Campaign Contact Number Length

Version 1
    This document was generated from CDN thread

    Created by: Jawad Bokhari on 12-07-2013 11:38:54 PM
    For the UCCX 9.0.2, while trying to load contacts for dialing via the RestFUL API we figured out that the nummber's maximum acceptable length for dialing is 8 digits. 
    The upload contact api call http://<server>:<port>/adminapi/campaign/{id}/contacts is successful, but the dialing never happen.
    Is there anyway to increase the acceptable length of Phone Number?

    Suprisingly, there's no issue uploading contacts manually via the UCCX AppAdmin interface. It accepts the 10-digit number happily.

    Subject: RE: Campaign Contact Number Length
    Replied by: Siddachetty Mahesh on 15-07-2013 02:48:17 AM
    Hi Jawad,

      There is no restriction on the length of phone numbers imported via REST api. You can use the REST api to get the pending contacts and verify that the contacts were imported correctly.

        Did you import contacts using the Appadmin interface and REST api for the same campaign?


        Regards,
        Mahesh

    Subject: RE: Campaign Contact Number Length
    Replied by: Jawad Bokhari on 16-07-2013 02:29:39 AM
    Thanks Mahes for your reply, 

    Yes I did it for the same campaign both ways, i) REST API and ii) AppAdmin. The same contact imported via AppAdmin is dialed out and I can get the pending list of contacts from REST API function.
    However, if the same number is populuated via REST, nothing happens. I can't see any contact returned as pending list of contacts either. But the API call to upload contacts returns sucess (200).

    And just by changing the length of number of digits, the dialer makes the dialing attempt and we see the error on gateway's log that the number is invalid. 

    It's something really wiered. Any suggestions on which logs should I enable/review to find the issue. 
    Following is the code snippet that I added in the SampleRestClient provided.
     1public void addCampaignContacts(String campaign, String campaignId) {           
     2          
     3           CampaignContacts cc = new CampaignContacts();           
     4           NameUriPair campaignURI = new NameUriPair();           
     5           campaignURI.setName(campaign);                       
     6           campaignURI.setRefURL(wr.path("5").toString());           
     7           cc.setCampaign(campaignURI);           
     8           StringBuilder csvDataBuilder = new StringBuilder();           
     9           String newLine = System.getProperty("line.separator");           
    10           csvDataBuilder.append("last name, phone1").append(newLine);           
    11           csvDataBuilder.append("testing, 1234567890");                                   
    12           cc.setCsvdata(csvDataBuilder.toString());           
    13           System.out.println("Ref-URL: " + campaignURI.getRefURL());           
    14           System.out.println("CSV-Data:");           
    15           System.out.println(csvDataBuilder.toString());           
    16           wr.path(campaignId).path("contacts").accept(MediaType.TEXT_XML).entity(cc, MediaType.TEXT_XML).post();               
    17}


    Subject: RE: Campaign Contact Number Length
    Replied by: Siddachetty Mahesh on 17-07-2013 05:09:34 AM
    Hi Jawad,

       We tried on our 902 testbed with the same data (8-/9-/10-digit numbers) and the calls were getting dialled out. This could be some other configuration issue.
       You can look at the following options to help narrow down the cause.

    1. Check MADM logs to verify no errors while importing contacts. You can also use the REST api to query contacts by "PENDING" status to verify the contacts are imported.
    2. As long as the contacts are successfully imported, the dialer behavior is indentical for both REST and Appadmin based imports. It does not differ based on how you inserted the contacts.
    3. Look at the MIVR logs to see why the dialer is not dialing out.
    4. If you have database access, you can confirm the numbers are dialled out by looking at the call status field.

    Regards,
    Mahesh
      

    Subject: RE: Campaign Contact Number Length
    Replied by: Jawad Bokhari on 22-07-2013 10:19:54 PM
    Thanks Mahesh for the detailed answer, 

    Our diagnostic was incorrect. The issues was actually related to some kind of duplication detection by UCCX for dialing. There's no difference in Appadmin and REST API behavior in this case. If a contact is loaded once from CSV and is dialed out and if we try to load the same contact again either from AppAdmin or REST API, the contact isn't dialed.
    Is there anyway to change this behavior and not to detect duplicates. 

    However, when I delete all campaign contacts and import the same contact again, it dials out.

    Appreciate your assistance,

    Subject: RE: Campaign Contact Number Length
    Replied by: Jawad Bokhari on 25-07-2013 01:38:04 AM
    I found something in the administration guide in the section "Import Contacts For Campaign" regarding duplicate handling:

    "When contacts are imported, the contacts text file is checked for duplicate entries. If the phone01 value of a contact matches the phone01, phone02, or phone03 values of another contact in the contacts list being imported, then the previous contact is overwritten with the new contact."

    Ref: http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/configuration/guide/UCCX_BK_U767AC77_00_uccx-admin-guide_chapter_01100.html#UCCX_RF_C826CD0A_00

    But does this apply to closed contacts also? And will it not call the same number again?
    That's what happening for us here. It sounds more like a limitation than a feature. Any idea, when can this limitation be resolved.

    Another thread talking about the same issue is http://developer.cisco.com/web/uccxapi/community/-/message_boards/message/11851529

    Subject: RE: New Message from Jawad Bokhari in Contact Center Express Configuration
    Replied by: Siddachetty Mahesh on 25-07-2013 03:26:48 AM
    Hi Jawad,

      During import, contacts are checked for duplicates in the import file and against any contacts that are not closed. If a contact is in closed state, the duplicate contact will be imported and dialed out by the dialer eventually.

      Regards,
      Mahesh

    From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
    Sent: Thursday, July 25, 2013 12:08 PM
    To: cdicuser@developer.cisco.com
    Subject: New Message from Jawad Bokhari in Contact Center Express Configuration API (UCCXAPI) - Message Boards Home - Contact Center Express Configuration API (UCCXAPI): RE: Campaign Contact Number Length

    Jawad Bokhari has created a new message in the forum "Message Boards Home - Contact Center Express Configuration API (UCCXAPI)": -------------------------------------------------------------- I<http://developer.cisco.com/web/uccxapi/community/-/message_boards/message/11851529> found something in the administration guide in the section "Import Contacts For Campaign" regarding duplicate handling:

    "When contacts are imported, the contacts text file is checked for duplicate entries. If the phone01 value of a contact matches the phone01, phone02, or phone03 values of another contact in the contacts list being imported, then the previous contact is overwritten with the new contact."

    Ref: http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/configuration/guide/UCCX_BK_U767AC77_00_uccx-admin-guide_chapter_01100.html#UCCX_RF_C826CD0A_00

    But does this apply to closed contacts also? And will it not call the same number again?
    That's what happening for us here. It sounds more like a limitation than a feature. Any idea, when can this limitation be resolved.

    Another thread talking about the same issue is http://developer.cisco.com/web/uccxapi/community/-/message_boards/message/11851529
    --
    To respond to this post, please click the following link: http://developer.cisco.com/web/uccxapi/community/-/message_boards/view_message/17585303 or simply reply to this email.