Problematic Behaviour of FS regarding ptime negotiation
Jan, no ptime means 20ms. That's the RFC. David Ponzone Direction Technique email: david.ponzone@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 à 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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Propably you refer RFC 2327: 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. 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 Jan Am 08.10.2010 12:48, schrieb David Ponzone:
Jan, no ptime means 20ms. That's the RFC.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr <mailto:david.ponzone@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 <BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com <BLOCKED::http://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@sns.eu <mailto:riedinger@sns.eu> SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN :jan@sns-consult.de <mailto:jan@sns-consult.de> 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger AG Charlottenburg - HRB 71973
It's exactly where RFCs start to be stupid, IMHO. David Ponzone Direction Technique email: david.ponzone@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:16, Jan Riedinger a écrit :
Propably you refer RFC 2327: 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.
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 Jan
Am 08.10.2010 12:48, schrieb David Ponzone:
Jan, no ptime means 20ms. That's the RFC.
David Ponzone Direction Technique email: david.ponzone@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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, 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). So, yes, the message displayed by FS is correct at some point: FS asked for 20ms, and your carrier is sending 60ms. 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. 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.... :) 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. David Ponzone Direction Technique email: david.ponzone@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 à 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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@ipeva.fr <mailto:david.ponzone@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 <BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com <BLOCKED::http://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@sns.eu <mailto:riedinger@sns.eu> SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN :jan@sns-consult.de <mailto:jan@sns-consult.de> 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger AG Charlottenburg - HRB 71973
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@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 <Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973 _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
<Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
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.ht... 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@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@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@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
<Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger AG Charlottenburg - HRB 71973
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@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.ht...
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@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@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@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
<Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
I could solve the problem by setting "rtp-autofix-timing=false", which disabled the (too) smart behaviour of FreeSwitch. I'm happy with this solution, but maybe it would helpful in general to enable the setting of this variable channel specific. Thus it would be possible to use standard ports even for interconnects to problematic routes/GWs. BR Jan Am 08.10.2010 17:14, schrieb Anthony Minessale:
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@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.ht...
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@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@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@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
<Ptime Problem Call Trace.tif>_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger
AG Charlottenburg - HRB 71973
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@sns.eu SNS Consult GmbH ICQ : 163-237-041 Südwestkorso 49a MSN : jan@sns-consult.de 14197 Berlin GERMANY Skype : Jan Riedinger AG Charlottenburg - HRB 71973
participants (3)
-
Anthony Minessale
-
David Ponzone
-
Jan Riedinger