[Freeswitch-users] Problematic Behaviour of FS regarding ptime negotiation

Anthony Minessale anthony.minessale at gmail.com
Fri Oct 8 08:14:22 PDT 2010 

I already stated my position and supplied you with a solution.
I am on to other issues now.


On Fri, Oct 8, 2010 at 10:03 AM, Jan Riedinger <riedinger at sns.eu> wrote:
> Hi Anthony,
>
> you are writing: "Wanting to send 60 and not actually specifying it..."
>
> 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.
>
> 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.
>
> Indications that the RFC is to be interpreted in this way can be found under
>
> http://www.cisco.com/en/US/docs/ios/12_3/sip/configuration/guide/chapter8.html#wp1064009
>
> 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
>     Jan
>
>
>
>
>
>
> Am 08.10.2010 16:18, schrieb Anthony Minessale:
>
> Everything you described is how we behave.
> We will not be changing it.
>
> Not specifying the ptime is a giant performance hit because we cannot
> initilize the timers.
> Wanting to send 60 and not actually specifying it could also probably
> explained away in some deep interpretation of the RFC but it's not
> typical and it's plain foolish.
>
> The only advice I can give you is to create a dedicated sip profile
> for this call path and configure the codec negotiation to scrooge and
> define G729 at 60i in your codec config.
>
> This will make FS use 60ms g729 regardless of what it sees in the sdp,
> this is not optimal for anyone but your one case which is why I say to
> put it in a specific profile.
>
>
> On Fri, Oct 8, 2010 at 6:57 AM, David Ponzone <david.ponzone at ipeva.fr>
> wrote:
>
> I am out of my league, I would need to dig into the RFCs so I prefer to wait
> for comments from the people who wrote the code, because I am sure they have
> an opinion on how the RFCs should be read or why they did what they did.
> For the autofix-timing thing, I don't think there is a way to change that
> per gateway or with a channel variable.
> So yes, you have to use another IP or same IP with non-standard port.
> But you just need 2: one profile with it, one without.
> 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:39, Jan Riedinger a écrit :
>
>
> Am 08.10.2010 13:06, schrieb David Ponzone:
>
> Jan,
> to answer to 2 others questions you ask:
> Why FS tries to enforce 20 ?
> Well, the default is 20ms for most codecs, except perhaps G723, and no
> explicit ptime means 20ms for most codecs.
> So your carrier is sending no ptime, meaning they want 20.
> FS agrees and send back 20 (and explictly, because smart people always do
> things explictly and avoid relying on default values/behaviours).
>
> 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
>
>
> So, yes, the message displayed by FS is correct at some point:
> FS asked for 20ms, and your carrier is sending 60ms.
>
> But the usage of 60 ms nevertheless, is ok according the RFC.
>
> Now, I see your point: perhaps the phrase is not very clear.
> 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.
>
> 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.
>
> Ok the RFC allows it, but as usual, it was probably badly implemented by
> most vendors, and anyway, there is no real benefit.
>
> So FS tries to stay simple.
> 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.... :)
>
> 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.
>
> 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.
> About the message, you can get rid of it with rtp-autofix-timing=false, but
> use it at your own risk.
>
> 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
>     Jan
>
> 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
>
>
> _______________________________________________
> 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
>
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900

More information about the FreeSWITCH-users mailing list