AT&T vs Verizon DTMF recognition using OBi110 as an FXO Port on Asterisk
otter117:
Per your request to open a ticket I sent the log below via e-mail.
Here is my syslog for a call from a Verizon Samsung cell phone.
DTMFmethod = auto, channel gains are all at defaults.
I pushed the 1 key 10 times and it was only recognized twice.
I spoke with someone who said it might be the cell companies use of the G.729 protocol which can be programmed per switch.
Therefore you might get different results depending upon your carrier and where you dial from.
I have been trying various channel gain values without any improvement.
Jul 19 18:56:07 10.70.5.205 [DAA]: FXO ring on
Jul 19 18:56:09 10.70.5.205 [0]DAA CND 07191849,,UNAVAILABLE ,,,
Jul 19 18:56:11 10.70.5.205 sendto a0a05cd:5060(952)
Jul 19 18:56:11 10.70.5.205 INVITE sip:36226@10.10.5.205:5060 SIP/2.0 Call-ID: d4403b3b@10.70.5.205 Content-Length: 400 CSeq: 8001 INVITE From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f Max-Forwards: 70 To: <sip:36226@10.10.5.205> Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-270df828;rport User-Agent: OBIHAI/OBi110-1.2.1.2384 Contact: <sip:obi110@10.70.5.205:5060> Expires: 60 Supported: replaces Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER Remote-Party-ID: <sip:obi110@10.10.5.205>;party=calling;privacy=off Content-Type: application/sdp v=0 o=- 17175 1 IN IP4 10.70.5.205 s=- c=IN IP4 10.70.5.205 t=0 0 m=audio 10033 RTP/AVP 0 8 18 104 102 103 105 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:104 G726-32/8000 a=rtpmap:102 G726-16/8000 a=rtpmap:103 G726-24/8000 a=rtpmap:105 G726-40/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 a=xg726bitorder:big-endian
Jul 19 18:56:11 10.70.5.205 RxFrom:a0a05cd:5060
Jul 19 18:56:11 10.70.5.205 SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-270df828;received=10.70.5.205;rport=5060 From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f To: <sip:36226@10.10.5.205> Call-ID: d4403b3b@10.70.5.205 CSeq: 8001 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: <sip:36226@10.10.5.205> Content-Length: 0
Jul 19 18:56:11 10.70.5.205 RxFrom:a0a05cd:5060
Jul 19 18:56:11 10.70.5.205 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-270df828;received=10.70.5.205;rport=5060 From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f To: <sip:36226@10.10.5.205>;tag=as4c7df965 Call-ID: d4403b3b@10.70.5.205 CSeq: 8001 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Contact: <sip:36226@10.10.5.205> Content-Type: application/sdp Content-Length: 211 v=0 o=root 15522 15522 IN IP4 10.10.5.205 s=session c=IN IP4 10.10.5.205 t=0 0 m=audio 10006 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv
Jul 19 18:56:11 10.70.5.205 RTP:DtmfTxMtd:1(1),0
Jul 19 18:56:11 10.70.5.205 sendto a0a05cd:5060(324)
Jul 19 18:56:11 10.70.5.205 ACK sip:36226@10.10.5.205 SIP/2.0 Call-ID: d4403b3b@10.70.5.205 Content-Length: 0 CSeq: 8001 ACK From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f Max-Forwards: 70 To: <sip:36226@10.10.5.205>;tag=as4c7df965 Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-604cd22d;rport User-Agent: OBIHAI/OBi110-1.2.1.2384
Jul 19 18:56:11 10.70.5.205 [DAA]: FXO OFFHOOK
Jul 19 18:56:11 10.70.5.205 [DAA]: detecting disconnect tone, reinit: 1
Jul 19 18:56:11 10.70.5.205 RTP:Start->a0a05cd:10006(80);0;0;0:0:0;0(15)
Jul 19 18:56:11 10.70.5.205 [DAA] FXO ring off
Jul 19 18:56:21 10.70.5.205 [DSP] ---- S/W DTMF ON (level: 3) : 1, @ 175761 ----
Jul 19 18:56:21 10.70.5.205 [RTP] DTMF TX (RFC) -- dgt: 1, c_dgt:
Jul 19 18:56:21 10.70.5.205 [DSP] ---- S/W DTMF OFF @ 175821 ms----
Jul 19 18:56:30 10.70.5.205 [DSP] ---- S/W DTMF ON (level: 3) : 1, @ 184041 ----
Jul 19 18:56:30 10.70.5.205 [RTP] DTMF TX (RFC) -- dgt: 1, c_dgt:
Jul 19 18:56:30 10.70.5.205 [DSP] ---- S/W DTMF OFF @ 184101 ms----
Jul 19 18:57:04 10.70.5.205 t_on: 250, t_off: 250, steady_on: 210, steady_off: 290, hits: 5
Jul 19 18:57:04 10.70.5.205 [DSP]: fxo tone detected: reorder, 3!
Jul 19 18:57:04 10.70.5.205 [DSP]: fxo (disconnect) tone detected: reorder, 3!
Jul 19 18:57:04 10.70.5.205 [0]DAA Disc.Tone 0 0
Jul 19 18:57:04 10.70.5.205 sendto a0a05cd:5060(407)
Jul 19 18:57:04 10.70.5.205 BYE sip:36226@10.10.5.205 SIP/2.0 Call-ID: d4403b3b@10.70.5.205 Content-Length: 0 CSeq: 8002 BYE From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f Max-Forwards: 70 To: <sip:36226@10.10.5.205>;tag=as4c7df965 Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-29b40c7a;rport User-Agent: OBIHAI/OBi110-1.2.1.2384 X-RTP-Stat: PS=2631,OS=450036,PR=2323,OR=399556,PL=0,JI=1,DU=52,EN=G711U,DE=G711U
Jul 19 18:57:04 10.70.5.205 RTP:Del Channel
Jul 19 18:57:04 10.70.5.205 [JB] call overall status -- peer: 10.10.5.205:10006, local: 10.70.5.205:10033, pkt_tx: 2631, pkt_rx: 2323, bytes_tx: 450036, bytes_rx: 399556, clk_diff: 497 PPM, pkt_in_jb: 8, pkt_ooo: 0, pkt_lost: 0, pkt_late: 0, pkt_loss_rate: 0 %, pkt_drop_rate: 0 %, jb_len: 190 ms, curr_rcvd_jitter: 1 ms, rcvd_digits: 0, underruns: 0, overruns: 0, seq_num_broken: 0, pkt_interp: 619, skew_comp: 0 ms, frm_in_pkt: 2
Jul 19 18:57:04 10.70.5.205 [DAA]: FXO ONHOOK MONITOR
Jul 19 18:57:04 10.70.5.205 [DAA]: FXO ONHOOK MONITOR
Jul 19 18:57:04 10.70.5.205 RxFrom:a0a05cd:5060
Jul 19 18:57:04 10.70.5.205 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.70.5.205:5060;branch=z9hG4bK-29b40c7a;received=10.70.5.205;rport=5060 From: <sip:obi110@10.10.5.205>;tag=SP134752bf759bd403f To: <sip:36226@10.10.5.205>;tag=as4c7df965 Call-ID: d4403b3b@10.70.5.205 CSeq: 8002 BYE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Content-Length: 0
OBiSupport:
From your very first post, you stated that OBi 110 DTMF detection works fine with connection to a ILEC POTS line. Correct? if so, OBi has no DTMF problem with regular PSTN network.
The problem appears when you have OBi device connected to an ESI PBX where QWEST is the ILEC.
Since digits go through QWEST VoIP network, we need to diagnose if any distortion is introduced in DTMF signal, particularly when the testing calls are originated from Verizon cell phone. If your PBX connects to a SIP trunk and all the digits (via RFC2833) are received OK, then, local generated digits should work for OBi device. However, if digits are actually sent as inband signal, speech vocoder might distort DTMF signal badly, e.g., G.729 as you pointed out (even G.711 will have some minor impact), which could be reason why OBi 110 cannot recognize those digits.
Please check with your service provider on whether this is the case, or it would be better that you have a test device to check on DTMF signal that connects to same PBX.
otter117:
I got some help from Verizon tech support.
It seems all Verizon phones have a setting for the duration of DTMF tones.
By default, all Verizon phones are set to “normal”.
The other setting available is “long”.
When I set my Samsung and Android to the “long” setting, the DTMF tones are recognized by the Obi110.
I need to do some further testing/tweaking as it is still not perfect.
I think we will be able to use the Obi110s after all. ;D
OBiSupport:
Thanks for informing us back ... This seems to indicate AT&T iPhones come with a longer DTMF duration by default. Interesting to know this. Good luck to your applications.
otter117:
And thank you for your prompt support.
It is going to be an issue where we have to educate the users on changing their phone settings.
Are there any values I can tweak in the OBi110 that will make it recognize the shorter DTMF duration?
I've tried several things like X_UseFixedDurationRFC2833DTMF and DTMFMethod but no luck yet.
Navigation
[0] Message Index
[#] Next page
[*] Previous page