SIP Calls hanging on BYE

Distro Discussion & Help
1

I get 100’s errors like this one over and over and over in the CLI: (sanitized)
Autodestruct on dialog ‘[email protected]:5060’ with owner SIP/XXX1-00000673 in place (Method: BYE). Rescheduling destruction for 10000 ms

sip show channels shows active calls with last received message as BYE
core show channels shows active calls using the last app dialparties.agi

Using Distro 2.210.62-3
Is an upgrade to 2.210.62-5 the fix?
Anyone else see this?

2

With SIP history on, I had another Zombie call after having to amportal kill/amportal start to get asterisk to clear the 5 or so other stuck calls.

Here’s the output from a SIP history:

  • SIP Call
  1. NewChan Channel SIP/CSC1-0000000f - from 674c5dd11158a8b8360aa9f11ee564
  2. TxReqRel INVITE / 102 INVITE - INVITE
  3. Rx SIP/2.0 / 102 INVITE / 401 Unauthorized
  4. TxReq ACK / 102 ACK - ACK
  5. AuthResp Auth response sent for 3424453262 in realm asterisk - nc 1
  6. TxReqRel INVITE / 103 INVITE - INVITE
  7. Rx SIP/2.0 / 103 INVITE / 100 Trying
  8. Rx SIP/2.0 / 103 INVITE / 180 Ringing
  9. Rx SIP/2.0 / 103 INVITE / 200 OK
  10. TxReq ACK / 103 ACK - ACK
  11. Masq Old channel: Parking/SIP/CSC1-0000000f
  12. Masq (cont) …new owner: SIP/CSC1-0000000f
  13. Rx BYE / 102 BYE / sip:[email protected]:5060
  14. RTCPaudio Quality:ssrc=142598841;themssrc=1552081355;lp=0;rxjitter=0.0003
  15. RTCPaudioJitter Quality:minrxjitter=0.000000;maxrxjitter=0.000000;avgrxjitter=0
  16. RTCPaudioLoss Quality:minrxlost=0.000000;maxrxlost=0.000000;avgrxlost=0.00000
  17. RTCPaudioRTT Quality:minrtt=0.000000;maxrtt=0.000000;avgrtt=0.000000;stdevrt
  18. SchedDestroy 6400 ms
  19. TxResp SIP/2.0 / 102 BYE - 200 OK
3

I get this message when the call is transferred to the parking lot:
[2013-02-18 13:13:57] NOTICE[1418] chan_sip.c: Disconnecting call ‘SIP/CSC1-0000000f’ for lack of RTP activity in 31 seconds

4

Just upgraded to 2.210.62-5
The issue happens if I Park a call, by doing an XFer->Parkext->Xfer (on Aastra 57i)

Typically if a call is parked, picked up, and parked again.

The specific error of interest is: Can’t setup masquerade. One or both channels is dead. (SIPPeer/SIP/4357-0000000c <-- SIP/4357-0000000c)

Here’s the log:
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called SIP/4357
– SIP/4357-0000000c is ringing
– SIP/4357-0000000c is ringing
– SIP/4357-0000000c answered SIP/CSC2-0000000b
– Started music on hold, class ‘default’, on SIP/CSC2-0000000b
– Stopped music on hold on SIP/CSC2-0000000b
– Executing [h@macro-dial-one:1] Macro(“Parking/SIP/CSC2-0000000b”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“Parking/SIP/CSC2-0000000b”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“Parking/SIP/CSC2-0000000b”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] Hangup(“Parking/SIP/CSC2-0000000b”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘Parking/SIP/CSC2-0000000b’ in macro ‘hangupcall’
== Spawn extension (macro-dial-one, h, 1) exited non-zero on ‘Parking/SIP/CSC2-0000000b’
== Spawn extension (macro-dial-one, s, 42) exited non-zero on ‘Parking/SIP/CSC2-0000000b’ in macro ‘dial-one’
== Spawn extension (macro-exten-vm, s, 14) exited non-zero on ‘Parking/SIP/CSC2-0000000b’ in macro ‘exten-vm’
== Spawn extension (ext-local, 4357, 2) exited non-zero on ‘Parking/SIP/CSC2-0000000b’
[2013-02-19 17:48:27] WARNING[21644]: channel.c:6173 __ast_channel_masquerade: Can’t setup masquerade. One or both channels is dead. (SIPPeer/SIP/4357-0000000c <-- SIP/4357-0000000c)
[2013-02-19 17:48:27] NOTICE[22618]: manager.c:2479 authenticate: Seems to have passed…
[2013-02-19 17:48:58] NOTICE[21644]: chan_sip.c:27480 check_rtp_timeout: Disconnecting call ‘SIP/CSC2-0000000b’ for lack of RTP activity in 31 seconds

5

Check you network, two clues, lack of RTP activity in 31 seconds and Can’t setup masquerade. One or both channels is dead, it indicates that you have not setup your router correctly.

6

Thanks for the tip, are you thinking NAT issues here?
The PBX is on a publicly routed IP behind a firewall, and endpoints are behind NAT.
This doesn’t happen every time, but after you park/pickup/repark and then even so not 100% of the time. I havent found an exact pattern.