[asterisk-bugs] [Asterisk 0011815]: receive 491 after reinvite handeling
noreply at bugs.digium.com
noreply at bugs.digium.com
Sun Jan 27 12:32:33 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 12:32 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.
======================================================================
----------------------------------------------------------------------
revolution - 01-27-08 12:32
----------------------------------------------------------------------
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?
Issue History
Date Modified Username Field Change
======================================================================
01-27-08 12:32 revolution Note Added: 0081236
======================================================================
More information about the asterisk-bugs
mailing list