[Home]

Summary:ASTERISK-05077: [patch] Provisional responses to INVITE are ignored if a request has been sent in an early dialog
Reporter:mikma (mikma)Labels:
Date Opened:2005-09-13 17:13:31Date Closed:2011-06-07 14:10:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 5215.patch
( 1) 5215.patch_copy
( 2) 5215-incoming2.log
( 3) 5215-outgoing2.log
( 4) cseq.patch
( 5) cseq.patch_copy
( 6) cseq.patch_copy
Description:Asterisk ignores provisional responses (for example 180 Ringing) to INVITE if it has sent a request (for example INFO) in an early dialog. I think it should allow responses for both the last outgoing request *and* INVITE, and I have made a patch that seems to work.

The early dialog was created when * received a 101 Dialog Establishment response.
Comments:By: mikma (mikma) 2005-09-14 04:15:11

Asterisk also shouldn't ignore ACKs for the initial INVITE in a dialog that it has received requests for in the early dialog. The following patch works for me, but might let some requests through that should be ignored.


@@ -10329,7 +10330,8 @@
       if (option_debug > 2)
               ast_log(LOG_DEBUG, "**** Received %s (%d) - Command in SIP %s\n", sip_methods[p->method].text, sip_methods[p->method].id, cmd);

-       if (p->icseq && (p->icseq > seqno)) {
+       if ((p->icseq && (p->icseq > seqno))
+           && !(!ast_test_flag(p, SIP_OUTGOING) && (req->method == SIP_ACK) &&
p->pendinginvite && (p->pendinginvite == seqno))) {
               ast_log(LOG_DEBUG, "Ignoring too old SIP packet packet %d (expecting >= %d)\n", seqno, p->icseq);
               return -1;
       } else if (p->icseq && (p->icseq == seqno) && req->method != SIP_ACK &&(p->method != SIP_CANCEL|| ast_test_flag(p, SIP_ALREADYGONE))) {
By: Michael Jerris (mikej) 2005-09-24 18:58:51

oej- can you review this please.
By: Olle Johansson (oej) 2005-09-28 15:17:15

I want to see a SIP debug for both cases, thank you.
By: mikma (mikma) 2005-09-28 17:30:37

I have uploaded SIP debug logs for two calls, one outgoing and one incoming. The problems are triggered by the overlapped dialing which generates INFO requests in the early dialogs in both calls.

I have also added an updated patch.
By: Olle Johansson (oej) 2005-09-29 01:50:16

When uploading SIP debug, please always set debug to 4, verbose to 4 and capture everything that Asterisk says. Make sure that debug log is sent to the console in logger.conf. I need to see what Asterisk says about the messages.

THank you.
By: mikma (mikma) 2005-09-29 05:17:15

Ok, I uploaded two new files with debug and verbose messages, hope it helps. I added the following debug statement (around line 10457) to display when the requests are ignored.

} else if (p->ocseq && (p->ocseq != seqno)) {
                      /* ignore means "don't do anything with it" but still have to
                          respond appropriately  */
+                       ast_log(LOG_DEBUG, "Ignoring too old SIP packet %d (expecting >= %d)\n", seqno, p->ocseq);
                       ignore=1;
}

(I noticed now that it should have been "expecting == %d")


By: Olle Johansson (oej) 2005-10-02 14:15:16

Hmm. This creates a major headache.

The INFO moves the sequence counter in the dialog while we still haven't finished the first INVITE. This version of chan_sip is unfortunately not transaction aware to a proper extent, so we can't handle multiple transactions open in the same dialog like this.

Can you help me with a pointer to where this way of doing overlapped dialing is described in an RFC or draft? I would like to learn more before I determine how we should handle this the best way without rewriting a large part of chan_sip. That will be done later, but not before 1.2 release :-)
By: mikma (mikma) 2005-10-02 14:57:19

I think the usage of INFO requests in an early dialog complies with RFC 3261 and RFC 2976, and another RFC or draft aren't really needed.

But a similar way to accomplish overlapped dialing is described in draft-zhang-sipping-overlap-00. It is only the body type, dtmf-relay vs x-session-info, and the usage of reliable provisional responses in the draft that differs.

If a UAS establishes an "early" dialog by sending a provisional response, I think it need to be prepared to receive requests in that dialog. They could be rejected with a failure response, but that would still require multiple transactions.

RFC 3261, 12.1
  Dialogs are created through the generation of non-failure responses
  to requests with specific methods.  Within this specification, only
  2xx and 101-199 responses with a To tag, where the request was
  INVITE, will establish a dialog.

http://www.ietf.org/internet-drafts/draft-zhang-sipping-overlap-00.txt
By: Olle Johansson (oej) 2005-10-02 15:06:13

Hmmm. I am a bit afraid of your patch... Will have to think about this tomorrow and read some docs. THank you for the references.
By: Olle Johansson (oej) 2005-10-13 18:00:19

Olle, is it tomorrow yet?
By: Kevin P. Fleming (kpfleming) 2005-10-31 18:45:38.000-0600

Any updates here? beta2 will be released tonight, but it would be good to have this one resolved before we proceed further.
By: Mark Spencer (markster) 2006-01-07 17:22:13.000-0600

Note it's not == %d, it's >= %d because there is nothing in the SIP spec that requires that incoming sequence numbers increase by one each time.
By: Olle Johansson (oej) 2006-04-03 15:51:13

reminder...
By: Serge Vecher (serge-v) 2006-07-06 11:24:16

* ping *
By: jmls (jmls) 2006-10-31 13:33:01.000-0600

this has been "pinging" a long time...
By: Nic Bellamy (nic_bellamy) 2006-10-31 14:25:27.000-0600

I can confirm that this is still an issue in the latest 1.2 code, and I think it exists in 1.4 / trunk too.

The sequence of events that breaks it for me is:

(The phone sends the initial INVITE - user was slow to dial, and kept going after the INVITE had been sent)

-> INVITE ...
<- 100 Trying
<- 183 Session Progresws
-> INFO (DTMF)
<- 200 Ok
-> CANCEL
<- 503 Server error

The phone is doing the correct thing with CSeq's according to the RFC, but since the Asterisk SIP stack isn't treating the INVITE and the INFO as separate transactions, when the CANCEL comes in, Asterisk thinks the CSeq is out of date, and responds with the 503.

I've worked around this by using RFC2833 for DTMF, but it'd be nice to have it fixed - I suspect we might be waiting for the Pineapple branch on this one though... :-)
By: jmls (jmls) 2006-10-31 15:50:28.000-0600

oej: can you have a look at this - still seems to be a problem with 1.4 and trunk. Thanks.
By: Olle Johansson (oej) 2006-11-12 13:53:23.000-0600

Moving this to 1.2 instead of trunk. It was trunk at the time this bug report was opened. Working on a way to solve this, based on mikma's patch with some changes.
By: Serge Vecher (serge-v) 2007-03-13 09:47:05

any developments on this report? It's getting quite stale ...
By: Olle Johansson (oej) 2007-05-16 03:50:54

Ok, this is high on the list to review and test. I can't find any good test devices that send DTMF during call setup...
By: Olle Johansson (oej) 2007-06-20 03:26:25

yes! I found a device I can test this with. Finally.
By: Monte (spirited) 2007-06-29 19:06:35

Fixed?
By: Leif Madsen (lmadsen) 2007-10-31 11:08:31

/housekeeping

Can we get this one closed out? Does the patch resolve these issues?

What device did you use to test with? Does this need testing with the license valid patches?
By: Olle Johansson (oej) 2007-11-27 02:12:07.000-0600

No, couldn't test after all. Anyone else tested this lately?
By: Olle Johansson (oej) 2008-02-03 04:42:33.000-0600

...and now the patches aren't reachable for licensing problems. Just fixed a similar problem with CANCEL and ACK after INFO, so I wanted to take a look at this...
By: mikma (mikma) 2008-03-02 10:05:51.000-0600

I uploaded the patches again.
By: Joshua C. Colp (jcolp) 2008-03-04 14:13:49.000-0600

I've confirmed with oej's last changes this is fixed.