CUCM 6, RCC and Reverse Number Lookup RRS feed

  • Question


    Hi All,


    OK - So I have CUCM 6, CUPS and OCS 2007 working for RCC.


    I have also set up a custom ABServer normalisation rules through Company_Phone_Number_Normalization_Rules.txt so that internal extensions and mobile numbers from AD appear in MOC (they are all coded to normalise to E.164 format).


    My trouble is that although I can get Reverse Number Lookup for an Outlook contact working OK, the same is not the case for numbers that are in AD.


    For example, I have John Smith in my Outlook contacts and his mobile number appears fine in RNL - but if an internal user from their internal extension calls me, I only get their extension in the toast and not their name.  If the call diverts on no answer to Exchange Voice Mail, I get an email that successfully does the RNL - but just not the toast.


    Any ideas peoples???




    Tuesday, January 8, 2008 7:23 AM

All replies

  • Hi Hendo,


    First try to dump the ABS by using abserver -dumpFile on the server and see how the numbers look here. Then check your uccp logs on the PC and see what format the numbers have there. If they doesn't match that is your problem. If they do match check that you have the latest ABS downloaded to galContacts.db.


    From your text it might be the case that ABS has the number in E.164 format and the incoming call is only the extension. If that is the case you need to change one of the places.


    best regards



    Tuesday, January 8, 2008 7:40 AM
  • Jens,


    I recently completed a similar deployment and spent some time picking apart the way Office Communicator handles number normalization.  I noticed the same behavior, and although I had all numbers normalizing correctly so that RCC would dial them in the ways that CUCM expected, internal calls between clients would only show the number in the toast and in missed call notifications.  I worked with MSPS on some related RCC issues but we didn't further investigate the reverse resolution issues.  I'm interested to know if there is in fact a way to get the Display Names to appear.


    I have complimentary translation rules to handle all internal numbers in both E.164 format and in simple +4444 format, so that internal calls are routed internally when click-dialed from the Work Phone entry in OC.



    Tuesday, January 8, 2008 4:01 PM
  • Hi Jens - yes, that's the point that I am at at the moment.


    You need to have the ABServer normalisation rules set to E.164 for MOC will display them but with the leading + it does not match the CUCM caller ID so you only get the number.


    Again, maybe this is another one that may by resolved with CUCM 6.1....we'll wait and see.





    Wednesday, January 9, 2008 12:56 AM
  • Hi Hendo.


    We are running CUCM 6.1 with CUP 6.0(2) and RCC in several deployments -- same issue.


    Also, I am unsuccessful at getting RNL to work with Outlook Contacts because we prepend a 9 to all calling numbers from the PSTN.


    So, the Outlook Contact is Bob with (408) 555-1212. The IP phone (and MOC) sees 914085551212. No match.


    I've been led to believe that normalization rules will affect RNL in this case, but the rule I have to strip the 9 does not result in an Outlook Contact match.

    Do you have this working?






    Saturday, January 26, 2008 4:35 AM
  • Hi Mark,


    Not at the moment mate.


    Though since you're running CUCM 6.1, does E.164 dialing from MOC work through the mediation server?


    That is, can you get Enterprise Voice AND RCC working at the same time?


    See my prior post here.






    Tuesday, January 29, 2008 12:43 AM
  • OK - still not getting this :-/


    Here's what I've got:


    - RCC works perfectly  I've canned Enterprise Voice for now knowing that it does not work

    - All phone numbers in AD in E164

    - Server URI set to the CUPS Server

    - Tel URI set to tel:7785;phone-context=dialstring

    - Phone numbers displaying and dialing correctly in MOC


    But still no Reverse Number Lookup!!!!


    Here's my Company_Phone_Number_normalization_rules.txt file:


    Code Snippet


    # 4 Digit Internal Extensions in 77XX



    # Mobile Numbers



    # Local Numbers



    # Full National Numbers 0392643660
    # In the following formats 03 9264 3660, (03) 9264-3660, 0392643660 etc.



    # Full E.164

    # E.164 with formatting



    Now when an internal extension dials in I only get the number (e.g. 7773).  When a mobile calls in, I get 004XXXXXXXX.


    Am I supposed to be normalising numbers for both outbound dialling AND reverse number lookup?


    Here's a uccp log sample:


    <?xml version="1.0"?>
    <DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
     <alertingDevice xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="SubjectDeviceID">
      <notRequired xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="Empty"/>

    Any ideas people!?!?


    I'm tearing my hair out here.


    Thanks for your help.




    Friday, March 7, 2008 5:21 AM
  • *bump*



    Wednesday, March 12, 2008 6:00 AM
  • This was my cenario: CUCM5.1+CUPS+OCS


    It was a challenge this one, but there's was all about string normalization and how MOC see the contact.db


    I manage to solve this with this normalization rule (used 4 digits as inside numbering)







    This way the company numbering database will have a phone string,

    When a cal arrives, MOC will match the tel=xxxx;phone-context=dialstring with the contact database


     It should work on RCC environments



    (OCS / CUCM  expert looking for a challeging company @Unified Communications)


    Wednesday, April 16, 2008 1:58 PM
  •  Luis R wrote:


    I manage to solve this with this normalization rule (used 4 digits as inside numbering)








    I tried what Luis suggested (adding the phone-context tag to the end of the rule in the normalization txt file) and it seemed break MOC client matching up that rule at all.  You can tell when you manually enter a number in MOC, if it matches a rule as you type you see the conversion in the box below.  When it matched to this rule I got a "No results found."


    My attempt:

    Code Snippet




    Tuesday, April 22, 2008 2:19 AM
  • Yeah I also tried that at some stage with no luck.

    Tuesday, April 22, 2008 6:38 AM
  • I can't find a reason why it working diferently between us, but I it took some heavy debug here to find this configuration.

    What I used:

    - Microsoft Network Monitor on OCS server to monitor network traffic bettwen OCS<->CUPS;

    - Snooper on the MOC client;

    - Abserver -dumpfile on both OCS address book and MOC galcontact.db.

    It was particular dificult to monitor the tests, since configurations are not immediatly assumed  by the OCS or the MOC


    Tuesday, April 22, 2008 7:57 AM

    I'm not using the E.164 normalization.

    Since CUCM doesn't support the plus sign it sends the caller ID with "clear" number.


    If you didn't do it yet, change the rule to



    This is for OCS/MOC handle incoming calls.


    For outgoing calls we'll have to configure a rule at CCM side...

    Tuesday, April 22, 2008 8:04 AM
  • Luis, thank you for attempting to help.  I will look at my debugs too and see if I can make any sense of what you seem to have found.


    One question to clarify, I assumed above that you meant you added a rule to your company normalization rule .txt file (the one used principally by the address book service)... is that right?  Or were you actually referring to a rule added to a location profile?

    Thursday, April 24, 2008 10:03 PM
  • > AD users have plain 4 digit for phone and 9 digit for mobile

    > I was only using the normalization txt file




    Monday, April 28, 2008 8:55 AM



    The problem with your rule is that it's not E.164 so MOC 2007 will ignore those numbers.  We need the ability to dial out of MOC.  It would be nice if you maintain two normalization rules - one for incoming and one for outgoing.


    So are you saying that you have 4 digit and 9 digit phone numbers appear in MOC 2007 without using E.164 format with + signs?

    Saturday, May 3, 2008 3:45 AM
  • This specific configuration will respond to CUCM Remote Call Control. There is special needs and configurations on both sides to support incoming and outgoing numbers:

    1) MOC will allways send E.164 numbers to CUCM that doesn't support the plus sign, (but only if theres' equal or more then 9 digits);

    2) CUCM will send plain numbers that OCS/MOC will translate as tel:<number>;context=dialstring


    How did I solve this:

    > At CUCM/CUPS you have to create a rule that when a number has more than those 9 digits and a plus sign it will strip the 1st digit (the plus sign) and will process the plain number;

    > When CUCM sends an incoming number the company_normalization_rule.txt will use this for a correct reverse number lookup


    In your company and country this configuration could be a little different.

    HINT: user microsoft network monitor in OCS server to analyse SIP packets that flow between OCS/CUPS

    Saturday, May 3, 2008 1:49 PM

    I agree and have E.164 numbers being stripped of the + sign in CUCM 6 with an application dial rule.  That works fine.  As for RNL, if CUCM6 sends tel:5000;context=dialstring it's not going to match up with anything in my address book since company normalization rules have changed them all to tel:+5000.  I'm not sure how you have RNL working but if there was a way to add the plus sign back in from CUCM I guess that would do it...
    Sunday, May 4, 2008 12:42 AM

    It is the company normalization rules that are helping the RNL.

    Active Directory users 'telephoneNumber' and 'mobile' fields have 4 or 9 digit plain number.


    MOC address book will match the "normalized" tel:XXXX;context=dialstring for RNL


    When i dump MOC GalContacts.db (using abserver.exe) i can see the number and is normalized rule.

    Monday, May 5, 2008 10:13 AM
  • OK, Here is a sample of my normalization rules file.


    Code Snippet

    # 4 digit extentions


    # Company Internal
    # 111-111-1111, dddd

    # 1-ddd-ddd-dddd



    Here is the result of abserver.exe -dumpfile


    Code Snippet
    ContactId 0ca8824c-6a31-43b0-8342-402fad162728
    otherTelephone 5555
    otherTelephone tel:+5555
    mobile 222-333-4444
    mobile tel:+12223334444
    telephoneNumber 111-111-1111, 5555
    telephoneNumber tel:+5555
    msRTCSIP-PrimaryUserAddress sip:mweidner@<company>.com
    displayName Weidner, Markus



    Here is my record in Contacts.csv (from my received files via the galcontacts.db dump function in MOC 2007 with the reg hack)


    First Name Last Name Display Name Work Phone Display Work Phone Number Cell Phone Display Cell Phone Number
    Markus Weidner Weidner, Markus 111-111-1111, 5555 tel:+5555 222-333-4444 tel:+12223334444


    But, let's say I called myself...  The call comes from CCM as tel:5555 and based on what I see here would not match with anything since galcontacts has + prefixes on every number.  Am I missing something?

    Monday, May 5, 2008 3:28 PM

    here my rule:



    here's an dumpfile from the address book:

    ContactId 52f8f131-b791-43c9-9779-007712daf1f3
    mobile 962000000
    mobile tel:962000000;phone-context=dialstring
    telephoneNumber 1767
    telephoneNumber tel:1767;phone-context=dialstring



    Monday, May 5, 2008 3:39 PM
  • I originally tried a normalization rule like yours ($1) but couldn't get the numbers to display in MOC2007 without the +$1.  So, is there a service pack or registry key to enable so that I don't have to bring in the E.164 + numbers?  My communicator.exe is version 2.0.6362...
    Monday, May 5, 2008 4:06 PM
  • This is behavior is by-design and according to PSS, it is NOT customizable.


    The reality of the situation is that it really only becomes an issue in an RCC deployment as EV dialing should by in E.164, hence the designed behavior.  And since MS is playing-down the RCC features of the product and has ripped out much of that code since LCS, I can't imagine their will be any support for changing this in the future.  I see Remote Call Control completely vanishing from future releases on the product Sad


    Monday, May 5, 2008 4:12 PM
  • I would think EV and RCC could coexist peacefully...  If Microsoft want to make a play for the SBM I can understand, but no enterprise is going to move to Microsoft EV until the product is road tested for a little longer.  Until then, I would hope they support RCC or they will risk losing customers to proprietary platforms like Cisco Unified Presence Server and the IM Client - which frankly are looking better and better compared to the limited integration we have with this.


    That said, if I can get RNL to work I will be happy.  And I guess based on what you said about feature stripping support for MOC initiated ad-hoc conferencing is not in the future.  That's too bad.

    Monday, May 5, 2008 4:29 PM

    Now I saw your problem

    If you are trying to use EV and RCC together I will not work (I tried that a lot).


    I already manage to deploy on a Lab our next objective; Use CUCM and OCS separated and with dial plans.

    Since CUCM has some features that cannot be addressed (yet) by OCS, Cisco will be used as the gateway to the PSTN


    Our corporates user will be able to choose which softphone to use.:

    may the best one win!

    Monday, May 5, 2008 8:29 PM
  • No - I just meant Microsoft should continue to support RCC since big customers will not toss their Nortel/Cisco/Avaya systems and jump on Microsoft EV anytime soon.


    We are using RCC.  So, after all of this discussion I still have no idea how you are getting MOC to display phone numbers which are not in E.164 format (based on the norm rules you pasted in...)


    Monday, May 5, 2008 8:44 PM
  • I haven't better explanations to justify why it is working, sorry!

    It took me a lot of time, and I know if I change some of this values, RNL will stop working.



    Tuesday, May 6, 2008 8:15 AM
  • I got it working!  Internal extensions look great and populate the name without a problem.


    Now my only problem is that outside calls are coming in without our required prefix digit "8" and don't match up with my normalized numbers which are in the format of tel:81234567890;phone-context=dialstring.  Did you add in a prefix digit on all incoming calls?


    Thursday, May 8, 2008 10:45 PM

     (I know how you're feeling)


    I didn't had the need to had prefix, but CUCM is very flexible on that, and you should be able to use and inbound rule to had a prefix. In my lab with OCS separate with CUCM I'm using one of those.

    With environment RCC I think it must is something to change in CUPS... I don't have access rights to the Cisoc production environment anymore Sad



    Friday, May 9, 2008 8:20 AM

    Hi Markus,


    If you would be so kind to show your rule(s) and dumpfile to get the RNL working?  I've been struggling to get this to work!




    Thursday, May 15, 2008 12:37 AM
  • If you read up the page a little you'll see what I was using for normalization originally.  I had prefixed a + to everything to conform to the E.164 standard.  However, after a bit more trial and error I noticed that as long as the WorkPhone is something like 4 or 5 digits - like a work extensions - "MobileNumber" and "Other" could be in any format.  I cannot explain why, but I only had a problem with MOC ignoring contacts' numbers when I tried to add a full 10 digit number to WorkNumber without the +.  As Luis said, this is something that takes a little trial and error to get working perfectly.


    At any rate, once you have the ability to bring your numbers in like 5555 you'll see in the dump from MOC that the normalization looks like tel:5555;phone-context=dialstring.  That will match up with the incoming string and RNL will work.  The other issue you may have (like me) is for calls coming from the outside.  We use 8 as our prefix digit, so I have to normalize everything with an 8 to enable dialing from MOC.  that means i have strings like tel:82122225555;phone-context=dialstring which don't match with what comes from CUCM: tel:2122225555Stick out tonguehone-context=dialstring.  So, I'm in the process of adding a "prefix digit" to my inbound DID translation patterns so that the incoming string includes the prefix digit.  This will also have the side effect of fixing the Cisco Phone missed calls directory which requires you to press edit dial and enter your code if you don't have prefix digits coming through.


    I hope this helps you.


    Friday, May 16, 2008 2:19 PM
  • I got this working as well.  I needed to modify the rule and add the 5 digit extension in the Business 2/Other Phone field.




    Friday, May 16, 2008 11:26 PM
  • How did you get MOC to recognize the Other phone field?  Did you edit the abserver config to add the attribute?


    Thursday, May 22, 2008 7:52 PM
  • Hello,


    Just wanted to add a couple of points for anyone who is finding this a little confusing.


    I'm a Cisco CUPS 6.0.3, Callmanager 6.1 (I think I will always call it Callmanager) and OCS 2007 Server Standard user.


    I use Remote Call Control only.


    You don't need any +'s in any of your dial strings to make RCC and Reverse Number Lookup work.  You just need to choose to whether to do everything in E.164 or not.  i.e. keep both OCS & CCM on the same numbering scheme.


    Just make sure your "Company_Phone_Number_Normalization_Rules.txt" reflects the way you use Cisco Callmanager and everything should work just fine.


    I have 4 digit extensions in the standard telephoneNumber AD field and dial 9 for an outside line.  Not a + in sight and no nead for Application Dial Rules in CCM.  RCC & Reverse Lookup work fine.


    Good luck.  It takes a bit of patience to match your rules and suddenly everything works really well.


    P.S.  If you do use an access code for an outside line don't forget to put in the "Company_Phone_Number_Normalization_Rules.txt" to cope with numbers in Communicator/Outlook that don't have a 9 appended.


    Sunday, June 1, 2008 3:54 PM
  • The problem that I am having is how to get the access code to dial.  I am not sure what to add in the "Company_Phone_Number_Normalization.txt" file to cope with the 9 in communicator and Outlook.  What seems to be happening for me is that RNL works just fine, but if a user wants to dial out the get a busy signal.  If the user enters a new phone number in MOC and makes sure to add the 9 to the start of the dialstring the call is completed.  I just have no idea on how to get MOC/Outlook to dial the 9 without breaking RNL.


    Thanks in advance for any suggestions.


    Monday, June 2, 2008 11:41 AM
  • We get MOC/Outlook to dial 9 with the following rules (and various other variations to deal with differently formated numbers).






    It is probably a little simpler her in the UK because all our UK numbers start with 0.


    I hope this helps.

    Monday, June 2, 2008 12:24 PM
  • This helps a great deal my only other question is with these particular rules how do you get RNL to work properly?  My numbers are stored in AD like this


    +1 (111)222-3333


    I can normalize this number so that RNL works properly I will attempt to use your strategy and see how this goes and I will post back with my results.  just so I am understanding the normalization rule correctly you have either a 7 digit or a 15 digit number correct?


    Monday, June 2, 2008 12:29 PM
  • I not a regular expressions expert by a long way.


    Have a look at http://www.regular-expressions.info/ (which I got from another post - perhaps in this thread - thanks to whoever posted it).


    (\d{7,15}) matches any number between 7 and 15 digits long.  We use this rule as a catch all rule at the bottom of normalisation rules.


    Other helpful regular expressions I use are...


    [\s()\-\./]+ which removes spaces, dashes etc from phone numbers.






    Turns "07702 111111" into 907702111111;phone-context=dialstring



    Another tip I found helpful is you don't need to sync the address book to test the rules.


    Add your rule to "Company_Phone_Number_Normalization_Rules.txt".  Save it and then use


    abserver.exe -testPhoneNorm "07702111111"


    to test your rules quickly.



    Good luck.



    Monday, June 2, 2008 1:19 PM
  • That is great info thank you very much for posting this.  I am just wondering if you are pre-pending a 9 in Cisco Call Manager to incoming calls?  If not how is RNL working?


    Monday, June 2, 2008 1:25 PM

    JSDC is indeed right.  In the end, you don't need the + anywhere in your normalization rules. 

    Let's look at a call from an extension:  Call comes in from extension 3550.  It looks like this "tel:3550;phone-context=dialstring"  Your normalization rules will have to normalize your four digit extensions so that they exactly match this incoming string.  Something like the following would work:

    Code Snippet



    The dumpfile from your addressbook should have an exact match with this.

    For outside numbers, you need a rule like this which will prefix your access digit, assuming your access digit is 9:

    Code Snippet
    # 1-ddd-ddd-dddd



    This will allow you to start a communicator call successfully... 

    But it creates a problem for incoming.  And the problem is the incoming digits will be just the 10, which will mean the string will be in this format:  "telBig Smileddddddddd;phone-context=dialstring"  And that will not match any of the normalized strings that have 9s.

    So, the last and final thing you need to do is add a 9 in your inbound translation patterns.  Let's say you have a DID of 212-222-2988 which goes to your phone.  (most people have auto attendants or ranges of DIDs, but this is just an example)

    In the Calling Party Transormations section, type in a 9 in the "Prefix Digits (Outgoing Calls)" section.  This will now prefix a 9 to any inbound call for that DID and then translated and sent to your extension, and your string will look like this: "tel:9dddddddddd;phone-context=dialstring" which will match something from the GAL (maybe a cell phone) or something from your outlook contacts.

    There are other ways to do this, but I found this to be the most simple.

    Tuesday, June 3, 2008 3:05 AM

    I notice you are using CUPS 6.0.3.  Have you had any issues with this release?  I've heard that it causes some fairly significant problems despite fixing a few.  Have you had success with flawless RCC, RNL, etc.?


    We are using 6.0.2 with some minor bugs/issues.

    Tuesday, June 3, 2008 3:06 AM
  • 6.0.3 seems fine.  (we only have a single CUPS server and only use the MOC functionality in anger)


    The only annoying bug is that when you first log on to Communicator and a divert is set on your Cisco phone, Communicator is unable to set/copy the divert and gives you an error with the option to click OK (which cancels the divert on the phone) and Cancel (which leaves everything alone and potentially leaves things out of sync).


    Given that the average user automatically clicks "OK" when ever they see "OK" they end up cancelling the office phone divert which can be annoying when you are half way across the country on your laptop.

    Tuesday, June 3, 2008 10:26 AM
  • OK in am now really starting to understand this.  I guess the next question I have is with the Outlook Contacts.  Do users have to store the phone numbers of Outlook contacts with a 9 prepended to the number?  If they do it shouldn't be that big of a deal a simple end-user training scenario  or do these normalization rules apply to Outlook contacts or is there a way to normalize the Outlook contacts.  I am sure this question is in the wrong forum, but it does pertain to the initial question.


    Tuesday, June 3, 2008 11:41 AM
  • The ABserver normalization rules apply to numbers stored in Outlook Contacts, as well as numbers manually dialed into the Find Bar in the OC Client and numbers pulled from AD phone number attributes.


    Outlook also has performs some standard formatting on numbers entered into Contacts, in terms of seperating characters and handling of the 1 prefix and area codes.


    Tuesday, June 3, 2008 1:12 PM
  • Great Post! thanks this will help I think I have my solution.  I want to thank everyone who has chipped in on this forum.  I will very soon have a working RCC Deployment with Cisco CM and CUPS as soon as I can get the Cisco guy to add the 9 to the inbound translation patterns.


    Tuesday, June 3, 2008 1:57 PM
  • Great Post!  Thank You very much for that info.  I want to thank everyone who has contributed on this forum as I will soon have a fully functioning RCC deployment with Cisco CM and CUPS as soon as I can get the Cisco guy to add the 9 to our inbound translation patterns.


    Tuesday, June 3, 2008 1:59 PM

    And you are running 6.0.3 without any of the following issues?


    1. calls placed by IP phone can't be controlled by MOC client (transfers, holds no longer work)
    2. calls placed by IP phone do screen pop with wrong called-number – it shows the callers own number
    3. calls placed by MOC client stay active for 30 sec, then MOC closes the session (IP phone call stays alive)
    4. Calls hung up with IP phone still show the MOC window open


    Pasted from pointbridge - https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=29


    I've held off on the load due to the following integration issues that .3 would cause...

    Tuesday, June 3, 2008 5:35 PM
  • Well I can certainly say 6.0.3 is not as buggy as this forum seems to be at the moment.  Getting loads of unknown errors when trying to post!


    Answers to 6.0.3 question.


    1.   Pretty sure this is not a problem but will test tomorrow and post my results.

    2.   Pretty certain I would have noticed this one as I have done nothing but reverse number lookup etc for a few days.

    3.   100% sure this is not a problem.  Just tested it remotely for 10 minutes.

    4.   100% sure this is not a problem.


    For the record I am running CCM




    Tuesday, June 3, 2008 7:25 PM


    haha - I thought it was me!  I now save my entire post to notepad before pressing the "Post" button since it usually takes 3-4 attempts to get a success!!!!  This is one of the buggiest forums I've ever used.


    If your experience is counter to those on pointbridge, I may just have to try out the update.  The big thing I need them to fix is the ability to invite others to a RCC phone call.  That ad-hoc conf capability was really nice in MOC2005.

    Tuesday, June 3, 2008 9:02 PM
  • Just made it into the office.


    I can confirm that all 4 items on your list seem to work fine for me at version:

    Wednesday, June 4, 2008 9:33 AM
  • I had these particular issues when we were running the previous version of CUPS.  Once we upgraded to version 6.0.3 the issues magically went away.  I do not manage the CUPS or CM Systems, but the problems that you speak of went away once our Cisco team did the upgrade.


    Wednesday, June 4, 2008 12:35 PM
  • Markus,


    About the ability to conference with RCC, I read that it still can be done if user still has Communicator 2005: so this limitation seems to come from the client part ! I thought it was a big server issue/limitation that made MS remove this functionnality, it seems to be more a marketing issue...digging in Communicator 2007, maybe we can find how to reactivate it ?!

    Friday, June 27, 2008 5:25 AM
  • We reproduced the issue mentionned in the blog listed above and there is a solution:


    Wrong number presentation is caused by the External Phone Number Mask defined for the IP Phone line:


    If you put something with XXXX for extension in EPNM, you will get troubble with CUPS, using this field prefixed by + in MOC clients.

    If you put the complete EPNM without XXXX (replace XXXX by the line extension) CUPS doesn't send the + and send only the extension digits, which is ok for OCS (corresponds to the Tel URI filled for RCC)


    Then it solves all issues of wrong pop up number, call cut.



    Friday, July 11, 2008 8:53 AM

    Is there a way to add the "+" for the incoming number with the SDK? There are a tools for SIP message routing and filtering available.

    Thursday, August 14, 2008 2:16 PM