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

[Artem Makhutov (JIRA)]

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

Artem Makhutov edited comment on ASTERISK-17410 at 8/14/12 6:40 AM:
--------------------------------------------------------------------

This problem still exists with Asterisk 10 and 11 and no only affects video but also audio calls.

When using directrtp asterisk should keep the rtpmap payload ID of the original offer. Instead it set's it's own ID in the ReINVITE.
This breaks all directrtp calls where the internal RTP payload ID of the phone is different from what asterisk is using.

When not using directrtp the rtp engine of asterisk is reweriting the payload ID of the RTP stream so that if machtes all devices - this can't be done in a direct RTP setup.

Example - both phones are using an internal payload ID of 116 for ILBC, asterisk is using 97 (as definced in main/rtp_engine.c):
Initial Invite of Phone A:
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20

ReINVITE send to Phone B:
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20

Result:
Phone A is sending a RTP stream with payload ID 116 to phone B, but phone B excepts the RTP stream to have a payload ID of 97.
This results in no audio be playing back by Phone B and vice versa.

      was (Author: artem):
    This problem still exists with Asterisk 10 and 11 and no only affects video but also audio calls.

When using directrtp asterisk should keep the rtpmap payload ID of the original offer. Instead it set's it's own ID in the ReINVITE.
This breaks all directrtp calls where the internal RTP payload ID of the phone is different from what asterisk is using.

When not using directrtp the rtp engine of asterisk is reweriting the payload ID of the RTP stream so that if machtes all devices - this can't be done in a direct RTP setup.

Example - both phones are using an internal payload ID of 116 for ILBC, asterisk is using 97 (as definced in main/rtp_engine.c):
Initial Invite of Phone A:
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20

ReINVITE send to Phone B:
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30

Result:
Phone A is sending a RTP stream with payload ID 116 to phone B, but phone B excepts the RTP stream to have a payload ID of 97.
This results in no audio be playing back by Phone B and vice versa.
  
> 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