Changes between Initial Version and Version 1 of Ticket #1794


Ignore:
Timestamp:
Sep 24, 2014 10:24:27 AM (10 years ago)
Author:
nanang
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1794 – Description

    initial v1  
    11Scenario: 
    2  1. make call using pjsua with G.722.1 multiple bitrates in SDP offer, e.g: 
     2 1. SDP offer G.722.1 multiple bitrates, e.g: 
    33    {{{ 
    44a=rtpmap:118 G7221/16000 
    … …  
    77a=fmtp:119 bitrate=32000 
    88    }}} 
    9  2. receive call answer, but the SDP answer specifies the second format/bitrate (from the offer), e.g: 
     9 2. SDP answer specifies the second bitrate (from the offer), e.g: 
    1010    {{{ 
    1111a=rtpmap:119 G7221/16000 
    … …  
    1414 
    1515The SDP negotiator seems to handle this already, i.e: it negotiates the bitrate in SDP fmtp too (instead of only matching the encoding name and the clock rate). But there are two problems: 
    16  1. as stream only matches encoding name, clock rate, and channel count, it may get wrong remote payload type so the remote will complain with wrong payload type in its received RTP packets. 
    17  1. as codec manager cannot differentiate G.722.1 based on the bitrate, the stream gets wrong G.722.1 codec parameters and open the codec using that wrong param, this leads to assertion or garbled audio. 
     16 1. as SDP answerer: as stream only matches encoding name, clock rate, and channel count, it may get wrong remote payload type so the remote will complain with wrong payload type in its received RTP packets. 
     17 1. as SDP offerer & answerer: as codec manager cannot differentiate G.722.1 based on the bitrate, the stream gets wrong G.722.1 codec parameters and open the codec using that wrong param, this leads to assertion or garbled audio. 
    1818 
    1919Thanks to Brian Walker for the report.