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

David Ponzone david.ponzone at ipeva.fr
Fri Oct 8 04:57:15 PDT 2010


I am out of my league, I would need to dig into the RFCs so I prefer  
to wait for comments from the people who wrote the code, because I am  
sure they have an opinion on how the RFCs should be read or why they  
did what they did.

For the autofix-timing thing, I don't think there is a way to change  
that per gateway or with a channel variable.
So yes, you have to use another IP or same IP with non-standard port.
But you just need 2: one profile with it, one without.

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 à 13:39, Jan Riedinger a écrit :

>
>
> Am 08.10.2010 13:06, schrieb David Ponzone:
>>
>> 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).
> I think this isn't correct. If you work with a codec list in a Cisco  
> and set any byte / frame size values for the codecs of the codec  
> list, the Cisco doesn't specify any ptime in the initial INVITE  
> message, even if for all codecs of the codec list the same frame  
> size is specified. Thus it's risky at this point, if FS assums that  
> the caller wants to use 20 ms
>
>>
>> So, yes, the message displayed by FS is correct at some point:
>> FS asked for 20ms, and your carrier is sending 60ms.
>>
> But the usage of 60 ms nevertheless, is ok according the RFC.
>> 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.
> I configured for a long time a payload of 40 or 60 bytes on my  
> Ciscos, because of the disadvantageous TCP/IP header overhead, if  
> you go with 20 bytes. I asked my business partners to do it in the  
> same way. However, often the didn't change their standard config and  
> continued to use 20 bytes. I had trouble by this asymmetry only once  
> out of more than 200 configured interconnects.
>> 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.... :)
>>
> As you see in the trace graph attached to my previous e-mail, the re- 
> INVITE of FFS results in an "internal server error" at the  
> terminating GW. Of course this shouldn't be the case and doesn't  
> comply with the RFC, but this problem is caused by the efforts of FS  
> to fix a problem, which doesn' exist - at least according the RFC.
>
>> 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.
>>
> Is it possible to use rtp-autofix-timing just for a specific  
> carrier? If I specify it in the default profile, it is used for all  
> carriers. Maybe/Probably I'm wrong, but according my current  
> knowledge I have to use another non standard IP port, if I want to  
> use another profile just for this specific carrier.
>
> BR
>     Jan
>
>> David Ponzone   Direction Technique
>> email: 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
>>
>> 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
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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/dc9807f0/attachment-0001.html 


More information about the FreeSWITCH-users mailing list