[asterisk-dev] Provider requires Delay between OK and ReINVITE

[Mark Michelson]

On 08/22/2012 11:27 AM, Olle E. Johansson wrote:
> 22 aug 2012 kl. 16:52 skrev John R Covert:
>
>> Help, please.
>>
>> I have a client using a provider which has just installed a new
>> SIP trunk into our Asterisk installation from a different platform.
>> All works fine on their "Sonus" platform.  However, on their "Fusion"
>> platform, they drop a call when they receive a ReINVITE.
>>
>> 09:48:58.495468 IP PROVIDER > ASTERISK: SIP, length: 1001
>> INVITE sip:exten at asterisk:5060 SIP/2.0
>>
>> 09:48:58.501365 IP ASTERISK > PROVIDER: SIP, length: 503
>> SIP/2.0 100 Trying
>>
>> 09:48:58.886713 IP ASTERISK > PROVIDER: SIP, length: 519
>> SIP/2.0 180 Ringing
>>
>> 09:49:12.794858 IP ASTERISK > PROVIDER: SIP, length: 815
>> SIP/2.0 200 OK
>>
>> 09:49:12.795835 IP PROVIDER > ASTERISK: SIP, length: 397
>> ACK sip:exten at asterisk:5060 SIP/2.0
>>
>> 09:49:12.801258 IP ASTERISK > PROVIDER: SIP, length: 835
>> INVITE sip:2167129661 at 208.93.226.215:5060 SIP/2.0
>>
>> 09:49:12.801595 IP PROVIDER > ASTERISK: SIP, length: 336
>> SIP/2.0 100 Trying
>>
>> 09:49:12.845627 IP PROVIDER > ASTERISK: SIP, length: 508
>> SIP/2.0 491 Request Pending
>>
>> 09:49:12.848064 IP PROVIDER > ASTERISK: SIP, length: 614
>> BYE sip:exten at asterisk:5060 SIP/2.0
>>
>> They have asked me to provide a delay between the "OK" sent
>> by Asterisk and the ReINVITE.
>>
>> Can this be done in the existing code?  If I were to develop a
>> change to SIP to allow this to be configured on a per-peer
>> basis or some other way (please suggest) would it be accepted
>> into the code base.
> We currently have no delay between the original call setup
> and the reinvite process. It could of course be made to a configurable
> option like you say and I see no reason why a patch that does this would
> not be accepted (unless the code is really bad… :-) )
>
> This option could be like this:
>
> directmediadelay = 10    ; Delay from bridge setup to media optimization attempt
>                                              ; default=0 s
>
>
> You can of course also disable the re-invites (direct media) in order
> to be able to use the new SIP trunk, but it sounds from your mail
> like this is something you want to happen.
>
> /O
The problem here is that not all reinvites are related to direct media. 
Reinvites may happen due to a switch to T.38 or in order to update 
connected line, for example. My assumption here is that the provider in 
question would respond to any reinvite in the same manner, and the 
problem is not limited to direct media reinvites. In fact, it would be 
worth investigating whether the same problem would occur for other 
in-dialog requests besides reinvites.

Depending on the breadth of the problem, the delay may be nearly 
impossible to get correct without causing problems elsewhere. In the end 
though, you are working with a broken piece of equipment if it sends an 
ACK for one INVITE transaction and then responds with a 491 to a new 
distinct reinvite transaction.

In the meantime, I suggest trying to address this in your dialplan. 
Answer the incoming call with the Answer() application, and then put in 
a small Wait() after the Answer(). I don't believe that Asterisk will 
try sending any reinvites to the caller until after the call is bridged, 
so your delay in the dialplan should take care of your issue.

Mark Michelson