<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#ffffff" text="#000000">
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
<font color="#ff0000">receive</font>.
...
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 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>
</body>
</html>