none
International Outbound calls through PstnGateway timeout, national works

    Question

  • Hello all,

    I have a problem with outbound international calls through our VoIP-gateway (Patton).

    Basic info:

    Lync 2010, latest updates, national calls working, inbound calls working. All calls from old non-IP phone connected to old PSTN (siemens), which connect through same VoIP gateway (Patton) to the network works OK. International calls worked for half a year, now last two days we have the problems.

    Problem:

    Call from Lync client to international numbers ends 10 seconds after INVITE is send to the Patton (Patton answers with 100 Trying). Than Lync send "CANCEL". When calling from old infrastructure, the time between dialing the number and first tone is long (creating the connection to the target took more than 10 seconds). Both calls (from lync and old PSTN) is processed in same way on the Patton gateway (are routed to the provider).

    When calling national number, Patton after answering "100 Trying" send the "183 Session Progress" in 8 seconds and all is Ok.

    How can I change the timeout for Lync to wait for Session Progress message before it CANCEL the connection? It looks like the providers are overhelmed now in time of XMas and conncting the call takes more than the timeout on Lync.


    Kamil Sacek
    Wednesday, December 21, 2011 11:59 AM

Answers

  • The gateway must send "Session Progress" after "Trying" before it starts dialing on the PSTN side. This is one of the requirements for qualification as (enhanced) media gateway for Lync. In that case this timeout will not happen.

    Seems that with CU4 Lync is a bit more rigorous on this.

     


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Wednesday, December 21, 2011 3:36 PM

All replies

  • Hi Kamil ,

    Can you set the "EnableSessionTimer" on trunk configuration and check ??

    http://technet.microsoft.com/en-us/library/gg398238.aspx

     

    Thanks

    saleesh

     

    Wednesday, December 21, 2011 12:31 PM
  • I have enabled the SessionTimer and the result is still same.
    Kamil Sacek
    Wednesday, December 21, 2011 12:44 PM
  • I hope you would have captured wireshark logs , are you seeing any update or reinvite packets on the logs ?

    It's a good idea to check with service provider on the session expiry for international calls or any recent firmware updates .

     

    Thanks

    Saleesh

    Wednesday, December 21, 2011 1:03 PM
  • There is the log of the failing call:

     


    Kamil Sacek
    Wednesday, December 21, 2011 1:09 PM
  • The problem is graduating, now it looks like we cannot call to some mobile providers, even when are national. It looks like the link connection processing is too slow and Lync do not wait enough long. Could be this timeout changed? This looks like easiest way how to solve it.
    Kamil Sacek
    Wednesday, December 21, 2011 2:54 PM
  • The gateway must send "Session Progress" after "Trying" before it starts dialing on the PSTN side. This is one of the requirements for qualification as (enhanced) media gateway for Lync. In that case this timeout will not happen.

    Seems that with CU4 Lync is a bit more rigorous on this.

     


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Wednesday, December 21, 2011 3:36 PM
  • Ok, but is there some solution for that? Some setting to make the timeout longer? I am trying to find the solution on gateway side, but...
    Kamil Sacek
    Thursday, December 22, 2011 10:32 AM
  • The simplest solution is using gateways qualified for Lync server - see http://technet.microsoft.com/en-us/lync/gg131938.aspx

     


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Thursday, December 22, 2011 10:38 AM
  • I know that you must say that, but no, it is not simplest. It is simplest if I have no limit for money :-)

    Again - is there some settings to change this timeout?

     

    Thanks for your time.


    Kamil Sacek
    Thursday, December 22, 2011 10:41 AM
  • You got it :-)

    Seems like Patton is working on Lync qualification; just found a blog post where qualification was announced for Q3 2011. They might have a newer firmware or settings to enable sending "Session Progress" immediately.


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Thursday, December 22, 2011 10:47 AM
  • Oh, good tip, thanks!I will try their latest technology build of the firmware! I was just going through their change notes to see something about that but nothing mentioned. I will contact our vendor...

    Have a nice day


    Kamil Sacek
    Thursday, December 22, 2011 11:36 AM
  • I've just come into this exact problem as well. After almost 18 hours of pulling my hair out! I had a perfectly working system, and then I did a CU4 update to get Mobile features and now half of my gateways don't work.

    There must be a way to adjust this timeout?

    Dave


    Dave
    Tuesday, January 24, 2012 2:07 PM
  • We are using the Patton technical build firmware and we have no problems now. I do not know, if the problems were x-mas links overload or if the firmware helped.
    Kamil Sacek
    Tuesday, January 24, 2012 2:23 PM
  • Hi there

    You CAN change the 10 sec timeout.
    The file which has the configurable parameters is 'OutboundRouting.exe.config”.  Use caution when changing these values, as a rule of thumb try not to increase or decrease the value by more than 25% of its original value.
    The file can be found here on the front end servers C:\Program Files\Microsoft\Lync Server 2010\Server\Core
    Change this line:
    <add key="FailOverTimeout" value="10000"/>
    10000 represents 10 seconds. I changed it to 20 seconds to get rid of the problem in my deployment.
    You should restart the servers, or at least restart the front end service after the change.

    Regards
    Jonatan

    • Proposed as answer by Jonatan V Thursday, January 26, 2012 1:52 PM
    Thursday, January 26, 2012 1:51 PM
  • Hi Jonatan,

    thanks for sharing that. This seems to work as well as my above proposal (using SESSION PROGRESS).

    Regards
    Johann


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin
    Monday, January 30, 2012 4:09 PM
  • Couple of things to beware of with Jonatan's fix. This is not currently a supported fix and adjusting the parameters of this timer is not supported (even though this may fix the issue). This is important because any future CU updates could remove this setting and you could be back to square one. Johans fix even though not always possible with every gateway is supported.

     


    http://voipnorm.blogspot.com/
    Monday, January 30, 2012 10:26 PM
  • We have the same problem.
    We use the AudioCodes Mediant 1000 MSBG to PSTN and Astersik as a gateway to Callcentric VoIP provider.
    Timeout on all outbound calls.
    Both gateways send "183SessionProgress" to Mediation.
    The file OutboundRouting.exe.config have the same values, ​​before and after application of CU4.

                                
    Thursday, February 23, 2012 12:00 PM
  • Confirmed with Microsoft that this is a valid workaround after applying the CU4 Updates. Surprised Microsoft has not created a KB about this, but it works.

    Tuesday, February 28, 2012 4:17 PM
  • Hi all,

    We have a topology with Lync CU4 and AudioCodes M1K. They works in SIP over TCP (not TLS). AudioCodes M1K has a trunking SIP with a Provider. We have the issue that some ougoing calls are registered as unexpected failure from Lync Monitoring. The errors are related to Diagnostic ID 12000; reason="Routes available for this request but no available gateway at this point".

    Ping/ICMP from/to Lync/M1K are all ok. SIP OPTIONS from M1K to Lync are ok.

    So we think that the trouble could be related to the response timers of M1K and we would change the parameters on 'OutboundRouting.exe.config' on Lync.

    Are these changes officially supported from Microsoft? May we resolve the issue upgrading to CU5?

    Many many thanks
    SM

    Tuesday, March 06, 2012 11:12 AM
  • Hi,

    changes to 'OutboundRouting.exe.config' are officially not supported.

    CU5 has no changes to mediation Server as you can see here: http://support.microsoft.com/kb/2493736/

    Last changes to Mediation server were in November 2011.

    Regards


    • Edited by Wolfgang Bach Tuesday, March 06, 2012 1:01 PM correction
    Tuesday, March 06, 2012 1:01 PM
  • Hi Wolfgang,

    You are right but CU5 upgrades also Front End features and the issue could be related to them.

    In details in outbound routing engine.....

    Regards

    SM

    Tuesday, March 06, 2012 1:22 PM
  • CU5 replaces CU4 ?

    You must install the first CU4 to enable service mobility / autodiscover?

    Only CU5 enables service mobility / autodiscover?

    Thanks,

    Ronaldo

    Wednesday, March 07, 2012 8:09 PM
  • How on earth did Microsoft come up with that requirement? The fact the gateway sent a 100 Trying means the call has been acknowledged. If under a minute, there's no need to indicate session progress until there's actually session progress (like, remote end is ringing). Lync is essentially asking all gateways/providers to provide false ringing and show artificially low PDD. Why?

    10 seconds PDD isn't enough time even for US termination, let alone destinations with worse infrastructure. 

    We're using a certified "SIP Trunking" provider, and they definitely are not sending progress until they receive it, forcing us to undo this poor choice and set it to something more reasonable, like 30-40 seconds.

    Thursday, March 22, 2012 9:16 PM
  • The requirement to send "session progress" before establishing the call helps to build up an early media session since "trying" does not contain SDP so RTP path can only be started on "ringing" which may by too late and still lead to clipping at the start of the call because there may be some ICE/NAT traversal to be done before completing the connection.


    Johann Deutinger | MCITP Lync 2010 | MCTS Exchange 2010, OCS | ucblog.deutinger.de | http://twitter.com/jwdberlin

    Thursday, March 22, 2012 9:24 PM
  • Johann is on the money along with using the function as a way to identify down gateways faster for rerouting. As part of being a certified gateway partner this is a requirement. From expereince this seems to be a big issue more with international calls, less so with national US calls. If someone where to wait 30-40 seconds for ringback most would likely hang up so 10 seconds although a little low is actaully not outside the bounds of reality. 15-20 seconds is probably more likely as  a solution when adjusting the outboundrouting file for gateways or SIP trunking that do not support the session progression reply.

    http://voipnorm.blogspot.com/

    Thursday, March 22, 2012 9:52 PM
  • I see. I'm not sure how Microsoft determined that ICE would be useful in corporate environments (or how anyone decided it'd be more useful than UPnP in any environment), but I suppose that's a pointless debate now.

    False early media is of dubious value, as the media path might change when you get the actual media, so any early negotiation benefit would be negated in those cases. I'd only see it making sense if you're actually directly connected to the media gateway, and even then, in error scenarios you'd get fake ringing followed by failure, which is confusing at best. At any rate, Microsoft's certified partners apparently aren't doing this across the board, and at least there's an easy workaround.

    I guess this isn't going to change, so thanks for explaining the reasoning.

    Thursday, March 22, 2012 9:57 PM
  • That would mean the gateway is up to send a 100 Trying, but down so that it cannot send calls, nor reply with an error code? That sounds like poor behaviour on the gateway that should be fixed (or a poorly configured proxy).

    Thursday, March 22, 2012 10:14 PM