[asterisk-bugs] [Asterisk 0018814]: Video dynamic RTP payload type negotiation incorrect when directmedia enabled

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18814 
====================================================================== 
Reported By:                Boris Fox
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18814
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 306827 
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             2011-02-15 09:00 CST
Last Modified:              2011-02-16 15:42 CST
====================================================================== 
Summary:                    Video dynamic RTP payload type negotiation incorrect
when directmedia enabled
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 [192.168.70.10] is the calling party, 409 at PM9
[192.168.70.9] 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0132047) lmadsen (administrator) - 2011-02-16 15:42
 https://issues.asterisk.org/view.php?id=18814#c132047 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-16 15:42 lmadsen        Note Added: 0132047                          
2011-02-16 15:42 lmadsen        Status                   new => closed       
2011-02-16 15:42 lmadsen        Resolution               open => no change
required
======================================================================