[asterisk-bugs] [Asterisk 0011815]: receive 491 after reinvite handeling

noreply at bugs.digium.com noreply at bugs.digium.com
Sun Jan 27 05:02:26 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11815 
====================================================================== 
Reported By:                gasparz
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11815
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-22-2008 06:52 CST
Last Modified:              01-27-2008 05:02 CST
====================================================================== 
Summary:                    receive 491 after reinvite handeling
Description: 
I noticed that asterisk doesn't support 491 Request Pending after an issued
reinvite, at least that's what the comment in the source code says:

lines: 12256 to 12259
	case 491: /* Pending */
		/* we really should have to wait a while, then retransmit */
			/* We should support the retry-after at some point */
		/* At this point, we treat this as a congestion */

lines: 12266 - 12270
				/* This is a re-invite that failed. */
				/* Reset the flag after a while 
				 */
				int wait = 3 + ast_random() % 5;
				p->waitid = ast_sched_add(sched, wait, sip_reinvite_retry, p); 

This is not conform to RFC 3261 - the random period set is incorrect

RFC 3261 states (page 65)
"If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer
with a value T chosen as follows:
1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it
generated the value), T has a
randomly chosen value between 2.1 and 4 seconds in units of 10 ms.
2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a
randomly chosen value of between
0 and 2 seconds in units of 10 ms."

Asterisk shouldn't handle this as congestion, it sould just resend the
invite after the random period.

Problem 2: when asterisk sends 491 to a received reinvite and the party
sends another reinvite in the correct 0-2 seconds interval it replays with
503 Unavailable.

Example callflow:

Date Src IP Dst IP Packet type 
2008-01-21 16:59:10 ip1:5060 ip2:5060 INVITE sip:number at ip2 SIP/2.0. 
2008-01-21 16:59:11 ip2:5060 ip1:5060 SIP/2.0 100 Trying. 
2008-01-21 16:59:11 ip2:5060 ip1:5060 SIP/2.0 183 Session Progress.  
2008-01-21 16:59:13 ip2:5060 ip1:5060 SIP/2.0 200 OK.  
2008-01-21 16:59:13 ip1:5060 ip2:5060 ACK sip:number at ip2:5060 SIP/2.0.  
2008-01-21 16:59:13 ip1:5060 ip2:5060 INVITE sip:number at ip2:5060 SIP/2.0. 

2008-01-21 16:59:14 ip2:5060 ip1:5060 SIP/2.0 100 Trying.  
2008-01-21 16:59:14 ip2:5060 ip1:5060 SIP/2.0 200 OK. 
2008-01-21 16:59:14 ip1:5060 ip2:5060 ACK sip:number at ip2:5060 SIP/2.0.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 INVITE sip:number at ip2:5060 SIP/2.0. 

2008-01-21 17:08:30 ip2:56311 ip1:5060 INVITE sip:+16175104621 at ip1:5060
SIP/2.0.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 SIP/2.0 491 Request Pending.  
2008-01-21 17:08:30 ip2:5060 ip1:5060 SIP/2.0 491 Request Pending.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 ACK sip:number at ip2:5060 SIP/2.0.  
2008-01-21 17:08:30 ip2:5060 ip1:5060 ACK sip:+16175104621 at ip1:5060
SIP/2.0.  
2008-01-21 17:08:30 ip2:56311 ip1:5060 INVITE sip:+16175104621 at ip1:5060
SIP/2.0. 2
2008-01-21 17:08:30 ip1:5060 ip2:5060 SIP/2.0 503 Unavailable.  
2008-01-21 17:08:30 ip2:5060 ip1:5060 ACK sip:+16175104621 at ip1:5060
SIP/2.0.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 BYE sip:number at ip2:5060 SIP/2.0. 
2008-01-21 17:08:31 ip2:56311 ip1:5060 SIP/2.0 481 Call Leg/Transaction
Does Not Exist. 
2008-01-21 17:09:00 ip2:56311 ip1:5060 BYE sip:+16175104621 at ip1:5060
SIP/2.0. 
2008-01-21 17:09:00 ip1:5060 ip2:5060 SIP/2.0 200 OK. 

ip1 is a 1.4.17 asterisk box

testing:
get a device that transmits 491 to a reinvite and see reinvite
retransmision.


====================================================================== 

---------------------------------------------------------------------- 
 oej - 01-27-08 05:02  
---------------------------------------------------------------------- 
With the number of bugs I have outstanding to fix, the "would be nice" bugs
ends up far down the list. I'm sorry, but that's reality unless someone
pays me for working with this.

To really fix this, we need to rewrite the internals of the SIP channel
driver to be more SIP complliant. That's work I've tried to get funding for
for almost two years now... Doesn't seem to be a high priority in the
community. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-27-08 05:02  oej            Note Added: 0081230                          
======================================================================




More information about the asterisk-bugs mailing list