[Home]

Summary:ASTERISK-01047: [patch] SIP Info problems may cause call teardown
Reporter:Olle Johansson (oej)Labels:
Date Opened:2004-02-18 06:54:36.000-0600Date Closed:2004-09-25 02:49:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sipinfoproblem.txt
Description:If during a call, a UA sends SIP info to the other end (i.e. DTMF tones) and the retransmission of SIP Info fails, Asterisk tears down the call. This should not happen. Grandstreams doesn't OK on INFO so this makes calls go down un-necessary.

****** ADDITIONAL INFORMATION ******

The RFC says:
    However, the INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP.

I'll experiment trying to find a patch. We need to check for INFO method and not initiate a tear down (BYE) if an INFO message during a call fails. Right now, ASterisk sends BYE to all parties.
Comments:By: z_smurf (z_smurf) 2004-02-18 09:45:06.000-0600

No patch needed.
Why should asterisk ever send INFO to grandstreams?
The fix is to change your sip.conf:

dtmfmode=rfc2833
By: Olle Johansson (oej) 2004-02-18 10:20:31.000-0600

I knew that I could configure around it, but still, it's a major fault if Asterisk tears down calls on SIP Info-related problems. Customers like to play around with tones and have various devices that react to DTMF.

This *really* needs to be fixed.
By: z_smurf (z_smurf) 2004-02-18 11:07:23.000-0600

I agree that asterisk is acting faulty on retransmissions, but still I cannot see why configure asterisk to send DTMF-info.

You can still have "send DTMF as sip-INFO" enabled in the phone.

I think there is more transmissions that causes a call to tear down, for example the "183 call in progress".

I can see two possible solutions:
1) Do not send unsupported packets to some phones. Somehow set up this in sip.conf
2) After 4 retransmissions, check wether the sent command should tear down call or not. Of not, just delete the que so no ACK is needed.

I think there is one thing that is not very good with 2), and it is that if several commands is sent to phone, all others will be blocked in 5 seconds until the INFO-que is deleted. If too much info-packets are sent, it can be a long que?

edited on: 02-18-04 09:53
By: Olle Johansson (oej) 2004-02-18 12:24:12.000-0600

What's the problem with 183 call in progress? Please tell me more!

The #1 is hard to do.
The #2 is is easier to do, is my guess. I'll check on it.
By: z_smurf (z_smurf) 2004-02-18 19:51:16.000-0600

The 183-bug can be shown in following scenario.

1) Configure asterisk to have two sip-peers. set dtmfmode=rfc2833 so asterisk will never send any INFO-packets to the phones, so we eliminate the INFO-bug.
2) Connect two GS-phones. In the GS-setup, set "Send DTMP via SIP-INFO". This should really do no harm, right?
3) Dial from phone 1 to another. While the phonenumber is sentfrom phone 1, and phone 2 is about to ring, press *a lot* of random digits on phone 1.
4) Now, asterisk will get stuck, and send the "183 session in progress" to phone 1 five times, and then hang up.

If you take a closer look to the sip-packets, you will notice that the SEQ number of the 183:s is already used by another message, which already got an ACK from the GS-phone. This may be another bug, but it does not matter. The thing that does matter is that retransmissions of 183 shold not tear down the call.

//Andreas
By: Olle Johansson (oej) 2004-02-19 16:16:35.000-0600

That's certainly the same bug. These are packets sent by in-dialogue messages with the same call-id. We have to mark SIP messages as critical and non-critical and only issue a bye if it's caused by retransmission of a critical SIP message. Thank you for the input, I'll look into this during the weekend.

Have to check the RFC for 183 messages, but I don't believe that 1xx class messages are considered critical at all.
By: Olle Johansson (oej) 2004-02-20 18:18:39.000-0600

Tried to fix this in the chan_sip2 channel, will try this in my test lab.
By: z_smurf (z_smurf) 2004-02-23 17:50:14.000-0600

Uploaded patch is stolen from chan_sip2.c.
It fixes both problems mentioned in this bugnote.

Please attach to CVS :-)
By: Olle Johansson (oej) 2004-02-24 02:48:53.000-0600

I'm not proud over this fix, it's more of a short-term hack. At least we now know that there was a problem with cancelling calls where some devices did not respond to in-dialogue messages.

The long term fix is adding a flag when initiating a SIP package, so that the xmit system knows when to cancel the call or not.

Apart from INFO, are there other in-dialogue SIP transmissions that should not disturb the call state?
By: z_smurf (z_smurf) 2004-02-24 06:07:03.000-0600

AGI "SEND TEXT" makes the same thing happen.
I don't know if that also is an INFO-event?
By: Olle Johansson (oej) 2004-02-24 08:39:46.000-0600

In SIP that's a MESSAGE. Messages within a SIP INVITE/BYE dialogue. Have to check how that works in the SIP standards - do we use the same call id. Do you have a trace?
By: z_smurf (z_smurf) 2004-02-24 18:34:51.000-0600

Well.
Seems that this patch even cures the agi-test.agi script that comes with asterisk. Instead of hanging up in the middle the "say number", it just shows a notice:

   -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-test.agi
   -- Playing 'digits/1' (language 'en')
   -- Playing 'digits/hundred' (language 'en')
   -- Playing 'digits/90' (language 'en')
   -- Playing 'digits/2' (language 'en')
   -- Playing 'digits/million' (language 'en')
   -- Playing 'digits/8' (language 'en')
   -- Playing 'digits/hundred' (language 'en')
   -- Playing 'digits/30' (language 'en')
   -- Playing 'digits/7' (language 'en')
   -- Playing 'digits/thousand' (language 'en')
Feb 25 00:18:35 NOTICE[7176]: chan_sip.c:497 retrans_pkt: Maximum retries exceeded on INFO message 27681bd690efef1c@192.168.0.26 for seqno 102
   -- Playing 'digits/4' (language 'en')
   -- Playing 'digits/hundred' (language 'en')
   -- Playing 'digits/60' (language 'en')
   -- Playing 'digits/5' (language 'en')
   -- AGI Script agi-test.agi completed, returning 0

Perfect!
By: alric (alric) 2004-03-22 12:21:55.000-0600

Per oej: "Need to rip the solution from chan_sip2 out and crate a patch for chan_sip. It's not committable yet, it works but is ugly."

He's working on it.
By: Olle Johansson (oej) 2004-03-22 12:23:00.000-0600

Reminder sent to oej

Rip the code out of chan_sip2 and fix a new patch :-)
By: Olle Johansson (oej) 2004-03-24 14:34:22.000-0600

New patch uploaded. This code is taken from chan_sip2, where it has been tested and confirmed to work properly.

It fixes a lot of problem with unexpected teardowns of SIP calls, especially when pressing DTMF buttons.
By: Mark Spencer (markster) 2004-03-24 16:27:16.000-0600

Proposed alternate fix in CVS, will commit if all goes well.
By: Olle Johansson (oej) 2004-03-24 16:41:45.000-0600

Ok, Marks fix is more a longterm fix than my hack. Please test this and confirm here if it works or not in your installation.
By: twisted (twisted) 2004-04-29 08:51:20

It's been over a month, can we get an update?
By: Olle Johansson (oej) 2004-04-29 11:52:18

Fixed in CVS. Open new bug report if there's still a problem, but since we haven't got any response, I'll consider this fixed. /O