locked
Inbound routing - The routing rules did not result in a final response for PSTN caller RRS feed

  • Question

  • We have brand new Lync 2013 environment with Frontend, Edge and Mediation server. PSTN connectivity is from SIP trunk.

    Problem seems to be inbound calls, which never reach the endpoint (Lync client). Outbound calls work perfectly, but inbound calls result the following error:

    TL_INFO(TF_PROTOCOL) [0]0FD8.16E8::03/05/2013-08:47:35.597.00001309 (S4,SipMessage.DataLoggingHelper:1823.idx(774))[449426627]
    <<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_1C3DD96>], 172.16.0.9:53230<-172.16.0.5:5061
    SIP/2.0 480 Temporarily Unavailable
    FROM: "<externalnumber>"<sip:<externalnumber>;phone-context=DefaultProfile@domain.com;user=phone>;epid=A60A3734C1;tag=febdceb379
    TO: <sip:020123456;phone-context=DefaultProfile@domain.com;user=phone>;tag=92244806470EACABD96B08EB2A4ED0D7
    CSEQ: 1057 INVITE
    CALL-ID: a33d9726-4b98-468e-b280-3b822609c2c2
    VIA: SIP/2.0/TLS 172.16.0.9:53230;branch=z9hG4bKfc6a737;ms-received-port=53230;ms-received-cid=4D1D00
    CONTENT-LENGTH: 0
    SERVER: InboundRouting/5.0.0.0
    ms-diagnostics: 13015;reason="The routing rules did not result in a final response for PSTN caller and non-UM enabled callee";source="DOMAIN-LYNC01.DOMAIN.COM";Callee="User.Lynctest@domain.com";appName="InboundRouting"

    The user's number is in E.164 format, +120123456 without extensions. SIP/2.0 101 message tells that the number is translated properly:

    ms-diagnostics: 14011;reason="Called Number translated";source="DOMAIN-LYNC01.DOMAIN.COM";RuleName="Default";CalledNumber="020123456";TranslatedNumber="+120123456";appName="TranslationService"

    We have pretty simple rules in Trunk and Voice route settings, allowing "all". These same rules work perfectly in Lync 2010, so what could be the problem?

    Tuesday, March 5, 2013 8:56 AM

Answers

  • I had a similar issue with ms-diagnostics: 13015; reason="The routing rules did not result in a final response for PSTN caller and non-UM enabled callee"

    The environment where I found the issue had Exchange Online for voicemail, and the specific user that was having the issue, my client did not set the user's HostedVoicemail to true.

    Make sure the user's voicemail is enabled/configured. If there's no end point logged in, Lync will try routing the call to voicemail, and if vmail is not enabled/configured, it will just ring fast-busy.


    Andrew Shin, TechNet Forum replies

    • Marked as answer by Kent-Huang Tuesday, May 14, 2013 5:57 AM
    Tuesday, April 9, 2013 4:23 PM

All replies

  • Hi,

    It means that Lync tried to route the call but couldn’t find an endpoint willing to take the call. You can refer to this link :

    http://flinchbot.wordpress.com/2013/02/20/inbound-lync-call-drops-immediately/

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.


    Kent Huang
    TechNet Community Support

    • Proposed as answer by Kent-Huang Tuesday, March 19, 2013 9:09 AM
    Wednesday, March 6, 2013 6:34 AM
  • there is one difference i see in my lab and production

    From:<sip:+49160xxxxx@msxfaq.de;user=phone>;.>
    To: <sip:+495246xxxxx@msxfaq.de;user=phone>;.

    you can see that my To/From lines stlll contain a domain part.

    And do you really have a lync user with the ="+120123456" as TEL:uri ?

    Can you enter tne ="+120123456 and see, if the lync client resolves that internally to the user ?

    Frank


    MCMLync2010, www.msxfaq.net, Please help us to find unanswered Questions by tagging answers as answer

    Thursday, March 7, 2013 11:14 PM
  • I had a similar issue with ms-diagnostics: 13015; reason="The routing rules did not result in a final response for PSTN caller and non-UM enabled callee"

    The environment where I found the issue had Exchange Online for voicemail, and the specific user that was having the issue, my client did not set the user's HostedVoicemail to true.

    Make sure the user's voicemail is enabled/configured. If there's no end point logged in, Lync will try routing the call to voicemail, and if vmail is not enabled/configured, it will just ring fast-busy.


    Andrew Shin, TechNet Forum replies

    • Marked as answer by Kent-Huang Tuesday, May 14, 2013 5:57 AM
    Tuesday, April 9, 2013 4:23 PM
  • TO: <sip:020123456;...

    Assuming that you did not change the number, you show that 120123456 translates, does 02123456 translate?

    Tuesday, April 9, 2013 5:40 PM