-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4093/#review13684
-----------------------------------------------------------



/tags/12.4.0/main/rtp_engine.c
<https://reviewboard.asterisk.org/r/4093/#comment24179>

    This is not compliant to the way L16 is supposed to be declared within SDP. 
The payload name is supposed to remain the same (L16) but the clock rate 
differs.
    
    Did you try that and it did not work, or did you just go for different 
payload names just because?


- Joshua Colp


On Oct. 31, 2014, 1:32 a.m., Frankie Chin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4093/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2014, 1:32 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24274
>     https://issues.asterisk.org/jira/browse/ASTERISK-24274
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Currently SLIN12, SLIN24, SLIN32, SLIN44, SLIN48, SLIN96 and SLIN192 are 
> found not working with SIP. The following error will be thrown if one of 
> those codecs is used: chan_sip.c:10718 process_sdp: No compatible codecs, not 
> accepting this offer! 
> 
> What I think the issue is that the codec format isn't being included in the 
> SDP media attributes when one of those codecs is used. Please refer to 
> ASTERISK-24274 for more details. This change updates the main/rtp_engine.c 
> and main/frame.c to ensure all these codecs are supported.
> 
> Note: SLIN and SLIN16 are working fine.
> 
> 
> Diffs
> -----
> 
>   /tags/12.4.0/main/rtp_engine.c 425756 
>   /tags/12.4.0/main/frame.c 425756 
> 
> Diff: https://reviewboard.asterisk.org/r/4093/diff/
> 
> 
> Testing
> -------
> 
> Specified SLIN48 codec in sip.conf of two Asterisk servers. Used AMI to 
> originate a call from Server A to Server B and then put Server B into a 
> conference hosted in Server A. The above mentioned error was no longer 
> reported and the conference was working as expected.
> 
> 
> Thanks,
> 
> Frankie Chin
> 
>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to