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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
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:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-3170 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 306827 
Request Review:              
====================================================================== 
Date Submitted:             2011-02-15 09:00 CST
Last Modified:              2011-04-28 08:12 CDT
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0134228) Boris Fox (reporter) - 2011-04-28 08:12
 https://issues.asterisk.org/view.php?id=18814#c134228 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-04-28 08:12 Boris Fox      Note Added: 0134228                          
======================================================================