Summary:ASTERISK-07264: [branch] Reinvite does not manage RFC 2833 -> wrong payload
Reporter:Sylvain RIBEYRON (sribeyron)Labels:
Date Opened:2006-06-30 10:25:23Date Closed:2011-06-07 14:08:15
Versions:Frequency of
Environment:Attachments:( 0) asterisksip.dump
Description:Connecting two softphones using Asterisk with reinvite option enabled may loose dtmfs if payload code is not 101 for audio/telephone-event for the calling phone.

When doing the reinvite, payload mapping is not actualized between the two terminals. Then, terminals may send dtmfs using two different payloads.


Here is a sample sequence:

Phone 1: sends invite to Asterisk with:
a=rtpmap:96 telephone-event/8000/1
<- OK ...

Asterisk: sends INVITE to Phone 2 with:
a=rtpmap:101 telephone-event/8000
<- OK ...

Then Asterisk reinvite:
Asterisk: sends invite to Phone 1 with:
a=rtpmap:96 telephone-event/8000
<- OK

Asterisk: sends invite to Phone 2 with:
a=rtpmap:101 telephone-event/8000
<- OK

Then, when rfc 2833 packets are sent from Phone 1 to Phone 2, their payload is 96, while Phone 2 waits for payload 101.

Workaround: either forbid reinvite, or use 101 as default payload for telephone-event in both phones.

Attached file contains complete traces of sip messages.
Comments:By: Andrey S Pankov (casper) 2006-07-02 17:46:38

Never seen Asterisk to negotiate RFC 2833 payload... it should be 101 and other payload types are not supported AFAIK.

By: Anthony LaMantia (alamantia) 2006-07-02 19:23:25

could we just not accept a codec change when a diffrent rtpmap sdp payload is sent and keep the old connection running via the stored sip_pvt structure in memory when process_sdp() is called?

/* Note: should really look at the 'freq' and '#chans' params too */
ast_rtp_set_rtpmap_type(p->rtp, codec, "audio", mimeSubtype);
if (p->vrtp)
ast_rtp_set_rtpmap_type(p->vrtp, codec, "video", mimeSubtype);

I am not entirelly sure on this tho.. and may be mistaken, input would be welcomed :)

or this may break some of the functionality of the reason for a reinvite ....

By: Sylvain RIBEYRON (sribeyron) 2006-07-03 01:58:44

I'm really not a SIP expert, but I think that choosing 101 as the only possible payload type for RFC 2833 is arbitrary. Rejecting other payload codes would not be a nice solution, because some softphones don't use 101 as default dtmf payload.

A good solution, I think, would be:
- to reuse the same payload map from caller to callee,
- not to re-invite if (for any reason) payload codes are not the same.

By: Olle Johansson (oej) 2006-07-03 09:45:50

We should offer the correct setting in the re-invite, this is most certainly a bug. Asterisk itself always set 101 to DTMF/RFC2833 but should keep others in mind when re-inviting.

By: Serge Vecher (serge-v) 2006-09-01 13:51:36

anybody able to handle a patch here?

By: jmls (jmls) 2006-11-01 10:18:30.000-0600

oej, you seemed to think that this was a bug. Is that still the case ?

By: Olle Johansson (oej) 2006-11-12 14:18:31.000-0600

This is definitely a bug that needs a fix.

By: Olle Johansson (oej) 2006-11-12 14:33:30.000-0600

Wonder if we do support this for normal codecs. If phone A wants to receive ulaw as codec 102, will Asterisk send codec 102 for ulaw on the re-invite to the other phone?

By: Olle Johansson (oej) 2006-11-21 03:17:22.000-0600

please test the "earlyrtpfix" branch where I fixed this - hopefully. We saw the same problem with video call setups.

By: Olle Johansson (oej) 2006-11-22 08:02:28.000-0600

My branch now fixes the setup of the call - the invite, but not handling the 200 OK coming back. Trying to fix that.

By: Olle Johansson (oej) 2006-11-30 01:27:59.000-0600

Have you tested my branch? Any feedback?

By: Henning Holtschneider (hehol) 2006-11-30 12:58:43.000-0600

I do not have a setup available at the moment to reproduce the case but I will try ASAP!

By: Olle Johansson (oej) 2007-01-23 03:00:38.000-0600

ASAP was a while ago... :-) Any updates?

By: Olle Johansson (oej) 2007-02-01 15:38:03.000-0600

Will re-open when reporter wakes up again.