-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, today we found a DTMF problem in an older FS build. We weren't able to pass "*" and "#" to PSTN. FS sents those chars as "0". I fixed that on my own. After that I searched in build 11055M to if it was already fixed in trunk. I found it was fixed in parts. I found that in INFO messages of application type "dtmf-relay" the rfc2833 DTMF events "*#ABCD" are now handled correct, but "EF" are still ignored. In INFO messages of application type "dtmf" EVENTS 0-9 are considered. The others are still ignored resp. changed to "0". So I would recommend to replace the code beginning in line 3535 <<<<<<<<<<<<<<<<<< if (*signal_ptr && (*signal_ptr == '*' || *signal_ptr == '#' || *signal_ptr == 'A' || *signal_ptr == 'B' || *signal_ptr == 'C' || *signal_ptr == 'D')) { dtmf.digit = *signal_ptr; } else { tmp = atoi(signal_ptr); dtmf.digit = switch_rfc2833_to_char(tmp); } <<<<<<<<<<<<<<<<<< with this two lines:
>>>>>>>> tmp=switch_char_to_rfc2833(*signal_ptr); dtmf.digit = switch_rfc2833_to_char(tmp); >>>>>>>>
This will handle all rfc2833 dtmf events in dtmf-relay INFO messages correctly. This is tested by me with snom and AVM clients. Further replace the line 3556 <<<<<<<<<<<<<< int tmp = atoi(sip->sip_payload->pl_data); <<<<<<<<<<<<<< with this line:
>>>>>>>> int tmp=switch_char_to_rfc2833(*(sip->sip_payload->pl_data)); >>>>>>>>
That should handle all rfc2833 DTMF-Events in dtmf INFO messages. This last patch isn't tested by me, cause I've no phone which genereates INFO messages of type applicatin/dtmf... best regards and a late "happy new year" to all of u! Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkll54QACgkQ4tZeNddg3dxJgwCfULx8X9hw6xDd1q8r/Iih5unx c6EAn1T/7GK56pLLrMi140x50HLnO6i1 =3ENR -----END PGP SIGNATURE-----
This workaround was added to address phones that specifically send info dtmf incorrectly. Do you have a specific device that is not working with 1.0.2? If so, can you please show the exact packet it is sending. Mike On Jan 8, 2009, at 6:46 AM, Helmut Kuper wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
today we found a DTMF problem in an older FS build. We weren't able to pass "*" and "#" to PSTN. FS sents those chars as "0". I fixed that on my own. After that I searched in build 11055M to if it was already fixed in trunk.
I found it was fixed in parts. I found that in INFO messages of application type "dtmf-relay" the rfc2833 DTMF events "*#ABCD" are now handled correct, but "EF" are still ignored. In INFO messages of application type "dtmf" EVENTS 0-9 are considered. The others are still ignored resp. changed to "0".
So I would recommend to replace the code beginning in line 3535
<<<<<<<<<<<<<<<<<< if (*signal_ptr && (*signal_ptr == '*' || *signal_ptr == '#' || *signal_ptr == 'A' || *signal_ptr == 'B' || *signal_ptr == 'C' || *signal_ptr == 'D')) { dtmf.digit = *signal_ptr; } else { tmp = atoi(signal_ptr); dtmf.digit = switch_rfc2833_to_char(tmp); } <<<<<<<<<<<<<<<<<<
with this two lines:
>>>>>>>>> tmp=switch_char_to_rfc2833(*signal_ptr); dtmf.digit = switch_rfc2833_to_char(tmp); >>>>>>>>>
This will handle all rfc2833 dtmf events in dtmf-relay INFO messages correctly. This is tested by me with snom and AVM clients.
Further replace the line 3556
<<<<<<<<<<<<<< int tmp = atoi(sip->sip_payload->pl_data); <<<<<<<<<<<<<<
with this line:
>>>>>>>>> int tmp=switch_char_to_rfc2833(*(sip->sip_payload->pl_data)); >>>>>>>>>
That should handle all rfc2833 DTMF-Events in dtmf INFO messages. This last patch isn't tested by me, cause I've no phone which genereates INFO messages of type applicatin/dtmf...
best regards and a late "happy new year" to all of u! Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkll54QACgkQ4tZeNddg3dxJgwCfULx8X9hw6xDd1q8r/Iih5unx c6EAn1T/7GK56pLLrMi140x50HLnO6i1 =3ENR -----END PGP SIGNATURE-----
_______________________________________________ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Mike, I guess the workaround refers to INFO messages with "dtmf" mime type instead of "dtmf-relay"? With the actual trunk (11090) it works. DTMF event F is still converted to zero (0). Im not sure if this event will ever transmitted via INFO. If you use FS switch_utils function "SWITCH_DECLARE(unsigned char) switch_char_to_rfc2833(char key)" instead of the big if-statement (checking for *,#,A,...) befor calling "switch_rfc2833_to_char()" function you can clean up the code a bit and handle all rfc2388 DTMF events. The INFO message my Snom and AVM phones send, looks like this: recv 506 bytes from udp/[85.16.245.220]:1024 at 14:59:40.229120: ------------------------------------------------------------------------ INFO sip:mod_sofia@85.16.246.6:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 85.16.245.220:1024;branch=z9hG4bK-0a38f681korf;rport From: "HK@FreeSWITCH" <sip:2709@85.16.246.6>;tag=v0fmpqh4nz To: <sip:xxxxxxxx@xxxxxxx;user=phone>;tag=m0NcZ8BDZ8pcD Call-ID: 3c26a924030f-p23y096nom3i CSeq: 3 INFO Max-Forwards: 70 Contact: <sip:2709@85.16.245.220:1024;line=3tzvc1jp>;reg-id=1 User-Agent: snom370/7.3.12 Content-Type: application/dtmf-relay Content-Length: 27 Signal=* Duration=160 ------------------------------------------------------------------------ regards Helmut Am 08.01.2009 15:09, schrieb Michael Jerris:
This workaround was added to address phones that specifically send info dtmf incorrectly. Do you have a specific device that is not working with 1.0.2? If so, can you please show the exact packet it is sending.
Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAklmHIoACgkQ4tZeNddg3dzR9gCghxxkOUeYyBEq82BfWsdZ/IWy zMUAnRZ+pf1FmdipqwUZ8YYqbvNscd2q =TzvT -----END PGP SIGNATURE-----
I just opened a bug with Snom on this one.. it should NEVER send a * or # in the signal line. But we do work around this but its wrong. /b On Jan 8, 2009, at 9:32 AM, Helmut Kuper wrote:
INFO sip:mod_sofia@85.16.246.6:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 85.16.245.220:1024;branch=z9hG4bK-0a38f681korf;rport From: "HK@FreeSWITCH" <sip:2709@85.16.246.6>;tag=v0fmpqh4nz To: <sip:xxxxxxxx@xxxxxxx;user=phone>;tag=m0NcZ8BDZ8pcD Call-ID: 3c26a924030f-p23y096nom3i CSeq: 3 INFO Max-Forwards: 70 Contact: <sip:2709@85.16.245.220:1024;line=3tzvc1jp>;reg-id=1 User-Agent: snom370/7.3.12 Content-Type: application/dtmf-relay Content-Length: 27
Signal=* Duration=160
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, sorry, got lost ... It's a bug in Snom and AVM's phones? Maybe we misunderstood. RFC 2833 emtioned in chapter 3.10 following DTMF Events: 3.10 DTMF Events Table 1 summarizes the DTMF-related named events within the telephone-event payload format. Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16 Table 1: DTMF named events Most phones in germany are able to send * and # DTMF events and Phone-applications like voiceboxes or IVRs need those Events. Therefor I don't think it's a bug in Snom or AVM ... But maybe you mean Snom and AVM should send "Signal=10" instead of "Signal=*" ? Unfortunately I can't find an rfc which describes DTMF over INFO messages to find out what the right way is. regards helmut Am 08.01.2009 16:43, schrieb Brian West:
I just opened a bug with Snom on this one.. it should NEVER send a * or # in the signal line. But we do work around this but its wrong.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAklmKNkACgkQ4tZeNddg3dwS5ACgog04UzepKkLgY6RDbzmUoAGy OYkAn3ZiaQeHXNri58+DpNv1GgtPJvoD =kcrv -----END PGP SIGNATURE-----
On 1/8/09, Helmut Kuper <helmut.kuper@ewetel.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Brian,
sorry, got lost ... It's a bug in Snom and AVM's phones?
Maybe we misunderstood. RFC 2833 emtioned in chapter 3.10 following DTMF Events:
3.10 DTMF Events
Table 1 summarizes the DTMF-related named events within the telephone-event payload format.
Event encoding (decimal) _________________________ 0--9 0--9 * 10 # 11 A--D 12--15 Flash 16
Table 1: DTMF named events
Most phones in germany are able to send * and # DTMF events and Phone-applications like voiceboxes or IVRs need those Events.
Therefor I don't think it's a bug in Snom or AVM ...
But maybe you mean Snom and AVM should send "Signal=10" instead of "Signal=*" ?
Yes, it should use the decimal encoding from the table you mentioned. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Snom has already responded to my issue and are going to be providing me a firmware for testing this tomorrow.. its still going to default to the WRONG way.. but has a toggle to turn it to the right way. /b On Jan 8, 2009, at 3:23 PM, Kristian Kielhofner wrote:
Yes, it should use the decimal encoding from the table you mentioned.
Update on this... the latest of anything to speak of in the standards process is that they are killing dtmf-relay. The last draft on it was: http://tools.ietf.org/html/draft-kaplan-sipping-dtmf-package-00 Which says snom is sending it right. We will continue to accept both ways but need to think a bit about how we send. Should we match the draft or the cisco way (cisco by the way was on record saying that info dtmf-relay should die in favor of new specs such as kpml). If anyone wants a good read of what the ietf has standardized in place of info based dtmf, see http://tools.ietf.org/html/rfc4730 Mike On Jan 8, 2009, at 6:38 PM, Brian West wrote:
Snom has already responded to my issue and are going to be providing me a firmware for testing this tomorrow.. its still going to default to the WRONG way.. but has a toggle to turn it to the right way.
/b
On Jan 8, 2009, at 3:23 PM, Kristian Kielhofner wrote:
Yes, it should use the decimal encoding from the table you mentioned.
_______________________________________________ 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
participants (4)
-
Brian West
-
Helmut Kuper
-
Kristian Kielhofner
-
Michael Jerris