locked
Simultaneous Ring through UX1000 Gateway, 404 User Not Found RRS feed

  • Question

  • Hi,

    We're working on on configuring a new UX1000 gateway in a basic Lync - UX1000 - Telco PRI configuration.   All basic calls in and out work, but I'm having an issue where, if the Lync user sets up simultaneous ring to their cellphone, simultaneous ring fails and lync logs a gateway responded with "SIP/2.0 404 Not found" error.  Transferring an existing call to an external number exhibits the same symptoms.

    I am pretty sure this is a setting on the UX1000 since, if I use our old gateway (Mitel 3300 sip trunk) the simultaneous ring works correctly. 

    I ran the Lync wizard while setting up the UX1000, but had to customize the call routing entries pretty heavily to match our existing dial plan.  I'm wondering if I could have screwed up an entry which handles the sim-ring / transfers.   I notice that the invite from Lync for simultaneous ring includes a "From" set to the external number dialing in instead of the lync user which is receiving the call.  Is it possible that the UX1000 is processing the "from" field to generate the 404 error? 

    Any ideas would be appreciated.

    Thanks

    Rob.

    Tuesday, February 28, 2012 3:43 PM

Answers

  • Hello Rob,

    As you said the reason is the calling number/address rule \+(\d{4}) you added for your outgoing calls, as Lync symring calls present the initial calling number, and not your internal number. But it should be easy to solve, just add a passthrough calling number/address under the previous one, with a regex like \+(.*) in the input field (you will maybe have to adapt the calling number format, to what your operator is awaiting but it should be almost the same format as basic call). And take care also of the kind or these calling rules, put them as optional and not mandatory. As summary, the first one will match your basic call, and the second one will match the simring call.

    • Marked as answer by rsweezie Sunday, March 4, 2012 2:51 PM
    Sunday, March 4, 2012 11:49 AM
  • Hi Rob,

    This is definitely not a bug, there is no need to duplicate all your normalization rules. Transformation tables can be difficult to understand at the beginning but at the end are very powerful, please have a look at this explanation for mandatory/optional, so you won't need to duplicate your rules:

    https://support.net.com/display/UXDOC/Optional+Matching+Overview

    Especially this comment:

    "While valid, a common use case should never have only one optional and one mandatory entry in a rule since having only one optional entry in a rule will always be considered mandatory."

    It means that if more than one type of transformation entry is present (in your case called number, calling number), at least one of each type must be true for the Transformation Table to be true and apply (whatever it is an optional or mandatory one).

    • Edited by nkv Monday, March 5, 2012 9:04 AM
    • Marked as answer by rsweezie Monday, March 5, 2012 11:31 AM
    Monday, March 5, 2012 8:58 AM

All replies

  • Hi Rob,

    I belive the "from" field is used to show the original callerid (if possable from your telco) so that it looks like some else calling you rather then your Lync number calling you.

    You mention that the Lync Log shows a 404 error, what does the UX1000 logging say?

    Cheers

    J

    Wednesday, February 29, 2012 2:54 AM
  • Hello Rob,

    In the Lync control panel click on Voice Routing and then Trunk configuration and double click on global and then uncheck "enable refer support", do this for all the trunks you have configrued.

    On the voice policy assigned to the user makse sure "Enable simultaneous ringing of phones" is checked.

    From the issue and 404 error it looks like the gateway does not understand the refer sent by the Lync mediation server. Wait for sometime and then try transfer or sim ring

    Thursday, March 1, 2012 9:03 AM
  • Thanks for the replies,   

    I started from scratch and ran the lync setup wizard.  After adding just the basic transformations I needed for outgoing / incoming calls I tried it again and, to my surprise, simultaneous ring worked fine.

    I added the transformation rules back in one by one and was able to isolate the one which appears to be causing the problem.   Internally, we use 4 digit numbers - ie "+2517" - for all our lync phones.   When I send them out to the PSTN, I need to rewrite that number to the users did - xxx-xxx-2517 so that the callerid shows up correctly.  I therefore created a transformation rule on the ux1000 which matches "Calling Address / Number" with a regex of \+(\d{4}) and replaces it with XXXXXX\1 (where the XXXXXX are the area code and suffix of the did).

    This works perfectly on the direct calls, but is what causes the simul-ring calls to fail.   I guess the UX is doing some sort of matching on the 4 digit extension and getting confused by the rewrite / failing with a 404.   Is there a different way to rewrite the outgoing callerid?

    Thanks again,

    Rob.

    Thursday, March 1, 2012 12:12 PM
  • Hello Rob,

    Thanks for the detailed information.

    Now for any call going out to pstn from the user's Lync client, you are manipulating the From address to show the DID of the user.

    What happens when the Lync user who is not setup for simul ring to his cell phone, calls his cell phone directly, does this work?

    Now setup simulring for the user and then make an inbound call to the Lync user, this will cause a call to the cell phone which will be routed through the UX gateway and the call fails, correct me if I am wrong..

    One thing to remember that the sip invite sent from the Mediation server to the gateway for a simul call will have the original caller in the From header and not the Lync user number.

    You can look at the mediation server debug logs using mediationserver and s4 component or at the gateway logs to confirm this...

    Is there a setting on the gateway which looks at the From header and since it belongs to a mobile number, rejecting it with 404?

    In Lync you can suppress the caller id by using caller id suppression in  voice routes but not an effificient way as you will have to do it for all the voice routes and its not sepcific to user, so inserting the user DID for each call is difficult. caller id suppression does not work with forwarded calls in Lync

    You can refer to the following kb article: http://support.microsoft.com/kb/2500421 after you make the changes, the Mediation server will send the information on who forwarded the call to the gateway in the sip invite using Referred-by header.

    If possible contact UX gateway support and check if they can use this referred-by header information and then forward the call to the cell phone or for any setting that is rejecting the call with 404 on the gateway.

    Saturday, March 3, 2012 10:53 AM
  • Hello Rob,

    As you said the reason is the calling number/address rule \+(\d{4}) you added for your outgoing calls, as Lync symring calls present the initial calling number, and not your internal number. But it should be easy to solve, just add a passthrough calling number/address under the previous one, with a regex like \+(.*) in the input field (you will maybe have to adapt the calling number format, to what your operator is awaiting but it should be almost the same format as basic call). And take care also of the kind or these calling rules, put them as optional and not mandatory. As summary, the first one will match your basic call, and the second one will match the simring call.

    • Marked as answer by rsweezie Sunday, March 4, 2012 2:51 PM
    Sunday, March 4, 2012 11:49 AM
  • Thanks for all the replies,

    I did some more work on this today.   It actually looks to me like this is a bug in the UX somewhere.  I setup the Net LX log monitoring software - for anyone with a UX based gateway, I'd highly recommend this, it makes interpreting the UX logs WAY easier than using a generic syslog server.

    I then compared the routing logic with and without the  (optional) "Calling Address / Number"  \+(\d{4}) replacing it with XXXXXX\1 rule.  All the sip signalling is identical, and the UX fails to match that rule on the simul-ring call (as you would expect).  Despite that, however, the UX does not route the simul-ring call if that rule is present.   This is why I'm thinking it is a bug - I can't see any reason the mere presence of that rule should make a difference if it isn't matching anything.

    In any case, I ended up doing basically what nkv suggested above - I added an additional entry to my call routing table which does a match on the phone-context=enterprise in the calling phone-context.  In that translation table, I duplicated all my normalization rules except the problem one above.   That seems to work perfectly, since Lync seems to always assign phone-context=enterprise to anything where the "from" is an external address.   It is just a bit annoying since I have to make almost a complete copy of my normalization rules.   I will open a ticket with Net to see if it is a bug.   Hopefully they will correct it.

    Thanks again for all the help.

    Rob.

    Sunday, March 4, 2012 2:51 PM
  • Hi Rob,

    This is definitely not a bug, there is no need to duplicate all your normalization rules. Transformation tables can be difficult to understand at the beginning but at the end are very powerful, please have a look at this explanation for mandatory/optional, so you won't need to duplicate your rules:

    https://support.net.com/display/UXDOC/Optional+Matching+Overview

    Especially this comment:

    "While valid, a common use case should never have only one optional and one mandatory entry in a rule since having only one optional entry in a rule will always be considered mandatory."

    It means that if more than one type of transformation entry is present (in your case called number, calling number), at least one of each type must be true for the Transformation Table to be true and apply (whatever it is an optional or mandatory one).

    • Edited by nkv Monday, March 5, 2012 9:04 AM
    • Marked as answer by rsweezie Monday, March 5, 2012 11:31 AM
    Monday, March 5, 2012 8:58 AM
  • Thanks again, nkv - after reviewing that article I added another optional match on the calling name / number that just passes through (as you suggested above) and it's all working nicely without the duplication.

    Always the little gotchas that seem to cause the biggest headaches - next time I'll try to rtfm first (;

    Cheers

    Rob.

    Monday, March 5, 2012 11:30 AM