<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Anthony, <br>
<br>
you are writing: "Wanting to send 60 and not actually specifying
it..."<br>
<br>
According my interpretation of the RFC it's just not possible for
gateway to specify the preferred ptime for SENDING. The ptime
specifies the preferred frame size for RECEIVING. <br>
<br>
In the RFC 3264 is written:<br>
<blockquote> If the ptime attribute is present for a stream, it
indicates the<br>
desired packetization interval that the offerer would like to<br>
<font color="#ff0000"><b>RECEIVE</b></font>.<br>
</blockquote>
<br>
Indications that the RFC is to be interpreted in this way can be
found under <br>
<br>
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/docs/ios/12_3/sip/configuration/guide/chapter8.html#wp1064009">http://www.cisco.com/en/US/docs/ios/12_3/sip/configuration/guide/chapter8.html#wp1064009</a><br>
<br>
If you study the examples of this web site for asymmetric SDP you
will find, that the ptime, which was requested by GW A is used from
GW B for sending packets, whereas GW A itself uses the frame size
for sending, which was requested by GW B!<br>
<br>
BR<br>
Jan<br>
<br>
<br>
<br>
<br>
<br>
<br>
Am 08.10.2010 16:18, schrieb Anthony Minessale:
<blockquote
cite="mid:AANLkTin9A+m6koQu5YnEVJs6bFBUzd1_vX_XhhFKf+Wz@mail.gmail.com"
type="cite">Everything you described is how we behave.<br>
We will not be changing it.<br>
<br>
Not specifying the ptime is a giant performance hit because we
cannot<br>
initilize the timers.<br>
Wanting to send 60 and not actually specifying it could also
probably<br>
explained away in some deep interpretation of the RFC but it's not<br>
typical and it's plain foolish.<br>
<br>
The only advice I can give you is to create a dedicated sip
profile<br>
for this call path and configure the codec negotiation to scrooge
and<br>
define G729@60i in your codec config.<br>
<br>
This will make FS use 60ms g729 regardless of what it sees in the
sdp,<br>
this is not optimal for anyone but your one case which is why I
say to<br>
put it in a specific profile.<br>
<br>
<br>
On Fri, Oct 8, 2010 at 6:57 AM, David Ponzone
<a class="moz-txt-link-rfc2396E" href="mailto:david.ponzone@ipeva.fr"><david.ponzone@ipeva.fr></a> wrote:<br>
<blockquote type="cite">I am out of my league, I would need to dig
into the RFCs so I prefer to wait<br>
for comments from the people who wrote the code, because I am
sure they have<br>
an opinion on how the RFCs should be read or why they did what
they did.<br>
For the autofix-timing thing, I don't think there is a way to
change that<br>
per gateway or with a channel variable.<br>
So yes, you have to use another IP or same IP with non-standard
port.<br>
But you just need 2: one profile with it, one without.<br>
David Ponzone Direction Technique<br>
email: <a class="moz-txt-link-abbreviated" href="mailto:david.ponzone@ipeva.fr">david.ponzone@ipeva.fr</a><br>
tel: 01 74 03 18 97<br>
gsm: 06 66 98 76 34<br>
Service Client IPeva<br>
tel: 0811 46 26 26<br>
<a class="moz-txt-link-abbreviated" href="http://www.ipeva.fr">www.ipeva.fr</a> - <a class="moz-txt-link-abbreviated" href="http://www.ipeva-studio.com">www.ipeva-studio.com</a><br>
Ce message et toutes les pièces jointes sont confidentiels et
établis à<br>
l'intention exclusive de ses destinataires. Toute utilisation ou
diffusion<br>
non autorisée est interdite. Tout message électronique est
susceptible<br>
d'altération. IPeva décline toute responsabilité au titre de ce
message s'il<br>
a été altéré, déformé ou falsifié. Si vous n'êtes pas
destinataire de ce<br>
message, merci de le détruire immédiatement et d'avertir
l'expéditeur.<br>
<br>
<br>
<br>
Le 08/10/2010 à 13:39, Jan Riedinger a écrit :<br>
<br>
<br>
Am 08.10.2010 13:06, schrieb David Ponzone:<br>
<br>
Jan,<br>
to answer to 2 others questions you ask:<br>
Why FS tries to enforce 20 ?<br>
Well, the default is 20ms for most codecs, except perhaps G723,
and no<br>
explicit ptime means 20ms for most codecs.<br>
So your carrier is sending no ptime, meaning they want 20.<br>
FS agrees and send back 20 (and explictly, because smart people
always do<br>
things explictly and avoid relying on default
values/behaviours).<br>
<br>
I think this isn't correct. If you work with a codec list in a
Cisco and set<br>
any byte / frame size values for the codecs of the codec list,
the Cisco<br>
doesn't specify any ptime in the initial INVITE message, even if
for all<br>
codecs of the codec list the same frame size is specified. Thus
it's risky<br>
at this point, if FS assums that the caller wants to use 20 ms<br>
<br>
<br>
So, yes, the message displayed by FS is correct at some point:<br>
FS asked for 20ms, and your carrier is sending 60ms.<br>
<br>
But the usage of 60 ms nevertheless, is ok according the RFC.<br>
<br>
Now, I see your point: perhaps the phrase is not very clear.<br>
I think the issue is (and Anthony or Brian will correct me on
this if<br>
required) that FS tries to negotiate the same ptime on both
directions,<br>
because what the RFC says about asymmetrical ptimes is scary,
AFAIK. I heard<br>
people reporting major issues trying to do this.<br>
<br>
I configured for a long time a payload of 40 or 60 bytes on my
Ciscos,<br>
because of the disadvantageous TCP/IP header overhead, if you go
with 20<br>
bytes. I asked my business partners to do it in the same way.
However, often<br>
the didn't change their standard config and continued to use 20
bytes. I had<br>
trouble by this asymmetry only once out of more than 200
configured<br>
interconnects.<br>
<br>
Ok the RFC allows it, but as usual, it was probably badly
implemented by<br>
most vendors, and anyway, there is no real benefit.<br>
<br>
So FS tries to stay simple.<br>
I think that's what FS means by "We were told": the other party
asked us for<br>
20ms, and as we like to keep things simple, we also asked for
20ms, and they<br>
send back 60ms, those p....bast.... :)<br>
<br>
As you see in the trace graph attached to my previous e-mail,
the re-INVITE<br>
of FFS results in an "internal server error" at the terminating
GW. Of<br>
course this shouldn't be the case and doesn't comply with the
RFC, but this<br>
problem is caused by the efforts of FS to fix a problem, which
doesn' exist<br>
- at least according the RFC.<br>
<br>
Basically, I think what you are asking is a new parameter that
would<br>
instruct FS to stop trying to re-packetize and accept
asymmetrical ptimes.<br>
About the message, you can get rid of it with
rtp-autofix-timing=false, but<br>
use it at your own risk.<br>
<br>
Is it possible to use rtp-autofix-timing just for a specific
carrier? If I<br>
specify it in the default profile, it is used for all carriers.<br>
Maybe/Probably I'm wrong, but according my current knowledge I
have to use<br>
another non standard IP port, if I want to use another profile
just for this<br>
specific carrier.<br>
<br>
BR<br>
Jan<br>
<br>
David Ponzone Direction Technique<br>
email: <a class="moz-txt-link-abbreviated" href="mailto:david.ponzone@ipeva.fr">david.ponzone@ipeva.fr</a><br>
tel: 01 74 03 18 97<br>
gsm: 06 66 98 76 34<br>
Service Client IP eva<br>
tel: 0811 46 26 26<br>
<a class="moz-txt-link-abbreviated" href="http://www.ipeva.fr">www.ipeva.fr</a> - <a class="moz-txt-link-abbreviated" href="http://www.ipeva-studio.com">www.ipeva-studio.com</a><br>
Ce message et toutes les pièces jointes sont confidentiels et
établis à<br>
l'intention exclusive de ses destinataires. Toute utilisation ou
diffusion<br>
non autorisée est interdite. Tout message électronique est
susceptible<br>
d'altération. IPeva décline toute responsabilité au titre de ce
message s'il<br>
a été altéré, déformé ou falsifié. Si vous n'êtes pas
destinataire de ce<br>
message, merci de le détruire immédiatement et d'avertir
l'expéditeur.<br>
<br>
<br>
<br>
Le 08/10/2010 à 12:40, Jan Riedinger a écrit :<br>
<br>
I'm terminating various destination by various carriers. After
migrating one<br>
customer to Freeswitch, we observed problems for the termination
of a<br>
specific route for a specific carrier. I tried to examine the
problem in<br>
detail and I think it's related to problems regarding the ptime
negotiation.<br>
I think Freeswitch doesn't breach any RFC, but I'm not sure, if
the<br>
behaviour is optimal.<br>
<br>
The SDP of the Caller INVITE-Message at time 1160,056 in the
attached trace<br>
doesn't include any ptime setting. Nevertheless Freeswitch
includes a<br>
ptime=20 media attribute in the forwarded INVITE message at time
1160,065.<br>
The ringing SDP sent by the callee at time 1161,948 again
doesn't include<br>
any ptime setting. Nevertheless, Freeswitch includes in the
Session Progress<br>
SDP (at time 1164,240) a ptime=20 media atrribute. Why try
Freeswitch to<br>
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.<br>
Nevertheless, the Freeswitch add a ptime=20 media attribute
forwarded to the<br>
caller at 1164,256.<br>
<br>
It seems that the callee is sending in the following with a
frame size of 60<br>
bytes - it never claimed to use ptime=20 and according the RFC
3264 it<br>
SHOULD send with ptime=20 because of the received INVITE message<br>
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>
<br>
e686b430-5d2d-488b-8b58-0fca1965eea7 2010-10-07 15:20:25.673206
[WARNING]<br>
mod_sofia.c:1033 We were told to use ptime 20 but what they
meant to say was<br>
60<br>
This issue has so far been identified to happen on the following
broken<br>
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>
<br>
This log message isn't correct. The callee never specified
anything about<br>
the usage of a specific ptime. Furthermore, according RFC 3264
the ptime<br>
doesn't specify the frame size, which will be used to send
packages by the<br>
side, which specify it in the SDP. In the RFC 3264 is written:<br>
<br>
If the ptime attribute is present for a stream, it indicates the<br>
desired packetization interval that the offerer would like to<br>
receive .<br>
<br>
...<br>
<br>
There is now requirement that the packetization interval be the
same in<br>
each direction for a particular stream.<br>
<br>
IMHO that means, that it isn't possible in principle that a
device is lying<br>
about it's ptime usage, because it only specify by the media
attribute the<br>
packetization it likes to receive and doesn't specify the
packetization it<br>
will use itself.<br>
<br>
For fixing "the problem" Freeswitch sends a re-INVITE message at
1164,777.<br>
This message includes in the message header "X-Broken-PTIME:
Adv=20;<br>
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<br>
"passthru_ptime_mismatch=true" (it's documented in the Wiki
since<br>
yesterday). Does it make sense, that Freeswitch tries to fix any
ptime<br>
setting if this variable is set to true?<br>
<br>
If someone wants to examine this issue more detailed, I can
provide the<br>
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>
--<br>
Jan Riedinger Phone : +49-30-39 73 19 66<br>
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64<br>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:riedinger@sns.eu">riedinger@sns.eu</a><br>
SNS Consult GmbH ICQ : 163-237-041<br>
Südwestkorso 49a MSN : <a class="moz-txt-link-abbreviated" href="mailto:jan@sns-consult.de">jan@sns-consult.de</a><br>
14197 Berlin GERMANY Skype : Jan Riedinger<br>
<br>
AG Charlottenburg - HRB 71973<br>
<br>
<Ptime Problem Call<br>
Trace.tif>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a class="moz-txt-link-abbreviated" 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>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a class="moz-txt-link-abbreviated" 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>
<br>
--<br>
Jan Riedinger Phone : +49-30-39 73 19 66<br>
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64<br>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:riedinger@sns.eu">riedinger@sns.eu</a><br>
SNS Consult GmbH ICQ : 163-237-041<br>
Südwestkorso 49a MSN : <a class="moz-txt-link-abbreviated" href="mailto:jan@sns-consult.de">jan@sns-consult.de</a><br>
14197 Berlin GERMANY Skype : Jan Riedinger<br>
<br>
AG Charlottenburg - HRB 71973<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a class="moz-txt-link-abbreviated" 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>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a class="moz-txt-link-abbreviated" 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>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
-- <br>
Jan Riedinger Phone : +49-30-39 73 19 66<br>
Dipl.-Inf. | Managing Director Fax : +49-30-39 73 19 64<br>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:riedinger@sns.eu">riedinger@sns.eu</a><br>
SNS Consult GmbH ICQ : 163-237-041<br>
Südwestkorso 49a MSN : <a class="moz-txt-link-abbreviated" href="mailto:jan@sns-consult.de">jan@sns-consult.de</a><br>
14197 Berlin GERMANY Skype : Jan Riedinger<br>
<br>
AG Charlottenburg - HRB 71973<br>
</body>
</html>