[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