[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=222539#comment-222539 ] 

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

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).

> 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)