[Freeswitch-users] Problematic Behaviour of FS regarding ptime negotiation
David Ponzone
david.ponzone at ipeva.fr
Fri Oct 8 04:27:07 PDT 2010
It's exactly where RFCs start to be stupid, IMHO.
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:16, Jan Riedinger a écrit :
> Propably you refer RFC 2327:
> Note that RTP audio formats typically do not include information
> about the number of samples per packet. If a non-default (as
> defined in the RTP Audio/Video Profile) packetisation is
> required,
> the "ptime" attribute is used as given below.
>
> or RFC 4566:
> Note: RTP audio formats typically do not include information
> about the number of samples per packet. If a non-default (as
> defined in the RTP Audio/Video Profile) packetisation is
> required, the "ptime" attribute is used as given above.
>
> IHMO that means, that the default packetisation CAN be used, if
> nothing is specified, but it doesn't mean that it SHOULD be used.
> But even if a ptime is specified, the RFC only says that the
> specified ptime SHOULD be used, what is different from that it HAVE
> to be used. Thus it doesn't breach any RFC, if a device is using
> another packetisation nevertheless.
>
> BR
> Jan
>
>
> Am 08.10.2010 12:48, schrieb 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 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/b33d86f8/attachment.html
More information about the FreeSWITCH-users
mailing list