|
|
cc
Registration Date: 01.01.1970
Posts:
|
|
Hi,
I am attempting to track down what is happening with my calls.
My setup:
pap2t->router (tomato 1.25)->att dsl (bridge mode)->internet
At random times, from 30s to 30min to never, I get random OUTBOUND audio drops. The connection is still active, but outbound audio (from the pap2t to the PSTN) has stopped for some reason.
The caller ALWAYS complains about a loud DTMF/FAX tone when the audio drops. I can hear them, they can't hear me. This happens on both sent and received calls.
Do you have any idea what would cause a loud DTMF tone right before the outbound audio is dropped?
I currently have the pap2t in the DMZ so it's not port forwarding issue. I haven't tried STUN yet, but I read that that is generally unneeded.
i'm going to see if I can get the pap2t on a public IP address somehow to see if it's a router/firewall issue. I wish I had another IP phone to test with to rule out the pap2t.
Anyway, any insight would be much appreciated...
Thanks!
Update:
Looking through the logs I see this for the call that ended badly - sip.callwithus.com is ONLY used for outbound calling... the call in question was answered by the pap2t - so why is CWU hanging up?
code: |
Oct 14 14:20:50 VERBOSE[6592] logger.c: -- SIP/cc-110-907e answered SIP/5068-081b57c8
Oct 14 14:20:50 VERBOSE[6592] logger.c: We're at 216.75.41.112 port 39122
Oct 14 14:20:50 VERBOSE[6592] logger.c: Video is at 216.75.41.112 port 44934
Oct 14 14:20:50 VERBOSE[6592] logger.c: Adding codec 0x4 (ulaw) to SDP
Oct 14 14:20:50 VERBOSE[6592] logger.c: Adding codec 0x8 (alaw) to SDP
Oct 14 14:20:50 VERBOSE[6592] logger.c: Adding non-codec 0x1 (telephone-event) to SDP
Oct 14 14:20:50 VERBOSE[6599] chan_sip.c: Hangup call SIP/CallWithUs-fd3a, SIP callid [EMAIL]18c220f00cfa2c0e703f27d26d7906ee@sip.callwithus.com[/EMAIL]
Oct 14 14:24:00 VERBOSE[6592] chan_sip.c: Hangup call SIP/cc-110-907e, SIP callid 26d6cde41e76e83a4d1f83ba462a299d@216.75.41.112
Oct 14 14:24:00 VERBOSE[6592] chan_sip.c: Hangup call SIP/5068-081b57c8, SIP callid 22354b6b72aaaf95478806b30b19e6b1@204.11.192.27
|
|
This post has been edited 1 time(s), it was last edited by cc on 15.10.2009 at 01:43.
|
|
15.10.2009 00:04 |
|
Dia
Premium Account
Registration Date: 03.03.2006
Posts: 1443
|
|
RE: help - random hangups :( |
|
Here are some thoughts and clarifications on the issue.
If two-way audio can be heard from both sides, for at least 5 minutes, it's not a regular NAT Traversal issue. Since the issue is not happening on a regular interval from the beginning of each call, I am almost willing to rule out a NAT Traversal issue completely. In addition the PAP2 doesn't support PPPoE, so I doubt it can acquire a true Public IP address.
Your trace indicates only the G.711 vocoders were used in the call. If CWU supports G.729, enable G.729 Passthru under General Settings, and place the G.729 as the Preferred Codec on the PAP2. Leave G.711 enabled otherwise the call will not connect via PBXes.
Ensure that DTMF is set to rfc2933 both on the PAP2 Extension and the CUW Trunk on your PBXes account. Set the DTMF Process AVT: Yes, the DTMF Process INFO: No, the DTMF Tx Method: AVT, the FAX Passthru Method: ReInvite, and the FAX Process NSE: No, on the PAP2 Line 1 or 2 configuration.
Try calling with this configuration and see if the issue you reported occurs. If it does, next in line is to setup a packet trace on your LAN.
|
|
15.10.2009 08:38 |
|
cc
Registration Date: 01.01.1970
Posts:
|
|
|
17.10.2009 03:13 |
|
Dia
Premium Account
Registration Date: 03.03.2006
Posts: 1443
|
|
RE: pap2t - help - random hangups :( |
|
I am glad the above suggestions helped you improve the issue of dropped calls.
A couple of clarifications regarding DTMF transmission and vocoders. The InBand method requires the vocoder to be set to G.711a or G.711u. It transmits the DTMF tones as audible sounds during the call, similarly to the analog terrestrial PSTN telephony.
But when DTMF tones are transmitted via mobile phones, VoIP networks e.t.c, with no pristine signal conditions, the InBand transmission of DTMF should be avoided at all costs. This is precisely the reason d' être for the other DTMF transmission methods.
Voice is compressed and transmitted over somewhat unreliable networks where jitter and dropped packets are expected, therefore the newer DTMF transmission methods use alternative methods to transmit the tones.
Since G.711(a or u) is not as compact as G.729 or other lower rate vocoders, using it for calls outside of the LAN is not recommended. The MOS score difference between G.711 and G.729 vocoders, does not warrant hauling 5 times the packets across the Internet based on my tests.
Now the vocoder used is a purely personal choice. What I am somewhat hazy is on the definition of "talk-off". What exactly do you mean by that? What is actually happening on the call when this condition occurs?
Lastly regarding your option to upgrade from a PAP2 to a Siemens DECT IP-phone is a step in the right direction, since you will be eliminating a voice conversion step.
I haven't actually tried the A580 IP personally, but it shares code-base with the Gigasets I have. Starting with the 02184 version of firmware, the Siemens DECT IP-phones have become a lot more reliable, enough to be recommended for daily use. They are not perfect yet, but on their way there.
|
|
17.10.2009 15:59 |
|
cc
Registration Date: 01.01.1970
Posts:
|
|
|
18.10.2009 00:48 |
|
Dia
Premium Account
Registration Date: 03.03.2006
Posts: 1443
|
|
|
18.10.2009 10:45 |
|
tel
Premium Account
Registration Date: 28.07.2008
Posts: 252
|
|
|
19.10.2009 13:42 |
|
Dia
Premium Account
Registration Date: 03.03.2006
Posts: 1443
|
|
|
19.10.2009 23:05 |
|
cc
Registration Date: 01.01.1970
Posts:
|
|
|
20.10.2009 22:09 |
|
Dia
Premium Account
Registration Date: 03.03.2006
Posts: 1443
|
|
|
20.10.2009 23:48 |
|
|
|
|
|
|
|