[Freeswitch-users] mod_com_g729 licences used even without transcoding
Jan Riedinger
riedinger at sns.eu
Mon Oct 4 14:08:02 PDT 2010
I'm doing voip configuration for about 8 years. Because of the
overhead of the tcp/ip header I usually configured my Ciscos to use g729
with a frame size of 40 or 60 bytes. This setting is pretty often
ignored by the other side. Thus it happens often that both sides are
sending with different frame sizes. However, I remember only one case,
where this caused any problems.
Thus my preferred behaviour for mod_com_g729 would be, that it doesn't
re-packetize and pass the packet in pass through mode for g729 to g729
calls, until it isn't configured explicitly in another manner. A licence
should be only used and transcoding should be only done, if caller and
callee are using different codecs.
It seems that there are three variants to handle g729 to g729 calls
with different ptime on the side of caller and callee:
1.
Encode and decode packets with the correct ptime.
Advantages:
Exclusion of jitter problems
Assurance that the correct ptime is used on the side of caller and callee.
Disadvantages:
High expenses for licences and CPU load
2.
Re-packetizing without de- and encoding
Advantages:
Low CPU load, no licences are needed
DisadvantagesI
According Anthony there could be a jitter problem, because a wrong ptime
is used to both sides.
3.
Pass-through the packages untouched
Advantages:
Lowest CPU usage, no licences are needed
Disadvantages:
In some - according my experience very very rare cases - there could be
an incompatibility between caller and callee because of the usage of a
different ptime.
I assume that mode_g729 is working with variant 3, thus it can't be such
a bad option. As I explained above, I would like to go with this variant.
Of course, the very best solution would be, to make the behaviour
configurable per profile or even better per call. But I don't know if
this can be done with a reasonable effort.
BR
Jan
Am 04.10.2010 21:07, schrieb David Ponzone:
> Tony,
>
> I'd rather have a consistent ptime between both legs, but I just
> noticed that the new carrier I use does not honor my request to use a
> ptime else than 20ms.
> They just send back 20ms.
> I will solve that with them sooner or later, but I suppose I am not
> the only one in this situation.
>
> David Ponzone Direction Technique
> email: david.ponzone at ipeva.fr <mailto:david.ponzone at ipeva.fr>
> tel: 01 74 03 18 97
> gsm: 06 66 98 76 34
>
> Service Client IP eva
> tel: 0811 46 26 26
> www.ipeva.fr <BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com
> <BLOCKED::http://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 04/10/2010 à 19:34, Anthony Minessale a écrit :
>
>> because it's based on G.711 the original codec used.
>>
>> It's a balance of latency to packet len.
>>
>> G.729 is poorly packetized at 20ms with only 10 bytes per payload.
>>
>> We can do something to make it work the way you want, but then I
>> refuse to care if you get jittery calls because you are sending the
>> wrong ptime in both directions.
>>
>>
>>
>> On Mon, Oct 4, 2010 at 12:18 PM, Jan Riedinger <riedinger at sns.eu
>> <mailto:riedinger at sns.eu>> wrote:
>>> I'm trying to do wholesale business with some dozen of
>>> interconnects. It's
>>> hopeless to force all customers/clients to use the same ptime - and
>>> I think
>>> there is no real reason to force them. I'm already happy, if they
>>> all offer
>>> the usage of g729 ;-). Often they pass through the calls themselves.
>>>
>>> BTW - I never understood, why 20 ms is the default frame size. In
>>> this way
>>> you have about 20 bytes payload and 40 bytes overhead for the TCP/IP
>>> header,
>>> which is a pretty bad ratio.
>>>
>>> BR
>>> Jan
>>>
>>> Am 04.10.2010 18:56, schrieb David Ponzone:
>>>
>>> You could also check with your carrier why they dont accept the
>>> custom ptime
>>> you need, or normalize your customers' config.
>>> I have a nice extension I made that denies calls if ptime is not
>>> 20ms, with
>>> early-neg or late-neg:
>>> <extension name="check-ptime" continue="true">
>>> <condition field="${sip_use_codec_ptime}" expression="20"
>>> break="on-true"/>
>>> <condition field="${ep_codec_string}" expression="@20i">
>>> <anti-action application="respond" data="488"/>
>>> <anti-action application="hangup" data="88"/>
>>> </condition>
>>> </extension>
>>> David Ponzone Direction Technique
>>> email: david.ponzone at ipeva.fr <mailto:david.ponzone at ipeva.fr>
>>> tel: 01 74 03 18 97
>>> gsm: 06 66 98 76 34
>>> Service Client IP eva
>>> tel: 0811 46 26 26
>>> www.ipeva.fr - www.ipeva-studio.com <http://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 04/10/2010 à 18:11, Jan Riedinger a écrit :
>>>
>>> I think, it would be a could idea to make it configurable, if
>>> mod_com_g729
>>> shall decode/encode the stream to re-packetize. With the current
>>> behaviour
>>> its usage is too expensive for me in respect of money needed for
>>> licences
>>> and CPU power. Most of my calls are calls are g729 to g729,
>>> transcodeding is
>>> needed only very rare.
>>>
>>>
>>>
>>> Am 04.10.2010 17:46, schrieb David Ponzone:
>>>
>>> I just discovered a situation like that.
>>> If the ptime of leg A and leg B does not match, FS will
>>> decode/encode the
>>> stream in order to re-packetize (despite the fact that mod_com_g729 is
>>> capable to re-packetize even without any license installed).
>>> I was thinking that it was not optimal, but Anthony explained some
>>> minutes
>>> ago on #freeswitch why this was the preferred behaviour, despite the
>>> quality
>>> loss it causes.
>>> David Ponzone Direction Technique
>>> email: david.ponzone at ipeva.fr <mailto:david.ponzone at ipeva.fr>
>>> tel: 01 74 03 18 97
>>> gsm: 06 66 98 76 34
>>> Service Client IP eva
>>> tel: 0811 46 26 26
>>> www.ipeva.fr - www.ipeva-studio.com <http://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 04/10/2010 à 17:20, Jan Riedinger a écrit :
>>>
>>> Using http://files.freeswitch.org/g729/fsg729-158-installer really did
>>> fix the issue described below.
>>>
>>> However, it seems that the licence is used (up), even if there is no
>>> transcoding needed. In my CDR I find for all calls, for which G729 is
>>> involed at all,
>>>
>>> read_codec="G729", read_rate="8000", write_codec="G729",
>>> write_rate="8000"
>>>
>>> Nevertheless, all of these calls use a G729 licence. Is there any way to
>>> find out, why mod_com_g729 wants to do any kind of transcoding?
>>>
>>> BR
>>> Jan
>>>
>>> now the cod
>>>
>>> Am 04.10.2010 15:15, schrieb Brian West:
>>>
>>> http://files.freeswitch.org/g729/fsg729-158-installer
>>>
>>> Just the CDN doesn't have the index updated yet. That will fix your
>>> issue.
>>>
>>> /b
>>>
>>> On Oct 4, 2010, at 8:09 AM, David Ponzone wrote:
>>>
>>> Nope, you have to install them manually.
>>>
>>> Current is v158.
>>>
>>> You can download it from the same place than 153, but via direct URL
>>> only.
>>>
>>> It's still Beta I think.
>>>
>>> David Ponzone Direction Technique
>>>
>>> email: david.ponzone at ipeva.fr <mailto: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 <http://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.
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> FreeSWITCH-users mailing list
>>>
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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
>>>
>>> --
>>> Jan Riedinger Phone : +49-30-39 73 19 66
>>> Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
>>> E-Mail: riedinger at sns.eu
>>> <mailto:riedinger at sns.eu>
>>> SNS Consult GmbH ICQ : 163-237-041
>>> Südwestkorso 49a MSN : jan at sns-consult.de
>>> <mailto:jan at sns-consult.de>
>>> 14197 Berlin GERMANY Skype : Jan Riedinger
>>>
>>> AG Charlottenburg - HRB 71973
>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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
>>> <mailto: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
>>>
>>> --
>>> Jan Riedinger Phone : +49-30-39 73 19 66
>>> Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
>>> E-Mail: riedinger at sns.eu
>>> <mailto:riedinger at sns.eu>
>>> SNS Consult GmbH ICQ : 163-237-041
>>> Südwestkorso 49a MSN : jan at sns-consult.de
>>> <mailto:jan at sns-consult.de>
>>> 14197 Berlin GERMANY Skype : Jan Riedinger
>>>
>>> AG Charlottenburg - HRB 71973
>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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
>>>
>>> --
>>> Jan Riedinger Phone : +49-30-39 73 19 66
>>> Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
>>> E-Mail: riedinger at sns.eu
>>> <mailto:riedinger at sns.eu>
>>> SNS Consult GmbH ICQ : 163-237-041
>>> Südwestkorso 49a MSN : jan at sns-consult.de
>>> <mailto:jan at sns-consult.de>
>>> 14197 Berlin GERMANY Skype : Jan Riedinger
>>>
>>> AG Charlottenburg - HRB 71973
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> <mailto: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
>>>
>>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _______________________________________________
>> 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
--
Jan Riedinger Phone : +49-30-39 73 19 66
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
E-Mail: riedinger at sns.eu
SNS Consult GmbH ICQ : 163-237-041
Südwestkorso 49a MSN : jan at sns-consult.de
14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20101004/f3574994/attachment-0001.html
More information about the FreeSWITCH-users
mailing list