[Freeswitch-users] Codecs issue
David Ponzone
david.ponzone at ipeva.fr
Mon Jan 17 04:31:08 MSK 2011
Again, read the wiki.
After this example, I wrote:
-FS checks the proposed codecs in order of priority (as listed in the SDP) against its list of allowed codecs (as configured in inbound-codec-prefs), and selects PCMA as the first authorized codec, so the codecs list becomes: PCMA/G729/PCMU.
Basically, that means, that the codec negotiated with A will always be put in the first position of the codecs list sent to B.
At least, that's what I observed during my numerous tests at that time.
I really recommend you do your own home-work in order to understand it.
It really helped me to get it.
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 17/01/2011 à 00:25, Diego Viola a écrit :
> Also, I noticed this on the wiki, in the Early Negotiation example.
>
> A -------- GSM/PCMA/G729 --------> FS (allowing G729/PCMA/PCMU)
> -------- PCMA/G729/PCMU --------> B
>
> Shouldn't that be:
>
> A -------- GSM/PCMA/G729 --------> FS (allowing G729/PCMA/PCMU)
> -------- G729/PCMA/PCMU --------> B
>
> instead?
>
> On Sun, Jan 16, 2011 at 8:24 PM, Diego Viola <diego.viola at gmail.com> wrote:
>> Thanks, I will read that
>>
>> On Sun, Jan 16, 2011 at 8:21 PM, 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> 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/20110117/1eb2676a/attachment-0001.html
More information about the FreeSWITCH-users
mailing list