Summary:ASTERISK-17410: Video dynamic RTP payload type negotiation incorrect when directmedia enabled
Reporter:Boris Fox (boris fox)Labels:
Date Opened:2011-02-15 09:00:15.000-0600Date Closed:2016-09-23 14:19:24
Versions:1.8.2 Frequency of
is related toASTERISK-22789 chan_sip SDP incorrect negotiation for RTP payload types causes DTMF recognization failure and appears to violate RFC
is related toASTERISK-23279 [patch]Asterisk doesn't support the dynamic payload change in rtp mapping in the 200 OK response
is related toASTERISK-25166 No audio when using direct media and a codec with a dynamic payload
Environment:Attachments:( 0) debug.txt
( 1) debug2.txt
( 2) debug3.txt
( 3) full
( 4) full2
( 5) full3
( 6) pm10-410-409-calling-sip_only.pcap
( 7) pm9-410-409-called-sip_only.pcap
( 8) rtp_payload_patches.tgz
( 9) sip.conf
(10) sip.conf2
Description:When calling endpoint specifying dynamic RTP payload type for some codecs (H.263-1998 for example), and directmedia is enabled, Asterisk negotiates it's own built-in payload type for this codec with the called party, and doesn't re-negotiate it during remote bridge setup (in re-INVITEs). This leads to both parties bridged together having different dynamic payload types for the same codec, and can't receive video media stream from each other.

sip.conf, full log file, and sip debug trace for that two peers are attached.
Peer 410 at host PM10 [] is the calling party, 409 at PM9 [] is the called.
410 offers payload type 115 for the H.263-1998 codec, and Asterisk translate this call to 409 with the same video codecs but offers payload type 98 for H.263-1998. Peer 409 accepts it. When Asterisk re-invites the peers establishing remote bridge, corresponding payload types does not change to one common value, but remain as negotiated at call setup.


Traces collected at version, but problem still persists in the current svn trunk revision.
Operating system is CentOS release 5.5.
Comments:By: Leif Madsen (lmadsen) 2011-02-16 15:42:23.000-0600

directrtpsetup=no               ; Enable the new experimental direct RTP setup. This sets up
                               ; the call directly with media peer-2-peer without re-invites.
                               ; Will not work for video and cases where the callee sends
                               ; RTP payloads and fmtp headers in the 200 OK that does not match the
                               ; callers INVITE. This will also fail if canreinvite is enabled when
                               ; the device is actually behind NAT.

By: Boris Fox (boris fox) 2011-02-20 05:09:53.000-0600

Problem still persists even with explicit "directrtpsetup=no" setting. New debug trace attached.

By: David Vossel (dvossel) 2011-04-26 16:48:07

I fixed something similar to this last week.  If you could please update to the latest. 1.8 branch code and verify this problem still exists.

Here's the revision my patch was committed in.


By: Boris Fox (boris fox) 2011-04-28 08:12:07

Thanks for your efforts to help.

Tried latest 1.8 code from svn today.
Still no luck, called station again got payload type 98 for H.263+ instead of 115 negotiated by the calling. When both stations bridged together, they've reinvited with these different payload types, which of course do not match.
Attached new files are full Asterisk debug "full(3)", sip debug of the called station "debug(3).txt", and two tcpdump captures: pm10 from the calling station and pm9 from the called.

By: Artem Makhutov (artem) 2012-08-13 13:38:40.885-0500

This problem still exists with Asterisk 10 and 11 and no only affects video but also audio calls.

When using directrtp asterisk should keep the rtpmap payload ID of the original offer. Instead it set's it's own ID in the ReINVITE.
This breaks all directrtp calls where the internal RTP payload ID of the phone is different from what asterisk is using.

When not using directrtp the rtp engine of asterisk is reweriting the payload ID of the RTP stream so that if machtes all devices - this can't be done in a direct RTP setup.

Example - both phones are using an internal payload ID of 116 for ILBC, asterisk is using 97 (as definced in main/rtp_engine.c):
Initial Invite of Phone A:
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20

ReINVITE send to Phone B:
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20

Phone A is sending a RTP stream with payload ID 116 to phone B, but phone B excepts the RTP stream to have a payload ID of 97.
This results in no audio be playing back by Phone B and vice versa.

By: David Woolley (davidw) 2012-08-14 05:48:59.582-0500

http://forums.digium.com/viewtopic.php?f=1&t=82925  seems to be discussing this problem.  I don't know if it has common participants.

By: Scoops Adamczyk (scoops) 2012-08-20 17:23:28.262-0500

I'm running into this too with video codecs.
When doing the bridging, I see Asterisk does remember the given payload type and uses that in the re-invite.
Shouldn't Asterisk just pass the payload number to the other endpoint when doing bridging?

By: David Woolley (davidw) 2012-08-21 05:56:18.783-0500

Asterisk is a back to back user agent for multiple technologies.  It started being primarily for circuit switched networks, which do not use RTP.  In principle, it might have technologies added that constrain the codec numbers so that they cannot be aligned with arbitrary SDP ones.

For a normal bridge, media is passed on to the software equivalent of a backplane with standardised codec numbers.  The codec numbers are then remapped by the outgoing side.  It is only during a native bridge, where the same technology driver is handling both sides, that it is even possible to pass through codec numbers unchanged.  The rest of this thread is really just about the native bridging case.

Incidentally one other thing that can cause complications is if the calling party use late offer SDP.  Asterisk generally/always uses early offer SDP.  That means that Asterisk can have told the outgoing side which codec numbers it is going to receive before the caller has told Asterisk which they are.  For a native bridge, this should get resolved, because Asterisk will re-invite, after the late offer has arrived, but for a general case bridge, this issue applies.

By: Artem Makhutov (artem) 2012-08-21 06:29:52.630-0500

Yes, when asterisk is not touching the RTP stream then it must pass-though the payload ID's in the SDP otherwise there can be a miss-match betweeen the SDP and the RTP stream payload...

By: Scoops Adamczyk (scoops) 2012-08-31 12:16:31.031-0500

I have been staring at chan_sip for a week and I have created these patches that will forward the RTP payload type. I have only tested with video, and then just 2 different clients.
I don't know if my changes are very correct with the Asterisk philosophy, and I'm not very versant with making patches, but I am willing to do what we need to get this fix in.
These diffs are from 10.7.0

By: Scoops Adamczyk (scoops) 2012-09-21 18:47:57

How can I get anyone to look at my code and give comments?

By: MS (ims77) 2013-10-15 05:26:43.529-0500

The patch is corrupt.
I migrate from 1.6 to asterisk 11 and I meet this problem.
directmedia is no more available with the latest version of asterisk 11 (LTS!) => Maybe should not be a minor bug?
Without directmedia all the traffic must go through the asterisk server resulting in a higher charge...

By: Rusty Newton (rnewton) 2013-10-16 11:13:25.928-0500

@Scoops if you are still watching this issue, the best way to get attention on an issue would be to bring it up for discussion on the asterisk-dev mailing list. There are a lot of issues on the tracker and most people don't want traffic on all of them.

@MS, what specific version of 11 did you test with? (SVN revision, or specific release version)
Are you having a general problem with directmedia other than issue with video dynamic RTP payload described in this issue 17410?

By: Boris Fox (boris fox) 2013-10-16 20:56:48.084-0500

I'll try to adapt this patch to 11.5 and check again.

By: MS (ims77) 2013-10-17 02:53:45.638-0500

I've tested with the release version 11.5.1
I have exactly the same problem than boris fox & Artem Makhutov (no more general problem) => the phones A & B can't exchange the video streams when the codecs use a dynamic RTP payload.
The phone A sends an INVITE with H264 / payload 102 to the Asterisk server
Asterisk sends an INVITE with h264 / payload 99 to the phone B
With directmedia=yes => A sends the video stream directly to B but B does not recognize the payload...

By: Scoops Adamczyk (scoops) 2013-10-17 16:21:41.023-0500

@Rusty Yes I'm still watching this.

We are stuck with 10.7 until this gets fixed. I wish I had some time now to look at ver 11 to see if I could update the patch.

By: Boris Fox (boris fox) 2013-11-03 05:21:30.331-0600

I can confirm the patch does not work (with 11.5.1). According to debug outputs, code branch with save_codec_maps() just didn't invoked (neither with directrtpsetup on nor with off). I'm still studying chan_sip code, it's too large to get it fast from scratch, but in my opinion the codec maps should be filled somewhere on receiving SDP offer from the caller.

By: J. DARIO ALVAREZ (aldanet) 2013-11-24 15:34:18.580-0600

I fixed all these issues for versions 10 and 11, including DTMF detection,  in a very simple way: Got back to 1.8 and everything works fine!! You can exchange video even between sofphones that use different payload types for the same codec. i.e 103 and 115 for h263+.

It seems that chan_sip must be rewritten. Perhaps the solution is that all stations involved in a call SHOULD match the dynamic payload value offered by the caller, so rtp can be bridged or going directly from caller to callee. I see that 1.8 behaves this way.

I found this link, that explains the negotiation.


Asterisk 10 and 11 match case 1 which is incorrect. Correct (99.9%) is last case where payload type matches the offered one, as 1.8 do.

By: Rusty Newton (rnewton) 2013-12-12 17:20:37.944-0600

Linking with ASTERISK-22789 as they are probably duplicate or related.

By: David Woolley (davidw) 2014-09-03 12:37:22.796-0500

I've observed this with telphony events, admittedly with an absolete version (, but it seems the same basic flaw, so is presumably still an issue, if this one is still open.

Also, it looks like the basic problem was first reported in 2004, but wrongly marked as fixed when it should have just been suspended.  (ASTERISK-1755)

I'm still trying to work out what should happen in this case (should the codec number be passed end to end at the beginning so that it isn't changed in the re-invite?).  Obviously the cheapest way out is to inhibit the re-invite.

By: David Woolley (davidw) 2014-09-04 06:23:36.729-0500

If I understand https://trac.pjsip.org/repos/ticket/1300 correctly, it looks like the strategy used by the main line development of PJSIP was that the re-inviter should assert its default dynamic codec numbers on a re-invite, which, I guess, will work if the other parties follow the SHOULD rule about maching the type in the response, for re-invites, as well as initial ones.

I don't know how that relates to the astererisk use of PJSIP and I haven't checked whether Asterisk copes with a change of payload type number on an incoming re-invite.

One caveat is that Avaya have, apparently, discovered some SIP end points that only accept their choice of payload type for media events: https://downloads.avaya.com/css/P8/documents/100178732 (page 11).