<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Am 08.10.2010 13:06, schrieb David Ponzone:
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
Jan,
<div><br>
</div>
<div>to answer to 2 others questions you ask:</div>
<div><br>
</div>
<div>Why FS tries to enforce 20 ?</div>
<div>Well, the default is 20ms for most codecs, except perhaps
G723, and no explicit ptime means 20ms for most codecs.</div>
<div>So your carrier is sending no ptime, meaning they want 20.</div>
<div>FS agrees and send back 20 (and explictly, because smart
people always do things explictly and avoid relying on default
values/behaviours).</div>
</blockquote>
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<br>
<br>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div><br>
</div>
<div>So, yes, the message displayed by FS is correct at some
point:</div>
<div>FS asked for 20ms, and your carrier is sending 60ms.</div>
<div><br>
</div>
</blockquote>
But the usage of 60 ms nevertheless, is ok according the RFC.<br>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div>Now, I see your point: perhaps the phrase is not very clear.</div>
<div>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.</div>
</blockquote>
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.<br>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div>Ok the RFC allows it, but as usual, it was probably badly
implemented by most vendors, and anyway, there is no real
benefit.</div>
</blockquote>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div>So FS tries to stay simple.</div>
<div>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.... :)</div>
<div><br>
</div>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div>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.</div>
<div>About the message, you can get rid of it with
rtp-autofix-timing=false, but use it at your own risk.</div>
<div> <br>
</div>
</blockquote>
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>
<br>
BR <br>
Jan <br>
<br>
<blockquote cite="mid:E18C5FFA-F9BD-43F0-9697-1BCC7A7176C3@ipeva.fr"
type="cite">
<div> </div>
<div><span> David Ponzone </span><span> <span>Direction
Technique</span> </span></div>
<div>
<div><span>
<div><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>
</body>
</html>