[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