How to refuse T.38 requests
Hello, My locale UAs do not know anything about T.38 protocol and I want to send a fax to some PSTN subscriber via OVH, my french VoIP provider, in an RTP/PCMA session. This session begins normally but, as soon as OVH's gateway recognizes fax tones from remote and/or locale side, an undesirable UPDATE with SDP for a T.38 session is sent to my side. The problem is that, immediately, FreeSwitch says "200 OK" instead of something like "488 Not acceptable here" and this is the beginning of a dialogue of the deaf which only takes end when remote fax-machine hangs up. I have done several things that I found in the WIKI: In my dialplan added these lines: <action application="set" data="sip_ignore_reinvites=true"/> <action application="set" data="fax_enable_t38=false"/> <action application="set" data="fax_enable_t38_request=false"/> In ~/conf/vars.xml: <X-PRE-PROCESS cmd="set" data="refuse_t38=true"/> In ~/conf/sip_profiles/external/sip.ovh.fr.xml: <param name="t38-passthru" value="false"/> But without better result. This is an example of the UPDATE request: UPDATE sip:gw+sip.ovh.fr@92.146.52.82:5080;transport=udp;gw=sip.ovh.fr SIP/2.0 Call-ID: 9686bdc8-e997-1231-27aa-001fc61584f4 Contact: <sip:10.7.1.60:5060> Content-Type: application/sdp Cseq: 29265730 UPDATE From: <sip:0556ZZZZZZ@sip.ovh.fr>;tag=00-08184-01c44a83-0e1305300 Max-Forwards: 30 Record-Route: <sip:91.121.129.20:5060;lr> To: \"0033972XXXXXX\" <sip:0033972XXXXXX@sip.ovh.fr>;tag=75761tHD7541g Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-DIVG-481b17bf-03a84e77 User-Agent: Cirpack/v4.56 (gw_sip) Content-Length: 299 v=0 o=cp10 138814832168 138814832170 IN IP4 10.7.1.132 s=SIP Call c=IN IP4 91.121.128.144 t=0 0 m=image 35996 udptl t38 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxRateManagement:TransferredTCF a=T38FaxMaxBuffer:1000 a=T38FaxMaxDatagram:200 a=T38FaxUdpEC:t38UDPRedundancy And that is the OK answer: SIP/2.0 200 OK Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-DIVG-481b17bf-03a84e77 Record-Route: <sip:91.121.129.20:5060;lr> From: <sip:0556ZZZZZZ@sip.ovh.fr>;tag=00-08184-01c44a83-0e1305300 To: \"0033972XXXXXX\" <sip:0033972XXXXXX@sip.ovh.fr>;tag=75761tHD7541g Call-ID: 9686bdc8-e997-1231-27aa-001fc61584f4 Cseq: 29265730 UPDATE Contact: <sip:gw+sip.ovh.fr@92.146.52.82:5080>;transport=udp;gw=sip.ovh.fr User-Agent: FreeSWITCH-mod_sofia/1.5.8b+git~20131213T181356Z~87751f9eaf~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 201 v=0 o=FreeSWITCH 1388128642 1388128643 IN IP4 92.146.52.82 s=FreeSWITCH CH c=IN IP4 92.146.52.82 t=0 0 m=audio 19678 RTP/AVP 8 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Any help much appreciated, thanks in advance...
Hello, As you can see, the 200 OK message to the Update does not include t.38. So, this would be a bug on your service provider if they continue to do t.38. Almost all service providers have the ability to turn off t.38 per account. I'd suggest you talk to your service provider. Regards, Ali Pey On Fri, Dec 27, 2013 at 12:51 PM, gegetel <geo.cherchetout@laposte.net>wrote:
Hello,
My locale UAs do not know anything about T.38 protocol and I want to send a fax to some PSTN subscriber via OVH, my french VoIP provider, in an RTP/PCMA session. This session begins normally but, as soon as OVH's gateway recognizes fax tones from remote and/or locale side, an undesirable UPDATE with SDP for a T.38 session is sent to my side. The problem is that, immediately, FreeSwitch says "200 OK" instead of something like "488 Not acceptable here" and this is the beginning of a dialogue of the deaf which only takes end when remote fax-machine hangs up.
I have done several things that I found in the WIKI:
In my dialplan added these lines:
<action application="set" data="sip_ignore_reinvites=true"/> <action application="set" data="fax_enable_t38=false"/> <action application="set" data="fax_enable_t38_request=false"/>
In ~/conf/vars.xml:
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
In ~/conf/sip_profiles/external/sip.ovh.fr.xml:
<param name="t38-passthru" value="false"/>
But without better result.
This is an example of the UPDATE request:
UPDATE sip:gw+sip.ovh.fr@92.146.52.82:5080;transport=udp;gw=sip.ovh.frSIP/2.0 Call-ID: 9686bdc8-e997-1231-27aa-001fc61584f4 Contact: <sip:10.7.1.60:5060> Content-Type: application/sdp Cseq: 29265730 UPDATE From: <sip:0556ZZZZZZ@sip.ovh.fr>;tag=00-08184-01c44a83-0e1305300 Max-Forwards: 30 Record-Route: <sip:91.121.129.20:5060;lr> To: \"0033972XXXXXX\" <sip:0033972XXXXXX@sip.ovh.fr>;tag=75761tHD7541g Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-DIVG-481b17bf-03a84e77 User-Agent: Cirpack/v4.56 (gw_sip) Content-Length: 299
v=0 o=cp10 138814832168 138814832170 IN IP4 10.7.1.132 s=SIP Call c=IN IP4 91.121.128.144 t=0 0 m=image 35996 udptl t38 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxRateManagement:TransferredTCF a=T38FaxMaxBuffer:1000 a=T38FaxMaxDatagram:200 a=T38FaxUdpEC:t38UDPRedundancy
And that is the OK answer:
SIP/2.0 200 OK Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-DIVG-481b17bf-03a84e77 Record-Route: <sip:91.121.129.20:5060;lr> From: <sip:0556ZZZZZZ@sip.ovh.fr>;tag=00-08184-01c44a83-0e1305300 To: \"0033972XXXXXX\" <sip:0033972XXXXXX@sip.ovh.fr>;tag=75761tHD7541g Call-ID: 9686bdc8-e997-1231-27aa-001fc61584f4 Cseq: 29265730 UPDATE Contact: <sip:gw+sip.ovh.fr@92.146.52.82:5080>;transport=udp;gw=sip.ovh.fr User-Agent: FreeSWITCH-mod_sofia/1.5.8b+git~20131213T181356Z~87751f9eaf~64bit Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 201
v=0 o=FreeSWITCH 1388128642 1388128643 IN IP4 92.146.52.82 s=FreeSWITCH CH c=IN IP4 92.146.52.82 t=0 0 m=audio 19678 RTP/AVP 8 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Any help much appreciated, thanks in advance...
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Le 30/12/2013 15:48, *Ali Pey* wrote:
Hello,
As you can see, the 200 OK message to the Update does not include t.38. So, this would be a bug on your service provider if they continue to do t.38.
I saw this message does not include t.38 and whas suspecting my provider's behaviour to be wrong. Now I am sure. But is "OK" the best answer to an *only t.38* request ? Is not there a way to have FreeSwitch rejecting more firmly such a request ?
Almost all service providers have the ability to turn off t.38 per account. I'd suggest you talk to your service provider.
OK, I am preparing a complaint with, now, one more strong argument. Not sure to be proved right because I am a very small customer... Thank you very much for your answer.
200 OK is a proper respond in this scenario as FS did receive the Update for an existing SIP session. Codec negotiation is a different story and is negotiated through SDP (Offer/Answer). If FS responds with a 4XX response code, the call would very likely be dropped which probably be a less desired outcome. Regards, Ali Pey On Mon, Dec 30, 2013 at 12:04 PM, gegetel <geo.cherchetout@laposte.net>wrote:
Le 30/12/2013 15:48, *Ali Pey* wrote:
Hello,
As you can see, the 200 OK message to the Update does not include t.38. So, this would be a bug on your service provider if they continue to do t.38.
I saw this message does not include t.38 and whas suspecting my provider's behaviour to be wrong. Now I am sure. But is "OK" the best answer to an *only t.38* request ? Is not there a way to have FreeSwitch rejecting more firmly such a request ?
Almost all service providers have the ability to turn off t.38 per account. I'd suggest you talk to your service provider.
OK, I am preparing a complaint with, now, one more strong argument. Not sure to be proved right because I am a very small customer...
Thank you very much for your answer.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
This is true, The spec is a little wishy washy here, some devices can go 488 and fall back go g711 but many will not. -- Brian West brian@freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Dec 30, 2013, at 12:03 PM, Ali Pey <alipey@gmail.com> wrote:
If FS responds with a 4XX response code, the call would very likely be dropped which probably be a less desired outcome.
Le 30/12/2013 19:03, *Ali Pey* wrote:
200 OK is a proper respond in this scenario as FS did receive the Update for an existing SIP session. Codec negotiation is a different story and is negotiated through SDP (Offer/Answer).
If FS responds with a 4XX response code, the call would very likely be dropped which probably be a less desired outcome.
Here you can see what happens when I send successfully a fax with Ekiga as an ATA, directly from my pc: http://cjoint.com/?0LFqxM5ew40 Yes, two loaded pages (and many more in other times) with 0 error at 14400 bit/s, this is possible with some softphones. :-) Here you can see what happens when I attempt to send a fax through FreeSwitch: http://cjoint.com/?0LFqzE3zgXj (In the two cases, the same account and the same sip provider are used.) And the errors displayed in red letters in FreeSwitch console: http://cjoint.com/?0LFqADKuAaY I am not pretending FreeSwitch doesn't work correctly, I whas only wishing to know if some setting exists to make possible sending classical faxes via my sip provider...
Le 30/12/2013 19:03, *Ali Pey* wrote:
200 OK is a proper respond in this scenario as FS did receive the Update for an existing SIP session. Codec negotiation is a different story and is negotiated through SDP (Offer/Answer).
But why does FS receive such an UPDATE request unstead of an INVITE one ? Is this because the "UPDATE" string is included in the "allow:" field it sends in its own INVITE requests ? Is it possible to have FS not including this string ? And how could I have this string not included ?
If FS responds with a 4XX response code, the call would very likely be dropped which probably be a less desired outcome.
With other UACs I use, responding 488 to an INVITE request from OVH (my VoIP provider) does not drop the call. OVH sends quickly a new INVITE with compatible SDP and the call goes on. So I should prefer to receive an INVITE... and see what happens.
Your carrier is sending the Update message and not the Invite, so you should ask them. FS, supports Update and that's why it's in the Allow message. I'm not sure if and how you can remove an allow parameter and I don't think that would make a difference. Ask your carrier to send a Re-Invite if you prefer that. Also, if you are behind a proxy servers such as OpenSIPS, you can do certain message manipulation to force certain behavior. Regards, Ali Pey On Mon, Jan 20, 2014 at 12:17 PM, geo cherchetout < geo.cherchetout@laposte.net> wrote:
Le 30/12/2013 19:03, *Ali Pey* wrote:
200 OK is a proper respond in this scenario as FS did receive the Update for an existing SIP session. Codec negotiation is a different story and is negotiated through SDP (Offer/Answer).
But why does FS receive such an UPDATE request unstead of an INVITE one ? Is this because the "UPDATE" string is included in the "allow:" field it sends in its own INVITE requests ? Is it possible to have FS not including this string ? And how could I have this string not included ?
If FS responds with a 4XX response code, the call would very likely be dropped which probably be a less desired outcome.
With other UACs I use, responding 488 to an INVITE request from OVH (my VoIP provider) does not drop the call. OVH sends quickly a new INVITE with compatible SDP and the call goes on. So I should prefer to receive an INVITE... and see what happens.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Le 20/01/2014 21:45, *Ali Pey* wrote :
Your carrier is sending the Update message and not the Invite, so you should ask them. FS, supports Update and that's why it's in the Allow message. I'm not sure if and how you can remove an allow parameter and I don't think that would make a difference.
Ask your carrier to send a Re-Invite if you prefer that. Also, if you are behind a proxy servers such as OpenSIPS, you can do certain message manipulation to force certain behavior.
OK, thank you very much. I could easily delete "UPDATE, " in "allow:" field sent by FreeSwitch using SIPProxy http://sourceforge.net/projects/sipproxy/ since I already used SIPProxy to modify messages sent by other clients like Linphone, but I can't figure out what I have to set in FS to have all SIP messages sent and received through SIPProxy. In a client like Linphone, this setting is easy : [proxy_3] reg_proxy=<sip:192.168.1.6:5064> # SIPProxy IP:port reg_route=<sip:192.168.1.6:5064> # SIPProxy IP:port reg_identity=sip:0033972XXXXXX@sip.ovh.fr But how to set reg_proxy and reg_route or equivalents in FreeSwitch ?
The refuse_t38 by itself is usually enough. Its possible that since the provider is using update instead of invites, that the update is being auto 200ok by the sofia stack and not giving fs a chance to refuse it. On Jan 24, 2014 7:27 AM, "gegetel" <geo.cherchetout@laposte.net> wrote:
Le 20/01/2014 21:45, *Ali Pey* wrote :
Your carrier is sending the Update message and not the Invite, so you should ask them. FS, supports Update and that's why it's in the Allow message. I'm not sure if and how you can remove an allow parameter and I don't think that would make a difference.
Ask your carrier to send a Re-Invite if you prefer that. Also, if you are behind a proxy servers such as OpenSIPS, you can do certain message manipulation to force certain behavior.
OK, thank you very much. I could easily delete "UPDATE, " in "allow:" field sent by FreeSwitch using SIPProxy http://sourceforge.net/projects/sipproxy/ since I already used SIPProxy to modify messages sent by other clients like Linphone, but I can't figure out what I have to set in FS to have all SIP messages sent and received through SIPProxy. In a client like Linphone, this setting is easy :
[proxy_3] reg_proxy=<sip:192.168.1.6:5064> # SIPProxy IP:port reg_route=<sip:192.168.1.6:5064> # SIPProxy IP:port reg_identity=sip:0033972XXXXXX@sip.ovh.fr
But how to set reg_proxy and reg_route or equivalents in FreeSwitch ?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Le 24/01/2014 15:52, *Anthony Minessale* wrote :
The refuse_t38 by itself is usually enough. Its possible that since the provider is using update instead of invites, that the update is being auto 200ok by the sofia stack and not giving fs a chance to refuse it.
Thank you Anthony for this advice confirming my hypothesis...
participants (5)
-
Ali Pey
-
Anthony Minessale
-
Brian West
-
gegetel
-
geo cherchetout