<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">It's exactly where RFCs start to be stupid, IMHO.<div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" color="#1C00FF">David Ponzone </font><font class="Apple-style-span" color="#000000" size="3"><span class="Apple-style-span" style="font-size: 12px; ">Direction Technique</span></font></font></div><div><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 13px; ">email: <a href="mailto:david.ponzone@ipeva.fr">david.ponzone@ipeva.fr</a></span></font></font></div><div><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 13px; ">tel: 01 74 03 18 97</span></font></font></div><div><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 13px; ">gsm: 06 66 98 76 34</span></font></font></div><div><font class="Apple-style-span" face="'Helvetica Neue'"><br></font></div><div><font class="Apple-style-span" color="#1C00FF" face="'Helvetica Neue'">Service Client<span class="Apple-converted-space"> </span></font><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" color="#FF0000">IP</font></font><font class="Apple-style-span" color="#1C00FF" face="'Helvetica Neue'">eva</font></div><div><font class="Apple-style-span" color="#1C00FF" face="'Helvetica Neue'"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Helvetica; "><div><font class="Apple-style-span" face="'Helvetica Neue'"><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 13px; ">tel: 0811 46 26 26</span></font></font></div><div><font class="Apple-style-span" face="'Helvetica Neue'" size="3"><span class="Apple-style-span" style="font-size: 13px; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Arial; color: rgb(0, 34, 243); "><span style="text-decoration: underline; "><a href="BLOCKED::http://www.ipeva.fr/">www.ipeva.fr</a></span><span style="color: rgb(101, 104, 149); "> - <span style="color: rgb(0, 34, 243); text-decoration: underline; "><a href="BLOCKED::http://www.ipeva-studio.com/">www.ipeva-studio.com</a></span></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Arial; color: rgb(0, 34, 243); "><span class="Apple-style-span" style="text-decoration: underline; "><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Arial; color: rgb(0, 34, 243); "><span class="Apple-style-span"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; text-align: justify; font: normal normal normal 10px/normal Arial; color: rgb(192, 192, 192); "><i>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. </i><b><i>IPeva</i></b><i> 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.</i></div><div style="text-decoration: underline; text-align: justify; "><font class="Apple-style-span" color="#C0C0C0"><i><br></i></font></div></span></div></span></font></div></span></font></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div><br><div><div>Le 08/10/2010 à 13:16, Jan Riedinger a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div bgcolor="#ffffff" text="#000000"> Propably you refer RFC 2327:<br> <pre class="newpage"> 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.
</pre> 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> <br> BR<br> Jan<br> <br> <br> Am 08.10.2010 12:48, schrieb David Ponzone: <blockquote cite="mid:3E86F0B9-A2F1-4F7A-979D-2C11F84EC1D7@ipeva.fr" type="cite"> Jan, no ptime means 20ms. <div>That's the RFC.</div> <div><br> <div> <span> <div><span> <div> <div> David Ponzone <span>Direction Technique</span> </div> <div> <span>email: <a moz-do-not-send="true" href="mailto:david.ponzone@ipeva.fr">david.ponzone@ipeva.fr</a></span> </div> <div> <span>tel: 01 74 03 18 97</span> </div> <div> <span>gsm: 06 66 98 76 34</span> </div> <div> <br> </div> <div> Service Client<span> </span> IP eva </div> <div> <span> <div> <span>tel: 0811 46 26 26</span> </div> <div> <span> <div><span><a moz-do-not-send="true" href="BLOCKED::http://www.ipeva.fr/">www.ipeva.fr</a></span><span> - <span><a moz-do-not-send="true" href="BLOCKED::http://www.ipeva-studio.com/">www.ipeva-studio.com</a></span></span></div> <div><span><br> </span></div> <div><span> <div><i>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. </i><b><i>IPeva</i></b><i> 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.</i></div> <div> <i><br> </i> </div> </span></div> </span> </div> </span> </div> </div> </span><br> </div> </span><br> </div> <br> <div> <div>Le 08/10/2010 à 12:40, Jan Riedinger a écrit :</div> <br> <blockquote type="cite"> <div> 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.<br> <br> 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?<br> <br> 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.<br> <br> 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. <br> <br> At next Freeswitch tries to fix "the issue". In the logfile I found:<br> <blockquote>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<br> This issue has so far been identified to happen on the following broken platforms/devices:<br> Linksys/Sipura aka Cisco<br> ShoreTel<br> Sonus/L3<br> We will try to fix it but some of the devices on this list are so broken,<br> who knows what will happen..<br> </blockquote> 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:<br> <pre> 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.</pre> <br> 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. <br> <br> 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.<br> The callee fails to process this re-INVITE and drops the call.<br> <br> 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?<br> <br> 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.<br> <br> <br> Thank you in advance<br> Jan<br> <br> <br> <br> <br> <br> <pre>--
Jan Riedinger Phone : +49-30-39 73 19 66
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
E-Mail: <a moz-do-not-send="true" href="mailto:riedinger@sns.eu">riedinger@sns.eu</a>
SNS Consult GmbH ICQ : 163-237-041
Südwestkorso 49a MSN : <a moz-do-not-send="true" href="mailto:jan@sns-consult.de">jan@sns-consult.de</a>
14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
</pre> </div> <span><Ptime Problem Call Trace.tif></span>_______________________________________________<br> FreeSWITCH-users mailing list<br> <a moz-do-not-send="true" href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br> <a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br> UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br> <a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a><br> </blockquote> </div> <br> </div> <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
FreeSWITCH-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>
</pre> </blockquote> <br> <pre class="moz-signature" cols="72">--
Jan Riedinger Phone : +49-30-39 73 19 66
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:riedinger@sns.eu">riedinger@sns.eu</a>
SNS Consult GmbH ICQ : 163-237-041
Südwestkorso 49a MSN : <a class="moz-txt-link-abbreviated" href="mailto:jan@sns-consult.de">jan@sns-consult.de</a>
14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
</pre> </div> _______________________________________________<br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br></blockquote></div><br></div></body></html>