[asterisk-dev] [Code Review] SIP: Re-send non-100 provisional responses every 60 seconds until a final response is sent

[Terry Wilson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/315/
-----------------------------------------------------------

(Updated 2009-07-20 18:55:31.098322)


Review request for Asterisk Developers.


Changes
-------

Address Mark's review.

Also, for currently released versions of Asterisk, should I make this configurable and default to the old behavior and then default to the new behavior (unless SIP session timers are being used) in trunk?


Summary
-------

The issue here is that Asterisk does not send a non-100 response at every minute for calls that are in the provisional response state. This causes most UACs and/or proxies to terminate the call after 3 minutes. There are many legitimate reasons why a call could remain in an unanswered state for more than 3 minutes such as early-media (183), call queuing (182), call forwarding (181) and ringing (180). 
Following is quote from section 13.3.1.1 of RFC 3261 which explains what a UAS should do under such a circumstance:

   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction. A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction. To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

This patch is my first attempt at coming up with a fix for this.  Basically it will re-send the last non-100 1xx message that has been sent, defaulting to 183 Session Progress w/ no SDP if no non-100 provisional messages have been sent, until a final response is sent.  It appears that most phones I've tested this situation against with the dialplan:

exten => 123,1,Wait(360)

will generate ringing locally upon receipt of a 183 Session Progress w/o SDP--which should not indicate that ringing is necessarily taking place.  But, most situations we will be resending a 183 w/ SDP or 180 Ringing response.  It would be nice to add the ability for app_queue to return a "call queued" state so we could properly send a 182 Queued, but that is a topic for another day.

Anyway, I'd like some feedback as to whether this looks like it is on the right track or not!  It would probably be wise to make this option configurable, which I haven't done yet.  Thanks.


This addresses bug 11157.
    https://issues.asterisk.org/view.php?id=11157


Diffs (updated)
-----

  /branches/1.4/channels/chan_sip.c 206937 

Diff: https://reviewboard.asterisk.org/r/315/diff


Testing
-------

Tested against:
[default]
exten => 123,1,Queue(test|r)

exten => 234,1,Progress
exten => 234,n,Wait(360)

exten => 345,1,Ringing
exten => 345,n,Wait(360)

exten => 456,1,Wait(360)

exten => 567,1,Dial(Local/456 at default,,r)


Thanks,

Terry