Call not being hangup

Asterisk Asterisk SIP
1

After upgrading to Asterisk 15.3.0 from 14.x, calls that are hangup by my softphone do not terminate the call in the other end.
From the SDP logs I can see that Asterisk receive BYE from my phone, but do not send it to the other end.
“Pjsip show channels” show that both channels are gone. Any suggestions?

Log from when I hangup:

– Channel PJSIP/softphone23-0000004c left ‘simple_bridge’ basic-bridge
– Channel PJSIP/sbc-00000049 left ‘simple_bridge’ basic-bridge
== Spawn extension (dial_local_user, 1, 15) exited non-zero on ‘PJSIP/sbc-00000049’
Executing [h@ dial_local_user:6] Hangup(“PJSIP/sbc-00000049”, “”) in new stack
== Spawn extension (dial_local_user, h, 6) exited non-zero on ‘PJSIP/sbc-00000049’

1 Like
2

You need to show the actual SIP trace as well from “pjsip set logger on”.

3

Sip trace

<— Received SIP request (550 bytes) from TCP:1.2.3.4:55589 —>
BYE sip:asterisk(AT)1.2.3.5:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 1.2.3.4:51025;branch=z9hG4bK-524287-1—b5dcf25853a4226c
Max-Forwards: 70
Contact: <sip user(AT)1.2.3.4:51027;transport=TCP;rinstance=1e92b61259416a83>
To: “+number” <sip:+ number(AT)1.2.3.5>;tag=ea6a4739-e7d4-4739-92b9-5a320aaa0dfa
From: <sip user(AT)1.2.3.4;rinstance=1e92b61259416a83>;tag=e0b1b949
Call-ID: 6f477f91-0ff1-418f-a2f1-25647db7f2f9
CSeq: 2 BYE
Content-Length: 0

[Apr 16 20:31:20] DEBUG[17426]: res_pjsip/pjsip_distributor.c:502 distributor: Searching for serializer associated with dialog dlg0x7f21d804d868 for Request msg BYE/cseq=2 (rdata0x7f2168024de0)
[Apr 16 20:31:20] DEBUG[17426]: res_pjsip/pjsip_distributor.c:510 distributor: Found serializer pjsip/outsess/user-0000009d associated with dialog dlg0x7f21d804d868
<— Transmitting SIP response (400 bytes) to TCP:1.2.3.4:55589 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP 1.2.3.4:51025;rport=55589;received=1.2.3.4;branch=z9hG4bK-524287-1—b5dcf25853a4226c
Call-ID: 6f477f91-0ff1-418f-a2f1-25647db7f2f9
From: sip:user(AT)1.2.3.4;rinstance=1e92b61259416a83;tag=e0b1b949
To: “+number” sip:+number(AT)1.2.3.5;tag=ea6a4739-e7d4-4739-92b9-5a320aaa0dfa
CSeq: 2 BYE
Content-Length: 0

and no other packets are sent/received.

Debug logging also revealed:

[Apr 16 20:31:20] DEBUG[17470]: manager.c:4184 action_waitevent: Finished waiting for an event!
[Apr 16 20:31:20] DEBUG[17499][C-00000006]: channel.c:2496 ast_softhangup_nolock: Soft-Hanging (0x20) up channel ‘PJSIP/sbc-0000000c’
[Apr 16 20:31:20] DEBUG[17499][C-00000006]: pbx.c:4204 ast_pbx_h_exten_run: Spawn extension (dial_local_user,h,6) exited non-zero on ‘PJSIP/sbc-0000000c’
== Spawn extension (dial_local_user, h, 6) exited non-zero on ‘PJSIP/sbc-0000000c’
[Apr 16 20:31:20] DEBUG[17499][C-00000006]: channel.c:2587 ast_hangup: Channel 0x7f21d8086268 ‘PJSIP/sbc-0000000c’ hanging up. Refs: 2
[Apr 16 20:31:20] DEBUG[17499][C-00000006]: chan_pjsip.c:2273 hangup_cause2sip: AST hangup cause 16 (no match found in PJSIP)

[Apr 16 20:31:20] DEBUG[17427]: res_pjsip_session.c:2626 ast_sip_session_terminate: Delay sending BYE to sbc because of outstanding transaction…
[Apr 16 20:31:20] DEBUG[17499][C-00000006]: channel.c:2222 ast_channel_destructor: Channel 0x7f21d8086268 ‘PJSIP/sbc-0000000c’ destroying

4

The BYE was delayed because there is already an outstanding request in progress. I’d suggest looking at the complete SIP trace from start to finish and following the requests.

5

Compared to Asterisk 14 trace logs, Asterisk 15 sends an extra INVITE to the same number that called after the bridge has joined the 2 parties. I have tested it multiple times.

— Transmitting SIP request (1070 bytes) to UDP:SBCSERVER:5060 —>
INVITE sip:sbcserver@SBCSERVER:5060 SIP/2.0
Via: SIP/2.0/UDP ASTERISKSERVER:5060;rport;branch=z9hG4bKPjc20a96cd-7b33-49cc-9158-998499019ec2
From: <sip +BNUMBER@sipserver>;tag=56382fab-83c5-4e92-b118-ae91305ebe70
To: “+ANUMBER” <sip +ANUMBER@SBCSERVER>;tag=SvS41Byv3XHZc
Contact: sip:ASTERISKSERVER:5060
Call-ID: a24f7987-bc5e-1236-20ae-522e0b3e5738
CSeq: 18724 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Server/1.0
Content-Type: application/sdp

v=0
o=- 41979434 3225830481 IN IP4 ASTERISKSERVER
c=IN IP4 ASTERISKSERVER
t=0 0
m=audio 28780 RTP/AVP 107 9 8 0 101
a=rtpmap:107 opus/48000/2
a=fmtp:107 maxaveragebitrate=64000;useinbandfec=1;usedtx=1
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv

— Received SIP response (409 bytes) from UDP:SBCSERVER:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP ASTERISKSERVER:5060;rport=5060;branch=z9hG4bKPjc20a96cd-7b33-49cc-9158-998499019ec2
From: <sip +BNUMBER@sipserver>;tag=56382fab-83c5-4e92-b118-ae91305ebe70
To: “+ANUMBER” <sip +ANUMBER@SBCSERVER>;tag=SvS41Byv3XHZc
Call-ID: a24f7987-bc5e-1236-20ae-522e0b3e5738
CSeq: 18724 INVITE
User-Agent: SBCServer
Content-Length: 0

Is this a issue with pjsip (2.7.2) or Asterisk ?

6

That may be a re-invite to update properties of the underlying audio stream. SBCServer should not leave that in limbo, it should send a final response (such as accepting the re-invite or rejecting it). I don’t think we have any configuration option to control that, but by not responding it is breaking SIP. We can’t send a BYE until we know the result of that re-invite.

7

Ok thank you.
Ill try updating the software in the other end/sbc too, and report errors to them instead if they still exist.

8

After updating SBC software, the problem still exists.
I commented out the code that delays BYE in Asterisk and sends it right away, and the problem is solved.
It might be a bug in the other end, but isn’t it better to just send BYE directly and ignore pending results?
The call seems to permanently hang in limbo state, which is not good.

9

Sending the BYE immediately violates the SIP spec. You can only have 1 request going at a time.

10

Tell that to Cisco :wink:
Anyway, I understand. Ill try getting a bugreport through to vendor.