[Home]

Summary:ASTERISK-11278: receive 491 after reinvite handeling
Reporter:Gaspar Zoltan (gasparz)Labels:
Date Opened:2008-01-22 06:52:12.000-0600Date Closed:2011-06-07 14:07:54
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 7a2af493623b544f71806dbb52e7f3e7@204.10.64.135_log.txt
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@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@ip2:5060 SIP/2.0.  
2008-01-21 16:59:13 ip1:5060 ip2:5060 INVITE sip:number@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@ip2:5060 SIP/2.0.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 INVITE sip:number@ip2:5060 SIP/2.0.  
2008-01-21 17:08:30 ip2:56311 ip1:5060 INVITE sip:+16175104621@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@ip2:5060 SIP/2.0.  
2008-01-21 17:08:30 ip2:5060 ip1:5060 ACK sip:+16175104621@ip1:5060 SIP/2.0.  
2008-01-21 17:08:30 ip2:56311 ip1:5060 INVITE sip:+16175104621@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@ip1:5060 SIP/2.0.  
2008-01-21 17:08:30 ip1:5060 ip2:5060 BYE sip:number@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@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.

Comments:By: Olle Johansson (oej) 2008-01-22 08:27:24.000-0600

Ok, what's the actual problem here - does the call fail, the media not get through?
By: Olle Johansson (oej) 2008-01-22 08:30:39.000-0600

According to the bug guidelines, you need to upload a full SIP debug with debug at level 4 as an attachment. I would also like to see the SIP history for each call. Thanks.
By: Olle Johansson (oej) 2008-01-22 08:31:58.000-0600

That second re-invite seems like a retransmission to me. But I need to see the call logs for that.
By: Gaspar Zoltan (gasparz) 2008-01-22 08:45:13.000-0600

I attached a compleate call trace.

The problem here is:
1) we are issuing a bye message after we receive a 491
2) we are sending a 503 message for a reinvite retransmision
3) Asterisk is not calculating the retransmision time correctly

Yes the second invite is a retransmision, but that is exacly what it should do according to the sip RFC.
By: Olle Johansson (oej) 2008-01-22 09:12:38.000-0600

Ok, let me ask again: What is the actual problem here, apart from the signalling mess? Does it affect your calls?
By: Gaspar Zoltan (gasparz) 2008-01-25 07:25:51.000-0600

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.
By: Olle Johansson (oej) 2008-01-27 05:02:26.000-0600

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.
By: daniel g (revolution) 2008-01-27 12:32:32.000-0600

oej -- a thought :

could this be related to issue 0011736?

It sounds eerily similar to what is happening on my end (but in my case -- the channel hangs)...

your opinion?
By: Olle Johansson (oej) 2008-01-30 05:19:40.000-0600

Please try with latest 1.4 from svn, thank you.
By: Jason Parker (jparker) 2008-04-09 17:45:07

Closing, since this isn't actually causing problems, and per comments from oej.  This issue can be reopened once somebody is willing/able to look at it.