[Home]

Summary:ASTERISK-11531: Asterisk sends 491 Pending for a new INVITE
Reporter:Andrew Tornash (atrash)Labels:
Date Opened:2008-02-27 15:12:13.000-0600Date Closed:2011-06-07 14:03:13
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 12091.diff
( 1) Pending_Problem_-_CLI.txt
( 2) Pending_Problem_-_debug.txt
( 3) SIP_DETAIL.txt
Description:Please help!!!

AsteriskNOW v 1.0.1 is setup with multiple phones running SIP.  

The server itself is communicating with our provider in SIP as well, and incoming/outgoing works great....

Except that outgoing calls get dropped in random time intervals ranging from between less than a minute to over 15 minutes.

Each time they get dropped, the SIP Debugging shows the same thing...
Here's a quick overview, with the detailed sip debugging attached.


So here's what happened for the last call:
1. The provider sends an INVITE:
INVITE sip:6787721321@10.212.7.226 SIP/2.0
CSeq: 778024721 INVITE

2. Asterisk responds with a Trying:
SIP/2.0 100 Trying
CSeq: 778024721 INVITE

3. Asterisk completes and sends the OK:
SIP/2.0 200 OK
CSeq: 778024721 INVITE

4. Provider sends another INVITE with a different CSeq:
INVITE sip:6787721321@10.212.7.226 SIP/2.0
CSeq: 778024722 INVITE

5. Asterisk thinks that this new invite is pending, and responds with:
SIP/2.0 491 Request Pending
CSeq: 778024722 INVITE

6. The provider ACKS this pending:
ACK sip:6787721321@10.212.7.226 SIP/2.0
CSeq: 778024722 ACK

7. The provider doesn't receive a completion, and responds with a BYE ( terminating the call :( ):
BYE sip:6787721321@10.212.7.226 SIP/2.0


Now, I'm left wondering why it replies with a 491 when the invite is not still in processing....

Comments:By: Joshua C. Colp (jcolp) 2008-02-28 13:30:07.000-0600

Please try the latest version as code responsible for this has been altered, as well if it still exists please enable debug to console in logger.conf, reload, type core set debug 9 on the console and upload the resulting CLI output.
By: Andrew Tornash (atrash) 2008-03-06 16:59:57.000-0600

Thanks for the quick response... and sorry for my delay, but I set up asterisk 1.4.18 and it took a little time reformatting and all.

Incoming/Outgoing is working fine, but the INVITEs from the provider cause the box to get stuck in a permanent Request Pending state.

Attached is the debug output which contains core debugging 9, and the CLI output which contains verbose 100 (to include EVERYTHING), and SIP Debugging (as well as normal CLI messages).

As a side note, is it normal to receive reINVITEs every 30 seconds from providers?

Thanks
By: Andrew Tornash (atrash) 2008-03-07 16:34:28.000-0600

So after some packet sniffing, it appears that this is caused by a discrepency in the way that the RFC is interpreted.

We're attached to a MetaSwitch UC9000.

When the OK is sent in step #3 above, it never reaches the switch (packet gets lost), the switch does not reply with an ACK, and then 2.1 seconds later sends anoter INVITE.

Apparently, the way that MetaSwitch has interpreted the RFC dictates that this reinvite gets a new CSeq.  Asterisk however, expects re-transmitted INVITEs to have the SAME CSeq.

Anyone have thoughts on this?
By: Joshua C. Colp (jcolp) 2008-04-14 12:39:13

Please give the attached patch a try against a recent check out of Asterisk 1.4
By: Olle Johansson (oej) 2008-07-03 11:46:47

No, the issue here is that we do not accept a re-invite until the first invite transaction is done and over. Before 4 in your scenario above, we must have an ACK from the other party. If that doesn't arrive, we simply deny any new INVITEs since the session is not UP yet. This is perfectly good according to the RFC.

There's no bug in Asterisk in this bug report.

If the second invite is ment to be a retransmission, it should have the same CSEQ. In this case, it's a re-invite in an existing session.
By: Olle Johansson (oej) 2008-07-03 11:47:57

If you still think there's a bug here, feel free to re-open this bug report. If you want to discuss, please find us on #asterisk-bugs on IRC or on asterisk-dev.

Thank you for reporting a possible bug. Good luck with fixing the issues with your device.