[asterisk-bugs] [JIRA] Updated: (ASTERISK-17410) Video dynamic RTP payload type negotiation incorrect when directmedia enabled

[Scoops Adamczyk (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-17410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scoops Adamczyk updated ASTERISK-17410:
---------------------------------------

    Attachment: rtp_payload_patches.tgz

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


> Video dynamic RTP payload type negotiation incorrect when directmedia enabled
> -----------------------------------------------------------------------------
>
>                 Key: ASTERISK-17410
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17410
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 1.8.2
>            Reporter: boris fox
>            Severity: Minor
>         Attachments: debug(2).txt, debug(3).txt, debug.txt, full, full(2), full(3), pm10-410-409-calling-sip_only.pcap, pm9-410-409-called-sip_only.pcap, rtp_payload_patches.tgz, sip.conf, sip.conf(2)
>
>
> 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.
> ****** ADDITIONAL INFORMATION ******
> Traces collected at version 1.8.2.2, but problem still persists in the current svn trunk revision.
> Operating system is CentOS release 5.5.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira