No BYE to destination after call with call file

Asterisk Asterisk SIP
#1

hi community

i am testing asterisk on a raspberry pi (raspbx-11-11-2019) and found a weird behaviour.
after trying everything i found online, i need to ask for your help.

i have 3 extensions, 10, 21, 22
21 can call 10, and 22 can call 10, without any problems.

now i start the call with a call file in /var/spool/asterisk/outgoing/

Channel: local/21@from-internal
Callerid: “Test” <21>
Context: from-internal
Extension: 10
Archive: yes

asterisk call 21 and also call 10 and connect both extensions. also this works without any problems.
and with a second call file i can start calls to connect 22 to 10.

the weird behaviour is now, if i end the call with the extension 10, asterisk don’t send the BYE-Packet to the connected destination 22.
in the same situation with the extensions 21 and 10, astersiks send the BYE correct to the destination 21 if i end the call with the extension 10.

the extensions 21 and 22 are doorphones of the same manufacturer but different models.
only one model has this problem with the missing BYE-Packet from the asterisk at the end of the call.
so i think the difference must be in the sip-communication.
i checked the register of both extesions and they are identical.
so i think it’s the 200OK-Packet who caused the problem.

???i cant post sip-logs beacause i am a new user and too many links, and i can’t upload files, what can i do???

i have three guesses what could be causing the problem:

  1. o=jack 0 0 IN IP4 192.168.0.72
    is “0 0” ok?
    i think that should be ok.

  2. double entry of codec PCMA
    m=audio 7080 RTP/AVP 8 0 8 101
    (a=rtpmap:8 PCMA/8000)
    can this cause a problem?
    I offer only PCMA in the INVITE.

  3. i miss the a=sendrecv in the 200OK.
    a=sendrecv
    is it possible that this brings the asterisk to not send the BYE?
    and do you have an idea what i can do to fix this?

thank you for your time and kind regards
hoi

#2

Include the files inline (marked as preformatted text.

Which channel technology driver are you using.

#3 
SIP/2.0 200 OK
via: SIP/2.0/UDP 192.168.0.14:5060;rport=5060;branch=z9hG4bKPj0864a3b9-11a7-4f20-9e33-1149eec83e68
From: "21" <21@192.168.0.14>;tag=1b2e6c58-5263-43a7-9c73-702e58535ac4
To: <sip:21@192.168.0.73>;tag=128511007
Call-ID: b4342f7b-808a-4843-929b-3f848c9d45d0
CSeq: 27955 INVITE
Contact: <sip:21@192.168.0.73:5060>
Content-Type: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER
User-Agent: Sip v1.0
Content-Length: 294
v=0
o=pan 1423 1423 IN IP4 192.168.0.73
s=session SDP
c=IN IP4 192.168.0.73
t=0 0
m=audio 23424 RTP/AVP 8 101
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
m=video 33424 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=428014
a=sendrecv

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.14:5060;rport=5060;branch=z9hG4bKPj0b1e0293-1456-4fd7-a2a9-04e7bb02fcaf
From: "22" <sip:22@192.168.0.14>;tag=44a41edb-de2c-44da-92cd-fd9562ce72f0
To: <sip:22@192.168.0.72>;tag=2090800163
Call-ID: 6c9f555d-5d79-4511-b442-57dcde36bfac
CSeq: 3359 INVITE
Contact: <sip:22@192.168.0.72:5060>
Content-Type: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, REFER
User-Agent: Sip v1.0
Content-Length: 309
v=0
o=jack 0 0 IN IP4 192.168.0.72
s=talk
c=IN IP4 192.168.0.72
t=0 0
m=audio 7080 RTP/AVP 8 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=rtpmap:8 PCMA/8000
m=video 9080 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=428014
#4

Which channel technology driver are you using.

i use pjsip

#5

Hello David

I really hoped you have an idea for me what i can do?

Thanks
hoi

#6

There isn’t enough information to work out what is happening, and the SDP should make no difference.

#7

Hi David

thank you for your feedback.
I have no idea which more information can help to find the cause of the problem.

I use a minimal configuration of freepbx, no settings changed, only DTMF RFC 2833.
I can change the doorphones to the other extensions, and the problem is always with the same doorphone, independent of the extension.

And because i start the call with a callfile, the doorphone sends only “100 Trying” “180 Ringing” and “200OK”.
Thats why i thinked it must be the 200OK.

Is there a way to manipulate incoming sip-packets on the asterisk, so that i can manipulate the packet for testing?

Thank you and kind regards
hoi

#8

No, Asterisk is not a SIP proxy or SIP toolkit and does not provide functionality to examine/modify SIP packets on incoming.

#9

The only way I can think of the 200 OK preventing a BYE is if it didn’t actually match the INVITE, or contained an impossible Contact address. The former would definitely provide evidence on the logs. I suspect the latter would.

#10

hi jcolp

thank you for your feedback.

are there some options in the asterisk configuration who i can try to modify the behaviour of the BYE at the call end?

kind regards
hoi

#11

There are no options. The SIP stack works as the SIP stack works according to the RFC and standards. Without logs and such, can’t say what happened.

#12

Hi all,

i swap the 2 numbers in the call-files, so this behaviour doesn’t occur.

Greetings
hoi