[asterisk-bugs] [JIRA] Commented: (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=196021#comment-196021 ] 

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

Asterisk is a back to back user agent for multiple technologies.  It started being primarily for circuit switched networks, which do not use RTP.  In principle, it might have technologies added that constrain the codec numbers so that they cannot be aligned with arbitrary SDP ones.

For a normal bridge, media is passed on to the software equivalent of a backplane with standardised codec numbers.  The codec numbers are then remapped by the outgoing side.  It is only during a native bridge, where the same technology driver is handling both sides, that it is even possible to pass through codec numbers unchanged.  The rest of this thread is really just about the native bridging case.

Incidentally one other thing that can cause complications is if the calling party use late offer SDP.  Asterisk generally/always uses early offer SDP.  That means that Asterisk can have told the outgoing side which codec numbers it is going to receive before the caller has told Asterisk which they are.  For a native bridge, this should get resolved, because Asterisk will re-invite, after the late offer has arrived, but for a general case bridge, this issue applies.

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