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

[David Ponzone]

Jan, no ptime means 20ms.
That's the RFC.

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/9c8e1b22/attachment.html