Hi, we are experiencing problems with DTMF between Snom Sip Phones and FS. The DMTF Type is set to SIP INFO (sip info only on Snom Phones). We could nail it down to a missing "telephone-event" parameter in sip sdp: INVITE sip:***6@spklw.x;user:phone SIP/2.0 Via: SIP/2.0/UDP ip:5060;branch=z9hG4bK-15eyqwai33r1;rport From: "Test" <sip:8000@spklw.x>;tag=qqnbrunjmq To: <sip:***6@spklw.x;user:phone> Call-ID: 3c33e6c729b3-t9yol2613q6v CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:8000@ip:5060;line=9lwqdnrx>;reg-id=1 X-Serialnumber: 000413262C33 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom370/8.4.32 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 244 v=0 o=root 334284706 334284706 IN IP4 phoneip s=call c=IN IP4 phoneip t=0 0 m=audio 12610 RTP/AVP 8 9 a=direction:both a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a:ptime:20 a=rtcp-xr:stat-summary=loss,dup,jitt a=sendrecv That resulted in sofia_glue.c disabling DTMF. A slight change in sofia_glue.c (Line 4839 in commit 71964f61ac4817ecfc516edaf4b643f41236868d) did the trick for us: if (tech_pvt->dtmf_type == DTMF_INFO) { //EWETEL } else { //EWETEL switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, "Disable 2833 dtmf\n"); switch_channel_set_variable(tech_pvt->channel, "dtmf_type", "none"); tech_pvt->dtmf_type = DTMF_NONE; te = tech_pvt->recv_te = 0; } //EWETEL Now the question is: Is this a too restrictive behaviour in FS or a shortcoming from the Snom phones (which would mean we have to submit a bug, wait, wait, wait and then hopefully someday it gets fixed :) )? Regards, Mitja -- Mitja Thomas Vertrieb Geschäftskunden Branchenlösungen / Service Entwicklung Telefon: +49 (0) 441 - 8000-4916 E-Mail: mitja.thomas@ewe.de EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg E-Mail: info@ewe.de Internet: www.ewe.de Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Konrad Meier (Vorsitzender), Dirk Brameier, Ulf Heggenberger, Norbert Westfal
It's negotiates INFO but sends rfc2833? The liberal-dtmf option will accept rfc2833 always. See here: http://wiki.freeswitch.org/wiki/DTMF#DTMF_Options -Avi On Tue, Aug 23, 2011 at 11:02 AM, Mitja Thomas <mitja.thomas1@ewetel.de>wrote:
Hi,
we are experiencing problems with DTMF between Snom Sip Phones and FS. The DMTF Type is set to SIP INFO (sip info only on Snom Phones). We could nail it down to a missing "telephone-event" parameter in sip sdp: INVITE sip:***6@spklw.x;user:phone SIP/2.0 Via: SIP/2.0/UDP ip:5060;branch=z9hG4bK-15eyqwai33r1;rport From: "Test" <sip:8000@spklw.x> <sip:8000@spklw.x>;tag=qqnbrunjmq To: <sip:***6@spklw.x;user:phone> Call-ID: 3c33e6c729b3-t9yol2613q6v CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:8000@ip:5060;line=9lwqdnrx><sip:8000@85.16.245.234:5060;line=9lwqdnrx> ;reg-id=1 X-Serialnumber: 000413262C33 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom370/8.4.32 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 244
v=0 o=root 334284706 334284706 IN IP4 phoneip s=call c=IN IP4 phoneip t=0 0 m=audio 12610 RTP/AVP 8 9 a=direction:both a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a:ptime:20 a=rtcp-xr:stat-summary=loss,dup,jitt a=sendrecv
That resulted in sofia_glue.c disabling DTMF. A slight change in sofia_glue.c (Line 4839 in commit 71964f61ac4817ecfc516edaf4b643f41236868d) did the trick for us: if (tech_pvt->dtmf_type == DTMF_INFO) { //EWETEL } else { //EWETEL switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, "Disable 2833 dtmf\n"); switch_channel_set_variable(tech_pvt->channel, "dtmf_type", "none"); tech_pvt->dtmf_type = DTMF_NONE; te = tech_pvt->recv_te = 0; } //EWETEL
Now the question is: Is this a too restrictive behaviour in FS or a shortcoming from the Snom phones (which would mean we have to submit a bug, wait, wait, wait and then hopefully someday it gets fixed :) )?
Regards, Mitja
-- Mitja Thomas Vertrieb Geschäftskunden
Branchenlösungen / Service Entwicklung
Telefon: +49 (0) 441 - 8000-4916 E-Mail: mitja.thomas@ewe.de
EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg E-Mail: info@ewe.de Internet: www.ewe.de
Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Konrad Meier (Vorsitzender), Dirk Brameier, Ulf Heggenberger, Norbert Westfal
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
Hello Mitja, I've been looking through that bit of code as well the last few days as we're having problems with a host that negotiates no telephone-event, but wants it anyway. But for your case, if you want to force SIP INFO, isn't it good enough to just set a channel variable dtmf_info=true on the channel towards your snom phones ? regards, Leon On Aug 23, 2011, at 10:02 AM, Mitja Thomas wrote:
Hi,
we are experiencing problems with DTMF between Snom Sip Phones and FS. The DMTF Type is set to SIP INFO (sip info only on Snom Phones). We could nail it down to a missing "telephone-event" parameter in sip sdp: INVITE sip:***6@spklw.x;user:phone SIP/2.0 Via: SIP/2.0/UDP ip:5060;branch=z9hG4bK-15eyqwai33r1;rport From: "Test" <sip:8000@spklw.x>;tag=qqnbrunjmq To: <sip:***6@spklw.x;user:phone> Call-ID: 3c33e6c729b3-t9yol2613q6v CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:8000@ip:5060;line=9lwqdnrx>;reg-id=1 X-Serialnumber: 000413262C33 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom370/8.4.32 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 244
v=0 o=root 334284706 334284706 IN IP4 phoneip s=call c=IN IP4 phoneip t=0 0 m=audio 12610 RTP/AVP 8 9 a=direction:both a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a:ptime:20 a=rtcp-xr:stat-summary=loss,dup,jitt a=sendrecv
That resulted in sofia_glue.c disabling DTMF. A slight change in sofia_glue.c (Line 4839 in commit 71964f61ac4817ecfc516edaf4b643f41236868d) did the trick for us: if (tech_pvt->dtmf_type == DTMF_INFO) { //EWETEL } else { //EWETEL switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, "Disable 2833 dtmf\n"); switch_channel_set_variable(tech_pvt->channel, "dtmf_type", "none"); tech_pvt->dtmf_type = DTMF_NONE; te = tech_pvt->recv_te = 0; } //EWETEL
Now the question is: Is this a too restrictive behaviour in FS or a shortcoming from the Snom phones (which would mean we have to submit a bug, wait, wait, wait and then hopefully someday it gets fixed :) )?
Regards, Mitja
-- Mitja Thomas Vertrieb Geschäftskunden
Branchenlösungen / Service Entwicklung
Telefon: +49 (0) 441 - 8000-4916 E-Mail: mitja.thomas@ewe.de
EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg E-Mail: info@ewe.de Internet: www.ewe.de
Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Konrad Meier (Vorsitzender), Dirk Brameier, Ulf Heggenberger, Norbert Westfal
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
Hello Leon & Avi, @Leon: sadly that didnt do the trick. dtmf_info=true was already set in sip_profile, so setting it again as a channel variable didnt help. As far as I understand it (which is admittedly not very well): Although the FreeSWITCH is set to accept DTMF_INFO dtmf tones, dtmf gets disabled because the Snom phone does not send the right rtp media attribute (a=rtpmap 101 telephone-event/8000) in SIP Invite. Anyhow the liberal-dtmf option (suggested by Avi) solved this problem. FS did behave well... liberal and thats exactly what we needed. Thanks a lot to both of you! Regards Mitja
Hello Mitja,
I've been looking through that bit of code as well the last few days as we're having problems with a host that negotiates no telephone-event, but wants it anyway.
But for your case, if you want to force SIP INFO, isn't it good enough to just set a channel variable dtmf_info=true on the channel towards your snom phones ?
regards,
Leon
On Aug 23, 2011, at 10:02 AM, Mitja Thomas wrote:
Hi,
we are experiencing problems with DTMF between Snom Sip Phones and FS. The DMTF Type is set to SIP INFO (sip info only on Snom Phones). We could nail it down to a missing "telephone-event" parameter in sip sdp: INVITE sip:***6@spklw.x;user:phone SIP/2.0 Via: SIP/2.0/UDP ip:5060;branch=z9hG4bK-15eyqwai33r1;rport From: "Test" <sip:8000@spklw.x>;tag=qqnbrunjmq To: <sip:***6@spklw.x;user:phone> Call-ID: 3c33e6c729b3-t9yol2613q6v CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:8000@ip:5060;line=9lwqdnrx>;reg-id=1 X-Serialnumber: 000413262C33 P-Key-Flags: resolution="31x13", keys="4" User-Agent: snom370/8.4.32 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 244
v=0 o=root 334284706 334284706 IN IP4 phoneip s=call c=IN IP4 phoneip t=0 0 m=audio 12610 RTP/AVP 8 9 a=direction:both a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a:ptime:20 a=rtcp-xr:stat-summary=loss,dup,jitt a=sendrecv
That resulted in sofia_glue.c disabling DTMF. A slight change in sofia_glue.c (Line 4839 in commit 71964f61ac4817ecfc516edaf4b643f41236868d) did the trick for us: if (tech_pvt->dtmf_type == DTMF_INFO) { //EWETEL } else { //EWETEL
switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_DEBUG, "Disable 2833 dtmf\n"); switch_channel_set_variable(tech_pvt->channel, "dtmf_type", "none"); tech_pvt->dtmf_type = DTMF_NONE; te = tech_pvt->recv_te = 0; } //EWETEL
Now the question is: Is this a too restrictive behaviour in FS or a shortcoming from the Snom phones (which would mean we have to submit a bug, wait, wait, wait and then hopefully someday it gets fixed :) )?
Regards, Mitja
-- Mitja Thomas Vertrieb Geschäftskunden
Branchenlösungen / Service Entwicklung
Telefon: +49 (0) 441 - 8000-4916 E-Mail: mitja.thomas@ewe.de
EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg E-Mail:info@ewe.de Internet:www.ewe.de
Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Konrad Meier (Vorsitzender), Dirk Brameier, Ulf Heggenberger, Norbert Westfal
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
-- Mitja Thomas Vertrieb Geschäftskunden Branchenlösungen / Service Entwicklung Telefon: +49 (0) 441 - 8000-4916 E-Mail: mitja.thomas@ewe.de EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg E-Mail: info@ewe.de Internet: www.ewe.de Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Konrad Meier (Vorsitzender), Dirk Brameier, Ulf Heggenberger, Norbert Westfal
participants (3)
-
Avi Marcus
-
Leon de Rooij
-
Mitja Thomas