Asterisk returns 481 on hangup - asterisk

Question

Not sure if it's the place where I should ask this question.
I'm developing a simple voip application. I can call to other users, but can't hang up. When client sends BYE request, server answers with 481 - call leg transaction does not exist.
Here are client logs:
INVITE sip:2#172.20.4.7:51110;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:5060;branch=z9hG4bK06952c7a;rport
Max-Forwards: 70
From: "First" <sip:1#172.20.4.7>;tag=as746cc61d
To: <sip:2#172.20.4.7:51110;transport=UDP>
Contact: <sip:1#172.20.4.7:5060>
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
User-Agent: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Date: Tue, 07 Mar 2017 11:52:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "First" <sip:1#172.20.4.7>
Content-Type: application/sdp
Content-Length: 310
v=0
o=root 2015785808 2015785808 IN IP4 172.20.4.7
s=Asterisk PBX 11.16.0
c=IN IP4 172.20.4.7
t=0 0
m=audio 13952 RTP/AVP 0 8 3 111 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKnCqg
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
To: <sip:2#172.20.4.7;transport=UDP>;tag=YU2R
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
Allow-Events: presence, kpml, talk
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bK06952c7a;rport
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
To: <sip:2#172.20.4.7;transport=UDP>;tag=YU2R
From: "First" <sip:1#172.20.4.7;transport=>;tag=as746cc61d
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Accept: application/sdp, application/sdp
Accept-Language: en
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri
Allow-Events: presence, kpml, talk
Content-Length: 247
v=0
o=Z 13 13 IN IP4 95.86.129.80
s=Test
c=IN IP4 95.86.129.80
t=0 0
m=audio 50000 RTP/AVP 3 110 8 0 97 101
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode = 30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
ACK sip:2#172.20.4.7:51110;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:5060;branch=z9hG4bK54ba94a0;rport
Max-Forwards: 70
From: "First" <sip:1#172.20.4.7>;tag=as746cc61d
To: <sip:2#172.20.4.7:51110;transport=UDP>;tag=YU2R
Contact: <sip:1#172.20.4.7:5060>
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 102 ACK
User-Agent: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Content-Length: 0
BYE sip:1#172.20.4.7;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKAZsQ
Max-Forwards: 70
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
To: <sip:1#172.20.4.7;transport=UDP>;tag=YU2R
Contact: <sip:2#172.20.4.7:51110;transport=UDP>
CSeq: 2 BYE
User-Agent: TestSoftphone
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
Content-Length: 0
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 172.20.4.7:51110;branch=z9hG4bKAZsQ;received=172.20.1.40;rport=51110
From: <sip:2#172.20.4.7;transport=UDP>;tag=as746cc61d
To: <sip:1#172.20.4.7;transport=UDP>;tag=YU2R
Call-ID: 425bb181009f366c499b10f362d29ac6#172.20.4.7:5060
CSeq: 2 BYE
Server: FPBX-AsteriskNOW-12.0.76.4(11.16.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
I read that 481 can occur if To tag or From tag or Call-ID is outside of dialog, but looks like tags and ids are ok. I don't receive a tag for To, so I generate Ringing packet where To tag is set, that may be the problem.
EDIT. I added "pedantic=no" to sip_custom.conf, and it works now. Though I don't know what's wrong with this dialog.

Answer 1

I'm pretty sure that Contact header is not necessary in BYE. Fastest way to understand what is wrong is check full dialog with some other SIP client. As you sad this is probably related with To or From headers

Answer 2

Please compare the content of Via headers in initial INVITE and BYE messages - values are different: Via: SIP/2.0/UDP 172.20.4.7:5060 and Via: SIP/2.0/UDP 172.20.4.7:51110 respectively. Asterisk created dialog and marked it internally (inside its mind) according to combination of address and port in Via header. It expects actual dialog to be canceled from the same address and port, hence all the requests came from different source are considered as "out-of-dialog" and rejected.
Actual problem is widespread and caused by incorrect behavior of the routers/firewalls installed on the edge of client networks. Try to disable ALG feature on mentioned device.