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

[David Woolley (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222536#comment-222536 ] 

David Woolley commented on ASTERISK-17410:
------------------------------------------

I've observed this with telphony events, admittedly with an absolete version (1.6.1.0), 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.

> 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 was sent by Atlassian JIRA
(v6.2#6252)