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

[noreply at bugs.digium.com]

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-25-2008 07:25 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.


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

---------------------------------------------------------------------- 
 gasparz - 01-25-08 07:25  
---------------------------------------------------------------------- 
We figured it out when this issue happens:
- the destination is a gateway that receives music on hold signal when the
call is hanged up. Some PSTN gateways don't hang up the call imediatly, but
send a music on old signal so that the user can go to another room and
continue the call from there.

- for a reinvited call both parties hang up at the same time: we send the
reinvite to get the media back to our ip, they send the invite to signal
the MOH
- This is when both parties have a pending reinvite and the 491 is being
sent out.

- they resend the reinvite according to SIP RFC in 0-2 seconds interval. I
think we are hanging up the call that is why we send 503, not accepting any
more invites. They are hanging up the call with a bye message later (after
a the MOH timer overflows) and signal in the bye message the timestamp when
the call  actually was hanged up.

The conclusion is that this case is not affecting the call in any way, but
it would be nice to resolve the signalling mess, and implement the 491
handling conform to the SIP RFC. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-25-08 07:25  gasparz        Note Added: 0081170                          
======================================================================