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

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Jan 22 09:12:38 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-22-2008 09:12 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-22-08 09:12  
---------------------------------------------------------------------- 
Ok, let me ask again: What is the actual problem here, apart from the
signalling mess? Does it affect your calls? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-22-08 09:12  oej            Note Added: 0081009                          
======================================================================




More information about the asterisk-bugs mailing list