[asterisk-users] Second invite after 100ms (with default t1min=100) --> canceled call problem!

Michael Maier m1278468 at allmail.net
Mon Apr 25 10:43:06 CDT 2016


Hello Joshua,

On 04/25/2016 at 12:35 PM, Joshua Colp wrote:
> Michael Maier wrote:
>> Hello!
>>
>> I encounter the following problem (asterisk 11 and 13) with Teconisy as
>> trunk provider with enabled qualify and default t1min (100ms):
>>
>> Teconisy most often doesn't answer the first invite before asterisk
>> default t1min ended. Therefore asterisk sends one more invite. This
>> second invite is answered by Teconisy with
>>
>> status 486 - Request terminated - Channel limit exceeded.
>>
>> (The second invite obviously is interpreted as second, new call).
>>
>> Asterisk therefore cancels the first(!!) call - but Teconisy proceeds
>> with exactly this first call (which now can't be handled by asterisk any
>> more).
>>
>> For me, there are two problems in asterisk at this point:
>>
>> 1. The VoIP standard defines 500ms for t1 - using this standard value
>>     for t1min works fine with Teconisy, too. t1min should be always
>>     500ms - it prevents a completely blocked line!
> 
> The standard actually allows you to ignore this and use the estimated
> round trip time, which chan_sip will derive from the time it takes an
> OPTIONS packet to go out and get a response. The t1min just enforces a
> minimum.
> 
>> 2. Why does asterisk stop the call completely after the second invite,
>>     which is canceled by Teconisy? It should be ignored because it
>>     means, that the first invite is already processed by Teconisy.
> 
> The 486 response code is actually for indicating busy. The 4XX series is
> also for client failure, which tear down the session. It can't be
> ignored. This would break things.
> 
> The retransmission of an INVITE shouldn't result in multiple sessions
> being set up, the other side should treat it as a retransmission. This
> is a bug on their side. Your adjustment of the T1 just makes it so you
> don't allow it to happen.
> 
> I'd say the problem isn't with Asterisk but with the remote side. Since
> you can configure things to work that's great but I don't see any code
> changes we can do.

thanks for clarification! Besides that - I'm really wondering why others
don't face this problem - I hardly can believe that I'm the only one
affected.

Regards,
Michael



More information about the asterisk-users mailing list