[Home]

Summary:ASTERISK-10681: Asterisk does not send a provisional response at every minute
Reporter:Raj Jain (rjain)Labels:
Date Opened:2007-11-04 16:29:06.000-0600Date Closed:2009-09-02 19:35:21
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ASTERISK_DEBUG.txt
( 1) SIP_1XX_NOREPEAT_TRACE.pcap
Description: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 issue was first reported by Alex Balashov on the asterisk-dev mailing list:
http://lists.digium.com/pipermail/asterisk-dev/2007-November/030341.html. I've reproduced this problem and collected wireshark and debug traces, which are attached to this bug report.
Comments:By: Alex Balashov (abalashov) 2007-11-05 02:34:52.000-0600

I was not even aware this was an implementational bug, especially with the 1.4.x tree.  :-)  It was just very strange;  I swore that the UAS implementation is supposed to retransmit provisional replies a lot more frequently than the interval tha I saw associated with the UACs aborting the call leg.

I would be curious to know the cumulative effect of retransmissions of early media / SDP messages of class 183 specifically on the continuity of the media stream, in the case of music-on-hold with queues, my original index case.  My guess would be that if the media is already being passed backward to the caller, the SDP information in the retransmission that holds it down probably just reaffirms it and does not disrupt it in any way.  Can anyone confirm that this would be true?  Or would the music restart each time the 183 was repeated?

Also, what if the SDP information passed back from the UAS in subsequent hold-down retransmits conflicts with the original media stream's port assignment parameters, etc?  Does the spec mandate that subsequent revisions to the media stream within the same dialogue be adhered to, in the case of provisional messages (rather than well-known implementations that utilise this precedence, like re-INVITEs).
By: Olle Johansson (oej) 2007-11-05 02:58:29.000-0600

Hmm. I don't think resending a 183 would work properly. We should propably resend something else.
By: Raj Jain (rjain) 2007-11-05 06:12:21.000-0600

The UAS MUST repeat the last 101-199 range 1XX (whatever that 1XX happened to be) that it sent to the UAC at every minute.

If the previous 1XX contained an SDP, then the keep-alive 1XX will contain the exact same SDP. As a matter of rule in the SIP protocol, a UAS is not allowed to change the SDP between 1XX and 2XX, let alone the SDP in keep-alive 1XXs. Since the UAC will see the same o= line version number across various keep-alive 1XX SDPs it knows that nothing has changed with respect to the media stream. The whole purpose of the keep-alive 1XXs is to refresh the early dialog at the UAC and proxies. This phenomenon has no effect on media streams whatsoever.

Regarding the point made about why we don't use RE-INVITEs for session refresh in this case, a RE-INVITE can not be initiated unless the previous INVITE transaction has successfully completed. In this case, the previous INVITE transaction is still going. This is in fact one of the fundamental reasons why SIP had to resort to keep-alive 1XXs.

Section 13.3.1.1 in RFC 3261 describes this is good enough detail.
By: Olle Johansson (oej) 2007-11-05 06:15:44.000-0600

Well, that's the theory. But practical tests have shown that the support of 183's is very shaky and I am sure that sending multiple 183's will confuse a lot of devices out there... I'll check the RFC's to refresh myself :-)
By: Raj Jain (rjain) 2007-11-05 06:33:18.000-0600

I don't think sending multiple 183s will confuse any devices as long as the SDP contained in these 183s is exactly the same. That's the key. Clearly, Asterisk will need to send the same SDP in such 183s. Also note that multiple 183s can happen due to interworking w/ PSTN anyways. If Asterisk receives multiple PROGRESS messages on Q.931, each PROGRESS will map to a 183 from Asterisk to the UAC.

These 183s obviously carry the same to-tag which indicates that they are being originated by the same UAS to take into account forking. When the UAC processes an inbound 183 SDP on an existing early-dialog, it sees that the version number in the o= line has not changed and thus it knows that it MUST NOT alter any media processing.

If a UAC causes media to change in such a condition then it is seriously broken. That UAC does not comply to RFC 3261 or RFC 2543. I don't think we should worry about such SIP implementations; they are unlikely to interoperate with any other SIP implementation anyway.

I realize that Asterisk has a bug in this area. I think Asterisk increments the SDP version number in the 200 from what it sent in the 183. I ran into this bug when I was developing SIP Session-Timers feature in Asterisk, because a session-refresh RE-INVITE also had to contain the previous SDP. I have now added a boolean argument in the function that generates SDP. When this argument is TRUE, that tells the function that it must generate the previous SDP not a new one.

Also, Asterisk had a bug that it would not check whether the SDP changed or not and would process any inbound SDP as the new SDP. I've corrected this was well as part of Session-Timers development. Now, when Asterisk sees an SDP which has the same o= line version number as the previous SDP, then it does not alter the media processing. I store the SDP version number in sip_pvt to accomplish this check.


By: Olle Johansson (oej) 2007-11-05 06:35:29.000-0600

Testing at SIPit showed a lot of interesting behaviours in regards to early media with 183... Trust me.
By: Raj Jain (rjain) 2007-11-05 07:03:16.000-0600

oej: I'm not disagreeing w/ you. I think the reason you encountered interop issues surrounding 183 is because Asterisk currently has some bugs in this area. The fundamental issue is that today Asterisk generates SDP statelessly.

Luckily, these bugs were easy to address and I've addressed them in the sip_session_timers branch.  Now we remember our local and remote end-point's SDP version number in sip_pvt. If the remote end-point is not changing its SDP version number, then we know that it is not asking for a media change. Likewise, when we are simply refreshing the session, we send the previous SDP in the RE-INVITE.

I've edited my previous note regarding some of these bugs, please take a read.


By: Olle Johansson (oej) 2007-11-19 13:04:42.000-0600

The issues discovered with 183's was not due to Asterisk, completely due to other devices all handling this in different ways. That's what worries me - since I know that 183 support is shaky, retransmitting it may make it even worse.

Regardless of the 183, do we have any patches for retransmission of 1xx>100 messages each minute?
By: Olle Johansson (oej) 2008-01-22 09:38:25.000-0600

This would add yet another scheduled timer to our poor sip stack... Well, gotta be fixed. No coders?
By: Olle Johansson (oej) 2008-01-22 09:51:45.000-0600

Another issue is that we don't save anything transmitted. I think it's time to start doing that in order to fix both this and responses to retransmissions. Coding time, folks.
By: Raj Jain (rjain) 2008-01-22 19:12:39.000-0600

oej,

We now do save the last SDP version that we transmitted in the sip_pvt struct. Take a look at the add_sdp() function. This allows us to generate the same SDP as the last one we sent.

I added this capability for the session-timers feature because the session refresh RE-INVITEs had to carry the same SDP as the previous one so that such RE-INVITEs do not trigger a media change of any sort and cause an interruption in the media flow. We can use the same "oldsdp" boolean flag for 1XX transmissions at every minute.
By: Olle Johansson (oej) 2008-01-23 01:43:36.000-0600

Well, it doesn't fix 1.4... But thanks for the tip.
By: jmls (jmls) 2008-05-03 14:17:34

ping. housekeeping
By: Tilghman Lesher (tilghman) 2008-07-16 12:03:56

rjain:  has the fix for this issue already been committed?
By: Raj Jain (rjain) 2008-07-16 13:04:10

Corydon76, Not yet. This is a somewhat low priority bug and I haven't gotten around to it yet. Still if possible, I'd like to keep the bug open so it can serve as a reminder.
By: Olle Johansson (oej) 2008-07-17 01:47:45

I suggest we add a note in chan_sip (a \todo) and include a reference to this bug report, then suspend this bug report. Keeping stuff open for too long blocks the view while working with critical bugs.
By: Raj Jain (rjain) 2008-07-17 04:52:29

oej's suggestion sounds fine to me. I'll take care of that.
By: Leif Madsen (lmadsen) 2008-10-22 10:41:58

Pinging this issue as it looks like it is almost ready to move to the next step; coding!

Any word on this issue?
By: Olle Johansson (oej) 2008-10-22 10:48:48

It's very low priority, as it is a feature request more than a bug.
By: Terry Wilson (twilson) 2008-12-16 16:29:30.000-0600

I went ahead and put the TODO in chan_sip.c and am suspending the bug since it is mostly a feature request and the reporter agreed that that would be fine with him.
By: Digium Subversion (svnbot) 2008-12-16 16:32:12.000-0600

Repository: asterisk
Revision: 164941

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r164941 | twilson | 2008-12-16 16:32:12 -0600 (Tue, 16 Dec 2008) | 2 lines

Make a note of the feature request in bug ASTERISK-10681 as per the reporter and oej, and suspend the bug since no one seems to be keen on implementing it any time soon.

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=164941
By: Digium Subversion (svnbot) 2009-09-02 16:42:07

Repository: asterisk
Revision: 215682

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r215682 | twilson | 2009-09-02 16:42:06 -0500 (Wed, 02 Sep 2009) | 18 lines

Re-send non-100 provisional responses to prevent cancellation

From section 13.3.1.1 of RFC 3261:

  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.

(closes issue ASTERISK-10681)
Reported by: rjain
Tested by: twilson

Review: https://reviewboard.asterisk.org/r/315/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215682
By: Digium Subversion (svnbot) 2009-09-02 18:31:49

Repository: asterisk
Revision: 215758

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r215758 | twilson | 2009-09-02 18:31:49 -0500 (Wed, 02 Sep 2009) | 25 lines

Merged revisions 215682 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
 
 Re-send non-100 provisional responses to prevent cancellation
 
 From section 13.3.1.1 of RFC 3261:
 
    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.
 
 (closes issue ASTERISK-10681)
 Reported by: rjain
 Tested by: twilson
 
 Review: https://reviewboard.asterisk.org/r/315/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215758
By: Digium Subversion (svnbot) 2009-09-02 19:05:57

Repository: asterisk
Revision: 215759

U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r215759 | twilson | 2009-09-02 19:05:56 -0500 (Wed, 02 Sep 2009) | 32 lines

Merged revisions 215758 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25 lines
 
 Merged revisions 215682 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
   
   Re-send non-100 provisional responses to prevent cancellation
   
   From section 13.3.1.1 of RFC 3261:
   
      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.
   
   (closes issue ASTERISK-10681)
   Reported by: rjain
   Tested by: twilson
   
   Review: https://reviewboard.asterisk.org/r/315/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215759
By: Digium Subversion (svnbot) 2009-09-02 19:23:58

Repository: asterisk
Revision: 215774

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r215774 | twilson | 2009-09-02 19:23:58 -0500 (Wed, 02 Sep 2009) | 32 lines

Merged revisions 215758 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25 lines
 
 Merged revisions 215682 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
   
   Re-send non-100 provisional responses to prevent cancellation
   
   From section 13.3.1.1 of RFC 3261:
   
      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.
   
   (closes issue ASTERISK-10681)
   Reported by: rjain
   Tested by: twilson
   
   Review: https://reviewboard.asterisk.org/r/315/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215774
By: Digium Subversion (svnbot) 2009-09-02 19:35:19

Repository: asterisk
Revision: 215795

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r215795 | twilson | 2009-09-02 19:35:18 -0500 (Wed, 02 Sep 2009) | 32 lines

Merged revisions 215758 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25 lines
 
 Merged revisions 215682 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
   
   Re-send non-100 provisional responses to prevent cancellation
   
   From section 13.3.1.1 of RFC 3261:
   
      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.
   
   (closes issue ASTERISK-10681)
   Reported by: rjain
   Tested by: twilson
   
   Review: https://reviewboard.asterisk.org/r/315/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215795