TIPS Dropped Call Explanation

[Stewart]

Can someone shed some light on how this call was terminated? It was an outgoing call. Setup seems fine. Ringing is good. Audio passes fine (although I'm not capturing RTP). Everything seems fine until Asterisk sends a bye to the user's handset disconnecting the call. The packet shows HangupCause "Normal Clearing" and HangupCauseCode of "16". Neither side initiated the Hangup. Why would Asterisk send the BYE?

 

[briankelly63]

Need more information from CLI or log.

New - Old system? Versions? Provider? Trunk configs? Network - Router info, POTS line? How often is problem? etc

Although a call is in progress and appears stable there is still a lot going on at the SIP and network levels so lots of things can still go wrong or timeout. If this is a serious problem it is unlikely that it won't become more defined or predictable.

 

[Stewart]

Asterisk is 1.4. It's a rebuild since the SSD croaked on the last one so it's only a couple of weeks old with a restore from a nightly backup. The provider is Brighthouse.

PEER Details:
type=peer
rfc2833compensate=yes
relaxdtmf=no
host=[hostip]
dtmfmode=inband

USER Details:
type=peer
reinvite=yes
port=5060
insecure=invite,port
host=[hostip]
context=from-trunk
canreinvite=no

No registration. There is a route set up to forward all traffic through the local IAD Gateway IP so no router in the way. Just a PoE switch connecting it all.

Here is the snippet of the Asteisk logfile.

[2013-09-16 09:27:40] DEBUG[3879] app_macro.c: Executed application: ExecIf
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Executing [s@macro-dialout-trunk:16] Macro("SIP/1011-0000036f", "dialout
-trunk-predial-hook|") in new stack
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/1011-000
0036f", "") in new stack
[2013-09-16 09:27:40] DEBUG[3879] app_macro.c: Executed application: Macro
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Executing [s@macro-dialout-trunk:17] GotoIf("SIP/1011-0000036f", "0?bypa
ss|1") in new stack
[2013-09-16 09:27:40] DEBUG[3879] app_macro.c: Executed application: GotoIf
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/1011-0000036f", "0?cust
omtrunk") in new stack
[2013-09-16 09:27:40] DEBUG[3879] app_macro.c: Executed application: GotoIf
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Executing [s@macro-dialout-trunk:19] Dial("SIP/1011-0000036f", "SIP/BH-S
IP-O/5555555555|300|TwW") in new stack
[2013-09-16 09:27:40] VERBOSE[3879] logger.c: -- Called BH-SIP-O/5555555555
[2013-09-16 09:27:41] VERBOSE[3879] logger.c: -- SIP/BH-SIP-O-00000370 is ringing
[2013-09-16 09:27:41] VERBOSE[3879] logger.c: -- SIP/BH-SIP-O-00000370 is making progress passing it to SIP/1011-0000036f
[2013-09-16 09:27:48] VERBOSE[3879] logger.c: -- SIP/BH-SIP-O-00000370 answered SIP/1011-0000036f
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Executing [h@macro-dialout-trunk:1] Macro("SIP/1011-0000036f", "hangupca
ll|") in new stack
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Executing [s@macro-hangupcall:1] GotoIf("SIP/1011-0000036f", "1?skiprg")
in new stack
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Goto (macro-hangupcall,s,4)
[2013-09-16 09:32:17] DEBUG[3879] app_macro.c: Executed application: GotoIf
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Executing [s@macro-hangupcall:4] GotoIf("SIP/1011-0000036f", "1?skipblkv
m") in new stack
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Goto (macro-hangupcall,s,7)
[2013-09-16 09:32:17] DEBUG[3879] app_macro.c: Executed application: GotoIf
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Executing [s@macro-hangupcall:7] GotoIf("SIP/1011-0000036f", "1?theend")
in new stack
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Goto (macro-hangupcall,s,9)
[2013-09-16 09:32:17] DEBUG[3879] app_macro.c: Executed application: GotoIf
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: -- Executing [s@macro-hangupcall:9] Hangup("SIP/1011-0000036f", "") in new
stack
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/1011-0000
036f' in macro 'hangupcall'
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: == Spawn h extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/1011
-0000036f'
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: == Spawn extension (macro-dialout-trunk, s, 19) exited non-zero on 'SIP/1011-
0000036f' in macro 'dialout-trunk'
[2013-09-16 09:32:17] VERBOSE[3879] logger.c: == Spawn extension (from-internal, 5555555555, 8) exited non-zero on 'SIP/101
1-0000036f'

You'll see the call lasted for about 4.5 minutes and then the system just hangs up. But it only sends the BYE to the handset and not to the trunk. I don't understand the process. Thanks.

 

[phoneguy]

Based on the info you provided and not having a full wireshark trace your provider sent the Bye Packet so Asterisk sent it to the handset. Otherwise you would see Asterisk send the Bye to the trunk which it did not do.

 

[briankelly63]

A few things to look at:

Don't see why you would need the compensate directive (1.2 involved?): http://issues.freepbx.org/browse/FREEPBX-2724

Its not "reinvite" its "canreinvite" http://www.voip-info.org/wiki/view/Asterisk+sip+reinvite

I would set dtmfmode=rfc2833 there is no reason inband should be needed these days. Phone should also be set to force rfc2833.

Get rid of relax dtmf directive (opens additional issues).

Brighthouse actually says canreinvite can be yes but for the moment I'd leave it no especially if there is more than one Asterisk box involved.

Spurious speech DTMF activity can cause a disconnect...

externip set properly?

If the issue continues you'd end up having to do a pcap type capture on the server or externally (if the switch can mirror ports) and then look that over with wireshark which would also have the RTP audio.

 

[Stewart]

phoneguy:
That is the full wireshark trace. I have the .cap file. It includes all of the SIP traffic and none of the RTP traffic but I can't think of something in the RTP that could cause Asterisk to send the BYE. If it came from the trunk, it would show up in the capture.

briankelly63:
-Compensate is in there because of issues I had with other providers. It must work with 1.4 because it has fixed issues for me. Maybe it's not needed here, but it isn't hurting anything.
-With Brighthouse I HAD to set DTMF to inband. Setting it to rfc2833 resulted in the tone "not being loud enough" according to them. This was especially true when users were checking their cell-phone voicemail remotely.
-True, I mis-typed the canreinvite. Nice catch.
-RelaxDTMF is in there because of issues I've had with other providers as well. Adding it in helped with the tone not being recognized with some autoattendants.
-I've not heard of Spurious DTMF causing a disconnect. Interesting.
-There is no externip since the box is set to public.
I can set the capture to include RTP, but what good would that do? I don't need to hear the audio. Is there a DTMF tone to hangup?

 

[briankelly63]

Bottom line right now is you don't have enough data on this issue to do anything other than the checking I've suggested. This is a good example of why it's important to be able to get SIP traces from the provider (Anveo includes this on every call).

Considering that you can configure a trunk by provider I'm not sure I'd leave in configuration items that solved an issue with another provider but that's a personal choice. My point is just that I wouldn't want to introduce a bunch of rather mysterious configuration changes that collectively cause a problem.

Compensate comes into play when you have Asterisk 1.2 and 1.4 talking to each other so I'm not sure how that would help.

DTMF, especially in a relaxed configuration, can be triggered by speech (talk off) and cause actions to be taken (like a deadend transfer) by the box at either end which results in a disconnect or an apparent disconnect that causes one of the parties to hang-up.

The issue you mentioned where they said "not being loud enough" doesn't make any sense. RFC2833 makes sure that the distant DTMF, if needed at all, is generated at the point which is closest to the intended receiver. Inband has you send DTMF through a long pipe and multiple codec's with the hope that it will be clean enough to invoke the intended function. RCF2833 sends an appropriate data packet that indicates that a particular key has been pressed that happens to be a particular DTMF tone. In a pure digital environment there is actually no true DTMF sent anywhere except to the handset of the phone just for user feedback.

The only reason to capture the RTP is to get a sense of the timing (who lost what first) and be able to see if you lost one or both RTP paths before their server said BYE. The distant party may have lost your users audio and then just hung up!

 

[Stewart]

I know the DTMF not being loud enough is a crock. The problem is that they can see that they are sending the dtmf tone but it just doesn't seem to do anything. Switching to inband fixed the issue but I tried for 2 days to get the RFC2833 to work with them. In the end I just needed it functional.

I guess I'm just not understanding. Something had to trigger Asterisk to generate the BYE and generate it only to the handset. If the other user had hung up I would see the BYE sent from the provider. If the handset had hung up I would see the BYE sent from the handset. If the other party had hung up there would be an associated SIP packet to indicate it. And now as I look at it, Wireshark shows the leg from the handset to the PBX as COMPLETED but shows the leg from the PBX to the provider as IN CALL. That makes sense since that leg was never closed. If no BYE packet was sent from the provider to the PBX what caused Asterisk to generate the BYE to the handset (and not to the provider)? What else could cause it to generate that?

 

[Stewart]

I think this is part of the same issue. The user hangs up because of dead air and the phone sends the BYE, but the system does not pass on the BYE to the Provider. The Provider then hangs up and the PBX says the call no longer exists. Any ideas on what to check?

 

[Stewart]

I think we've fixed the problem, but not sure what was actually happening. After replacing the IAD they haven't had any other problems. Still not sure what was happening, though. Maybe communication started happening on another channel and Asterisk switched to it but the IAD never did? Perplexing.