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
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client  IP eva
tel:      0811 46 26 26

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@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@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
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@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
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@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.



_______________________________________________

FreeSWITCH-users mailing list

FreeSWITCH-users@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@sns.eu
SNS Consult GmbH                        ICQ   :  163-237-041
Südwestkorso 49a                        MSN   :  jan@sns-consult.de
14197 Berlin GERMANY                    Skype :  Jan Riedinger

AG Charlottenburg - HRB 71973


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@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@sns.eu
SNS Consult GmbH                        ICQ   :  163-237-041
Südwestkorso 49a                        MSN   :  jan@sns-consult.de
14197 Berlin GERMANY                    Skype :  Jan Riedinger

AG Charlottenburg - HRB 71973


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@sns.eu
SNS Consult GmbH                        ICQ   :  163-237-041
Südwestkorso 49a                        MSN   :  jan@sns-consult.de
14197 Berlin GERMANY                    Skype :  Jan Riedinger

AG Charlottenburg - HRB 71973

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@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@sns.eu
SNS Consult GmbH                        ICQ   :  163-237-041
Südwestkorso 49a                        MSN   :  jan@sns-consult.de
14197 Berlin GERMANY                    Skype :  Jan Riedinger

AG Charlottenburg - HRB 71973