|Summary:||ASTERISK-07264: [branch] Reinvite does not manage RFC 2833 -> wrong payload|
|Reporter:||Sylvain RIBEYRON (sribeyron)||Labels:|
|Date Opened:||2006-06-30 10:25:23||Date Closed:||2011-06-07 14:08:15|
|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.
****** ADDITIONAL INFORMATION ******
Here is a sample sequence:
Phone 1: sends invite to Asterisk with:
<- OK ...
Asterisk: sends INVITE to Phone 2 with:
<- OK ...
Then Asterisk reinvite:
Asterisk: sends invite to Phone 1 with:
Asterisk: sends invite to Phone 2 with:
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);
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.