[Freeswitch-users] Codecs issue

Steven Ayre steveayre at gmail.com
Mon Jan 17 02:23:29 MSK 2011


Oh, and it is allowed in the standard to override a static number with a
rtpmap line for a dynamic codec if you run out of numbers in the dynamic
range, but the unassigned numbers should be used before any of the assigned
ones.

-Steve



On 16 January 2011 23:21, Steven Ayre <steveayre at gmail.com> wrote:

> It's part of the RTP/SDP standards. They're either static or dynamic
> numbers.
>
> Dynamic ones (96-127) are named by name in a=rtpmap lines.
>
> Static numbers are reserved numbers and the a=rtpmap is allowed but
> optional (although some devices incorrectly require it)
> The list of reserved static numbers is:
> http://www.iana.org/assignments/rtp-parameters
>
> -Steve
>
>
>
> On 16 January 2011 23:18, Diego Viola <diego.viola at gmail.com> wrote:
>
>> How do you understand these RTP/AVP numbers?
>>
>>  m=audio 23344 RTP/AVP 3 18 98 99 9 0 8 101 13
>>
>> What does the numbers mean? I don't see that on the wiki.
>>
>> Any help appreciated.
>>
>> On Sun, Jan 16, 2011 at 7:48 PM, David Ponzone <david.ponzone at ipeva.fr>
>> wrote:
>> > That sounds like a bad reading of the trace.
>> > The important line is the 239th:
>> >  m=audio 23344 RTP/AVP 3 18 98 99 9 0 8 101 13
>> > That means codec 3 is sent first (so GSM), then 18 (so G729).
>> > I think you should read a little bit on early negotiation.
>> > If leg A has GSM in 1st position, if your inbound codec list allows GSM,
>> and
>> > your outbound codec list is : G729, PCM, GSM, than your outbound INVITE
>> to
>> > leg B will have GSM in 1st position, because that was requested by leg
>> A.
>> > That's in the wiki, it's a part I rewrote myself some weeks ago, in the
>> most
>> > readable way I could.
>> > David Ponzone  Direction Technique
>> > email: david.ponzone at ipeva.fr
>> > tel:      01 74 03 18 97
>> > gsm:   06 66 98 76 34
>> > Service Client IPeva
>> > tel:      0811 46 26 26
>> > www.ipeva.fr  -   www.ipeva-studio.com
>> > Ce message et toutes les pièces jointes sont confidentiels et établis à
>> > l'intention exclusive de ses destinataires. Toute utilisation ou
>> diffusion
>> > non autorisée est interdite. Tout message électronique est susceptible
>> > d'altération. IPeva décline toute responsabilité au titre de ce message
>> s'il
>> > a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce
>> > message, merci de le détruire immédiatement et d'avertir l'expéditeur.
>> >
>> >
>> >
>> > Le 16/01/2011 à 21:59, Diego Viola a écrit :
>> >
>> > Hello,
>> >
>> > I'm experiencing some strange issue with codecs. I have the following
>> > in my vars.xml file:
>> >
>> >  <X-PRE-PROCESS cmd="set"
>> > data="global_codec_prefs=G729,G7221 at 32000h,G7221 at 16000h
>> ,G722,PCMU,PCMA,GSM"/>
>> >  <X-PRE-PROCESS cmd="set"
>> data="outbound_codec_prefs=G729,PCMU,PCMA,GSM"/>
>> >
>> > "inbound-late-negotiation" and "disable-transcoding" are commented in
>> > my internal SIP profile. So I guess I'm in Early Negotiation (default
>> > behavior) mode.
>> >
>> > However, when I send a call to my provider, and I look at the SIP
>> > trace I see that FS is sending another codec, not G729 as I specified
>> > in the global_codec_prefs / outbound_codec_prefs parameters.
>> >
>> > I'm sending calls like this:
>> >
>> >        <action application="bridge" data="sofia/internal/$
>> 1 at 38.102.93.70"/>
>> >
>> > Here is a SIP trace of a call:
>> >
>> > http://pastebin.freeswitch.org/15042
>> >
>> > I'm not understanding why FS is sending an INVITE with the G7221 codec
>> > in line 240, if I'm telling it explicitly that I want G729 as the
>> > priority when possible in the codec prefs options. But I see G729 in
>> > the 200 OK in line 291.
>> >
>> > I've been told to use absolute_codec_string=G729 in my dialplan or
>> > enable late negotiation, but why if I'm already telling it to use G729
>> > in the codec prefs?
>> >
>> > my softphone IP: 190.23.80.10
>> > provider IP: 38.102.93.70
>> > FS IP: 77.92.65.126
>> >
>> > calls flow like this:
>> >
>> > softphone -> FS -> provider
>> >
>> > Any help appreciated.
>> >
>> > _______________________________________________
>> > FreeSWITCH-users mailing list
>> > FreeSWITCH-users at lists.freeswitch.org
>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > UNSUBSCRIBE:
>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>> > http://www.freeswitch.org
>> >
>> >
>> > _______________________________________________
>> > FreeSWITCH-users mailing list
>> > FreeSWITCH-users at lists.freeswitch.org
>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > UNSUBSCRIBE:
>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>> > http://www.freeswitch.org
>> >
>> >
>>
>>
>>
>> --
>> Diego Viola
>> Representative of Bridgecom LLC
>> Phone: +595 971 320 520
>> GTalk: diego.viola at gmail.com
>> MSN: diegoev at msn.com
>> LinkedIn: http://www.linkedin.com/pub/diego-viola/15/886/609
>> www.bridgecom.com.py
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110116/d9ef1ca5/attachment-0001.html 


More information about the FreeSWITCH-users mailing list