[Freeswitch-users] Problematic Behaviour of FS regarding ptime negotiation

Fri Oct 8 04:06:19 PDT 2010

Jan,

to answer to 2 others questions you ask:

Why FS tries to enforce 20 ?
Well, the default is 20ms for most codecs, except perhaps G723, and no  
explicit ptime means 20ms for most codecs.
So your carrier is sending no ptime, meaning they want 20.
FS agrees and send back 20 (and explictly, because smart people always  
do things explictly and avoid relying on default values/behaviours).

So, yes, the message displayed by FS is correct at some point:
FS asked for 20ms, and your carrier is sending 60ms.

Now, I see your point: perhaps the phrase is not very clear.
I think the issue is (and Anthony or Brian will correct me on this if  
required) that FS tries to negotiate the same ptime on both  
directions, because what the RFC says about asymmetrical ptimes is  
scary, AFAIK. I heard people reporting major issues trying to do this.
Ok the RFC allows it, but as usual, it was probably badly implemented  
by most vendors, and anyway, there is no real benefit.
So FS tries to stay simple.
I think that's what FS means by "We were told": the other party asked  
us for 20ms, and as we like to keep things simple, we also asked for  
20ms, and they send back 60ms, those p....bast.... :)

Basically, I think what you are asking is a new parameter that would  
instruct FS to stop trying to re-packetize and accept asymmetrical  
ptimes.
About the message, you can get rid of it with rtp-autofix- 
timing=false, but use it at your own risk.

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 08/10/2010 à 12:40, Jan Riedinger a écrit :

> I'm terminating various destination by various carriers. After  
> migrating one customer to Freeswitch, we observed problems for the  
> termination of a specific route for a specific carrier. I tried to  
> examine the problem in detail and I think it's related to problems  
> regarding the ptime negotiation. I think Freeswitch doesn't breach  
> any RFC, but I'm not sure, if the behaviour is optimal.
>
> The SDP of the Caller INVITE-Message at time 1160,056 in the  
> attached trace doesn't include any ptime setting. Nevertheless  
> Freeswitch includes a ptime=20 media attribute in the forwarded  
> INVITE message at time 1160,065. The ringing SDP sent by the callee  
> at time 1161,948 again doesn't include any ptime setting.  
> Nevertheless, Freeswitch includes in the Session Progress SDP (at  
> time 1164,240) a ptime=20 media atrribute. Why try Freeswitch to  
> force the usage of ptime=20 for the communication?
>
> The OK SDP at time 1164,240 again doesn't contain a ptime media  
> attribute. Nevertheless, the Freeswitch add a ptime=20 media  
> attribute forwarded to the caller at 1164,256.
>
> It seems that the callee is sending in the following with a frame  
> size of 60 bytes - it never claimed to use ptime=20 and according  
> the RFC 3264 it SHOULD send with ptime=20 because of the received  
> INVITE message specification, but it DON'T HAVE to send with ptime=20.
>
> At next Freeswitch tries to fix "the issue". In the logfile I found:
> e686b430-5d2d-488b-8b58-0fca1965eea7 2010-10-07 15:20:25.673206  
> [WARNING] mod_sofia.c:1033 We were told to use ptime 20 but what  
> they meant to say was 60
> This issue has so far been identified to happen on the following  
> broken platforms/devices:
> Linksys/Sipura aka Cisco
> ShoreTel
> Sonus/L3
> We will try to fix it but some of the devices on this list are so  
> broken,
> who knows what will happen..
> This log message isn't correct. The callee never specified anything  
> about the usage of a specific ptime. Furthermore, according RFC  
> 3264  the ptime doesn't specify the frame size, which will be used  
> to send packages by the side, which specify it in the SDP. In the  
> RFC 3264 is written:
>    If the ptime attribute is present for a stream, it indicates the
>    desired packetization interval that the offerer would like to
>    receive.
>
>    ...
>
>    There is now requirement that the packetization interval be the  
> same in each direction for a particular stream.
>
> IMHO that means, that it isn't possible in principle that a device  
> is lying about it's ptime usage, because it only specify by the  
> media attribute the packetization it likes to receive and doesn't  
> specify the packetization it will use itself.
>
> For fixing "the problem" Freeswitch sends a re-INVITE message at  
> 1164,777. This message includes in the message header "X-Broken- 
> PTIME: Adv=20; Sent=60", and ptime = 60 media attribute.
> The callee fails to process this re-INVITE and drops the call.
>
> I made the trace after I set the newly introduced parameter  
> "passthru_ptime_mismatch=true" (it's documented in the Wiki since  
> yesterday). Does it make sense, that Freeswitch tries to fix any  
> ptime setting if this variable is set to true?
>
> If someone wants to examine this issue more detailed, I can provide  
> the Wireshark-cap file of the call and the debug output of Freeswitch.
>
>
> Thank you in advance
>            Jan
>
>
>
>
>
> -- 
> 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
> <Ptime Problem Call  
> Trace.tif>_______________________________________________
> 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/20101008/3e3dcd60/attachment-0001.html 