Avaya peering sip channel hung

Hello : guys

Question :asterisk peering with Avaya IP pbx (not session manager ) with TCP port 5062, when call from Aavaya , when call disconnect , the peering channel not destroyed .

My Asterisk enviroment : core show version
Asterisk 11.7.0 built by root @ Cen5.8Bin on a x86_64 running Linux
AVAYA peer 87806660
user phone register tls port 5061

Sip.conf :

office-phone ; create a template for our devices
type=friend ; the channel driver will match on username first,
; IP second
context=LocalSets ; this is where calls from the device will enter
; the dialplan
host=dynamic ; the device will register with asterisk
nat=force_rport,comedia ; assume device is behind NAT
; *** NAT stands for Network Address Translation,
; which allows multiple internal devices to share an
; external IP address.
dtmfmode=auto ; accept touch-tones from the devices, negotiated
; automatically
disallow=all ; reset which voice codecs this device will accept or offer
allow=g729 ; audio codecs to accept from, and request to, the device
allow=ulaw ; in the order we prefer
allow=alaw

600
secret=4VQ96sg6ROc
qualify=yes

[87806660]
type=peer
host=10.1.x.x
defaultuser=87806660
transport=tcp
port=5062
;allowguest=yes
fromdomain=10.1.236.104:5062
;trustrpid=yes
;sendrpid=yes
directmedia=no
;keepalive=45
dtmfmode=rfc2833
insecure=port,invite
outboundproxy=10.1.236.104:5062
;context=inbound-routing-108
context=LocalSets
nat=yes
;qualify=yes
canreinvite=no
disallow=all
allow=g729

Before the call :
sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
10.1.236.104 060cdf0a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80c2d09b45e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 808046a86a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 807a3e9a445 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0f82d116b45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0a486eda245 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02de33a745e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 008e498445e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80fca3709b4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 06839196a45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 032ea2aa145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02276f56945 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 8028eecc694 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07ae4a6a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 806ca7c96a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 01a4e596d45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80b455a7045 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07020e58645 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
18 active SIP channels

When call is disconnect by phone 600 We can see phone sent “bye” to Asterisk , and asterisk reply “bye” to the phone, But the asterisk not sent bye to the AVAYA , and hung by AVAYA user , AVAYA not sent “BYE” to ASTERISK ,and the channel between the AVAYA is not destroyed.

<— SIP read from TLS:118.163.76.241:37040 —>
BYE sip:87806660@220.130.182.108:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.1.111:49504;rport;branch=z9hG4bKPjb5a93bfa2139484597280575baddcfe1;alias
Max-Forwards: 70
From: sip:600@192.168.1.111;ob;tag=0ab7ed74ae82488da67374f5016a4dde
To: sip:87806660@220.130.182.108;tag=as1bee65f7
Call-ID: 5c23a046549113e4445b2c9624c5bfd6@220.130.182.108:5061
CSeq: 27644 BYE
User-Agent: MicroSIP/3.6.2
Content-Length: 0

<— Transmitting (NAT) to 118.163.76.241:37040 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.1.111:49504;branch=z9hG4bKPjb5a93bfa2139484597280575baddcfe1;alias;received=118.163.76.241;rport=37040
From: sip:600@192.168.1.111;ob;tag=0ab7ed74ae82488da67374f5016a4dde
To: sip:87806660@220.130.182.108;tag=as1bee65f7
Call-ID: 5c23a046549113e4445b2c9624c5bfd6@220.130.182.108:5061
CSeq: 27644 BYE
Server: Asterisk PBX 11.7.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

– Executing [h@LocalSets:1] Hangup(“SIP/87806660-00000037”, “”) in new stack
== Spawn extension (LocalSets, h, 1) exited non-zero on ‘SIP/87806660-00000037’
== Spawn extension (LocalSets, 600, 1) exited non-zero on 'SIP/87806660-00000037’
Scheduling destruction of SIP dialog ‘80e013d2846e4192f654366a300’ in 32000 ms (Method: INVITE)

Reliably Transmitting (NAT) to 118.163.76.241:37040:
OPTIONS sip:600@192.168.1.111:5061;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS 220.130.182.108:5061;branch=z9hG4bK65a34af1;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@220.130.182.108;tag=as49f99ff1
To: sip:600@192.168.1.111:5061;transport=TLS;ob
Contact: sip:asterisk@220.130.182.108:5061;transport=TLS
Call-ID: 7a600a4d3c0107a90c2ef92e2bbc09a5@220.130.182.108:5061
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 11.7.0
Date: Tue, 30 Sep 2014 01:24:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
10.1.236.104 060cdf0a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80c2d09b45e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 808046a86a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 807a3e9a445 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0f82d116b45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80e013d2846 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0a486eda245 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02de33a745e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 008e498445e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80fca3709b4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 06839196a45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 032ea2aa145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02276f56945 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 8028eecc694 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07ae4a6a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 806ca7c96a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 01a4e596d45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80b455a7045 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07020e58645 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
19 active SIP channels

serverBCLI> sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
10.1.236.104 060cdf0a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80c2d09b45e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 808046a86a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 807a3e9a445 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0f82d116b45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80e013d2846 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0a486eda245 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02de33a745e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 008e498445e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80fca3709b4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 06839196a45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 032ea2aa145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02276f56945 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 8028eecc694 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07ae4a6a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 806ca7c96a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 01a4e596d45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
118.163.76.241 83a4fffca33 (inv state: None) – -- No RTP active
10.1.236.104 80b455a7045 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07020e58645 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
19 active SIP channels
Really destroying SIP dialog ‘83a4fffca33a4c549530c263eeee7449’ Method: REGISTER
serverB
CLI> sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
10.1.236.104 060cdf0a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80c2d09b45e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 808046a86a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 807a3e9a445 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0f82d116b45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80e013d2846 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 0a486eda245 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02de33a745e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 008e498445e 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80fca3709b4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 06839196a45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 032ea2aa145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 02276f56945 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 8028eecc694 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07ae4a6a145 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 806ca7c96a4 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 01a4e596d45 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 80b455a7045 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
10.1.236.104 07020e58645 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
19 active SIP channels

sip show channels would be easier to understand.

Calling Hangup in the h extension is not very sensible, although probably harmless.

Have you waited long enough for the channel destruction timer to time out (32 seconds)?

Yes , I wait one day .But I don’t have any idea about the asterisk cause . Because Asterisk not sent “bye” packet to peer. and not any message to explain the reason .

Please see the link .
issues.asterisk.org/jira/browse/ASTERISK-19425
It’s very like , But just peering AVAYA to cause it . Peering Asterisk is not.

Hello :

I found new update , when I use hard phone (model:ES290-N), asterisk can sent a “bye” to peer , But Asterisk not sent “bye” packet to peer if I use soft phone (MicroSIP) .

Best Regard

JJ.chiou

You need to provide the complete session from 600. My guess is that 600 has failed to send an ACK and Asterisk is waiting for that before it can send the BYE.

In any case, the h extension is serving no useful purpose, so you should get rid of it to avoid unnecessary confusion.

The Avaya side of this is irrelevant as it has started the hangup processing on the phone, so the B side is already out of the picture.

Hello David:

I observe the normal call , it’s not necessary to “ACK” , just sent “BYE” , and response “200” ok.
I do the following test.
I release endpoint to login via TLS , then it change transport to tcp , then I can capture the packet content. I find something strange . When I hang up by asterisk endpoint . I find asterisk sent a “bye” to endpoint, then endpoint respond code “481” Call/Transaction Does Not Exist .

In general , it’s endpoint sent “bye” to asterisk , then Asterisk response “200” ok ,and sent “bye” to peer. what do you think ?

ACK is mandatory on an invite transaction, which is where I suggest it is missing. It is illegal on a BYE transaction. You cannot send BYE on the incoming leg until you have reeived ACK.

When Asterisk receives BYE, it sends AST_CONTROL_HANGUP. How that is handled depends on details of the dialplan and the channel technology on the calling side.

OK , I think it I don’t describe so detail.

The asterisk sent a "ACK " to softphone when my softphone “Microsip” sent “invite” to asterisk .

And Now I remake three parameter the following : (change the sip.conf)

;allowguest=no
;allowsubscribe=no
;rtcachefriends=yes

Then the asterisk sent “bye” to avaya , but now the channel between asterisk & softphone is not release .
sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
118.163.76.241 ec34cd890de 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
1 active SIP channel

I don’t know why. it’s something stange . I hung up via softphone . But it hung up via “rtptimeout” parameter. why the softphone not sent “bye” packet .

That would be just so blatant a breach of the SIP protocol that I don’t believe it, unless you have a really bad hardware fault on your machine.

The ACK has to be sent by the softphone if the softphone sends the INVITE.

I should say that it does look like there is an Asterisk bug here, but it is a secondary fault involving incorrect recovery from a primary fault, originating outside Asterisk. The inappropriate use of Hangup() may also be a factor.

The level of information presented so far would not be enough to support a formal bug report. You will need complete sip debugs with verbose 5 and debug 5 settings, along with details of the configuration. You should probably also upgrade to 11.9.0, first.

My guess is that even if the secondary problem is resolved, the primary problem will delay the sip channel shut down for some time.

OK David :

The newest is that ASterisk is sent a “bye” packet to avaya , but the channel between asterisk & endpoint (MicroSip) is not destroyed .

Now I describe the process of a endpoint register . endpoint register , then asterisk reply options , and endpoint reply “ok”. and then endpoint sent “publish” packet (event:presence) , asterisk reply “489” bad event .I don’t know what’s matter. Do you think it has any relationship for no “bye” .I ca’t found any “bye” sent by endpoint . (hang up by endpoint). the trptimeout work , sent “bye” to avaya .

The following is captured via asterisk console : not found endpoint sent “bye”
<------------>
– Locally bridging SIP/test1-00000006 and SIP/87806660-00000007
> 0x4abec00 – Probation passed - setting RTP source address to 118.163.76.241:53129
> 0x4abec00 – Probation passed - setting RTP source address to 118.163.76.241:53129
> 0x4acc1e0 – Probation passed - setting RTP source address to 192.168.58.254:2058
> 0x4acc1e0 – Probation passed - setting RTP source address to 192.168.58.254:2058

<------------->
— (8 headers 0 lines) —
Really destroying SIP dialog ‘5d74709c71e3feeb59b658d406ef8183@220.130.182.108:5060’ Method: OPTIONS
Reliably Transmitting (NAT) to 118.163.76.241:12108:
OPTIONS sip:test1@192.168.1.112:5060;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP 220.130.182.108:5060;branch=z9hG4bK3ac2b16e;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@220.130.182.108;tag=as3f5a0bc5
To: sip:test1@192.168.1.112:5060;transport=TCP;ob
Contact: sip:asterisk@220.130.182.108:5060;transport=TCP
Call-ID: 617987130371987b2ac743f02e904581@220.130.182.108:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 11.7.0
Date: Fri, 03 Oct 2014 01:22:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<— SIP read from TCP:118.163.76.241:12108 —>
SIP/2.0 200 OK
Via: SIP/2.0/TCP 220.130.182.108:5060;rport=5062;received=220.130.182.108;branch=z9hG4bK3ac2b16e
Call-ID: 617987130371987b2ac743f02e904581@220.130.182.108:5060
From: “asterisk” sip:asterisk@220.130.182.108;tag=as3f5a0bc5
To: sip:test1@192.168.1.112;ob;tag=z9hG4bK3ac2b16e
CSeq: 102 OPTIONS
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/simple-message-summary, message/sipfrag;version=2.0, application/im-iscomposing+xml, text/plain
Supported: replaces, 100rel, timer, norefersub
Allow-Events: presence, message-summary, refer
User-Agent: MicroSIP/3.6.2
Content-Length: 0

<------------->
— (12 headers 0 lines) —
Really destroying SIP dialog ‘617987130371987b2ac743f02e904581@220.130.182.108:5060’ Method: OPTIONS
[Oct 3 09:22:22] NOTICE[2546]: chan_sip.c:28883 check_rtp_timeout: Disconnecting call ‘SIP/test1-00000006’ for lack of RTP activity in 6 seconds
Scheduling destruction of SIP dialog ‘3ce2cc80060384024236004518da203c@220.130.182.108:5060’ in 32000 ms (Method: INVITE)
set_destination: Parsing sip:10.1.236.104:5062;transport=tcp;lr for address/port to send to
set_destination: set destination to 10.1.236.104:5062
Reliably Transmitting (no NAT) to 10.1.236.104:5062:
BYE sip:10.1.236.104:5062;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 220.130.182.108:5060;branch=z9hG4bK5f19613d
Route: sip:10.1.236.104:5062;transport=tcp;lr
Max-Forwards: 70
From: sip:test1@220.130.182.108;tag=as5f6c062a
To: sip:987806660@10.1.236.104:5062;tag=806cf5edf60e41358f54366a300
Call-ID: 3ce2cc80060384024236004518da203c@220.130.182.108:5060
CSeq: 103 BYE
User-Agent: Asterisk PBX 11.7.0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

<— SIP read from TCP:10.1.236.104:5062 —>
SIP/2.0 200 OK
From: sip:test1@220.130.182.108;tag=as5f6c062a
To: sip:987806660@10.1.236.104:5062;tag=806cf5edf60e41358f54366a300
Call-ID: 3ce2cc80060384024236004518da203c@220.130.182.108:5060
CSeq: 103 BYE
Via: SIP/2.0/TCP 220.130.182.108:5060;branch=z9hG4bK5f19613d;received=192.168.58.169
Server: Avaya CM/R016x.03.0.124.0
Content-Length: 0

<------------->
— (8 headers 0 lines) —
== Spawn extension (LocalSets, 011987806660, 1) exited non-zero on 'SIP/test1-00000006’
Scheduling destruction of SIP dialog ‘b0d5c69c50634beebcde78009a1d6262’ in 6400 ms (Method: INVITE)
Really destroying SIP dialog ‘3ce2cc80060384024236004518da203c@220.130.182.108:5060’ Method: INVITE
serverB*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups

Hello :

the new state : Does any one know what’s matter .

endpoint tls connect : sip channel not hung , but with sip tcp port 5062 , the sip channel is hung .

I just change end point configuration in sip.conf

please refer the following :

notice : the first call is tcp 5062 , the call is interrupt by rtptimeout 6 second , and sip channel add 1 , the next is tls , call is interrupt immediately ,and sip channel not added.

serverBCLI> sip reload
Reloading SIP
== Parsing ‘/etc/asterisk/sip.conf’: Found
== Parsing ‘/etc/asterisk/users.conf’: Found
== Using SIP CoS mark 4
SSL certificate ok
== Parsing ‘/etc/asterisk/sip_notify.conf’: Found
[Oct 7 17:44:53] ERROR[18482]: chan_sip.c:16923 register_verify: ‘TLS’ is not a valid transport for ‘test2’. we only use ‘TCP’! ending call.
[Oct 7 17:44:53] NOTICE[18482]: chan_sip.c:28003 handle_request_register: Registration from ‘sip:test2@x.x.x.x’ failed for ‘x.x.x.x:6405’ - Device not configured to use this transport type
– Registered SIP ‘test2’ at X.X.X.X:45099
– Unregistered SIP ‘test2’
– Registered SIP ‘test2’ at X.X.X.X:4227
== Using SIP RTP CoS mark 5
– Executing [011987806660@LocalSets:1] Dial(“SIP/test2-0000002e”, “SIP/87806660/987806660”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/87806660/987806660
– SIP/87806660-0000002f answered SIP/test2-0000002e
– Locally bridging SIP/test2-0000002e and SIP/87806660-0000002f
> 0xaca8aa0 – Probation passed - setting RTP source address to X.X.X.X:38675
> 0xacdc370 – Probation passed - setting RTP source address to 192.168.58.254:2064
> 0xaca8aa0 – Probation passed - setting RTP source address to X.X.X.X:38675
> 0xacdc370 – Probation passed - setting RTP source address to 192.168.58.254:2064
{Oct 7 17:46:17] NOTICE[11692]: chan_sip.c:28883 check_rtp_timeout: Disconnecting call ‘SIP/test2-0000002e’ for lack of RTP activity in 6 seconds
== Spawn extension (LocalSets, 011987806660, 1) exited non-zero on 'SIP/test2-0000002e’
serverB
CLI> sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
X.X.X.X 1556b933b83 0000000475 0000000027 ( 5.38%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0002
X.X.X.X 8cec21177bf 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
X.X.X.X 8c3e3a2dfb0 0000000477 0000000025 ( 4.98%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0003
X.X.X.X 003f482dec2 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
X.X.X.X fa2a532e8f7 0000000482 0000000020 ( 3.98%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0002
X.X.X.X 741a746c0e3 0000000241 0000000011 ( 4.37%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0025
6 active SIP channels
serverB*CLI> sip reload
Reloading SIP
== Parsing ‘/etc/asterisk/sip.conf’: Found
== Parsing ‘/etc/asterisk/users.conf’: Found
== Using SIP CoS mark 4
SSL certificate ok
== Parsing ‘/etc/asterisk/sip_notify.conf’: Found
[Oct 7 17:48:23] ERROR[18522]: chan_sip.c:16923 register_verify: ‘TCP’ is not a valid transport for ‘test2’. we only use ‘TLS’! ending call.
[Oct 7 17:48:23] NOTICE[18522]: chan_sip.c:28003 handle_request_register: Registration from ‘sip:test2@220.130.182.108’ failed for ‘X.X.X.X:4227’ - Device not configured to use this transport type
– Registered SIP ‘test2’ at X.X.X.X:55497
– Unregistered SIP ‘test2’
– Registered SIP ‘test2’ at X.X.X.X:7724
== Using SIP RTP CoS mark 5
– Executing [011987806660@LocalSets:1] Dial(“SIP/test2-00000030”, “SIP/87806660/987806660”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/87806660/987806660
– SIP/87806660-00000031 answered SIP/test2-00000030
– Locally bridging SIP/test2-00000030 and SIP/87806660-00000031
> 0xad03890 – Probation passed - setting RTP source address to X.X.X.X:3260
> 0xad1b470 – Probation passed - setting RTP source address to 192.168.58.254:2066
> 0xad03890 – Probation passed - setting RTP source address to X.X.X.X:3260
> 0xad1b470 – Probation passed - setting RTP source address to 192.168.58.254:2066
> 0xad03890 – Probation passed - setting RTP source address to X.X.X.X:3260
> 0xad03890 – Probation passed - setting RTP source address to X.X.X.X:3260
== Spawn extension (LocalSets, 011987806660, 1) exited non-zero on ‘SIP/test2-00000030’

serverB*CLI> sip show channelstats
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
X.X.X.X 1556b933b83 0000000475 0000000027 ( 5.38%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0002
X.X.X.X 8cec21177bf 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
X.X.X.X 8c3e3a2dfb0 0000000477 0000000025 ( 4.98%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0003
X.X.X.X 003f482dec2 0000000000 0000000000 ( 0.00%) 0.0000 0000000000 0000000000 ( 0.00%) 0.0000
X.X.X.X fa2a532e8f7 0000000482 0000000020 ( 3.98%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0002
X.X.X.X 741a746c0e3 0000000241 0000000011 ( 4.37%) 0.0000 0000000000 0000000001 ( 0.00%) 0.0025
6 active SIP channels

At a guess rtpholdtimeout is way too small to cope with even a single lost RTCP frame.

Dear sir :

I think it is not this reason , the config rtpholdtimeout=300 (original) , Does any idea about this event ?

It’s eerie , it just change endpoint configuration transport = tls (or tcp) port =5061 (or 5062) ,

Why tls is ok , tcp is not ?

thanks

Best Regard

We are still waiting for a sufficiently complete protocol trace, but I would note that RTP is never sent over TCP.

Dear sir :

what do you want the information , and I just found only two RTP package via wireshark , one to Avaya media gateway , and one is back . other is UDP packet .

The fault is on the phone side. The Avaya is irrelevant.

I think so , but I don’t know what’s matter if I peering two asterisk is no problem .

Thanks ! I solve this problem

I solve the problem major in sip.conf file .

I mark all not related configuration , bindport , udpbindaddr , transport no udp .

and solved asterisk not sent “bye” issue . But I found Asterisk also provide port 5060 , even reboot . I think it’s asterisk’s bug , all of the solution I searched tell me for the firewall to against it .