VVX 411 not processing BYE

Igor Olhovskiy
Occasional Contributor

VVX 411 not processing BYE

Hello!

I have a bit strange setup when having 2 identical accounts (what is differs - label and digitmap and actually digitmap is the reason for having 2 accounts) on a same device.

When I'm calling from device account 1 - everything is ok.

But when I'm calling from 2nd account and phone receives BYE from server - it replies with 481 Call Leg/Transaction Does Not Exist and call still is showing as ongoing on the phone

I assume it's cause can't map, that this call was made from 2nd account.

 

Can you please advice what can be done in this case? One of the options could be an RTP timeout, but I did not found any parameter that looks like this.

 

VVX 411: 6.4.2.3008 

 

Thanks!

Message 1 of 7
6 REPLIES 6
SteffenBaierUK
Polycom Employee & Community Manager

Re: VVX 411 not processing BYE

Hello @Igor Olhovskiy ,

Your post ended up in the Spam Filter so it was moved here. Please ensure to use Code Tags, as an example, when posting logs as explained >here<

 

The community is run by volunteers so no need to raise this via the abuse function as this should only be used in the case of abuse. 


Your post does not include enough details as  outlined in the FAQ or ReadMe1st and most likely would need to come into support to understand what you trying to archive. 


Other volunteers are welcome to comment. 

Best Regards

Steffen Baier

----------------

If official support is required please check how to phone or open a case here

----------------
The title Poly Employee & Community Manager is a community setting and does not reflect my role. I am just a simple volunteer in the community like everybody else. All posts and words are my own & do not represent the views of Employer.

----------------


⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓ SIGNATURE ⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓
Notice: This community forum is not an official Poly support resource, thus responses from Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
Please also ensure you always check the VoIP , Video Endpoint , Microsoft Voice , PSTN or other FAQ's in the different sections
Message 2 of 7
Igor Olhovskiy
Occasional Contributor

Re: VVX 411 not processing BYE

Steffen,

 

Sorry, maybe my question was really hard to understand.

 

I'll try to explain a bit more wide.

Device VVX 411 (UC Software 6.4.2.3008), openSIP profile.

Account 1: Usual SIP account, Line Key - 1

Account 2: Same SIP credentials, but with different DISPLAY NAME and different DIGITMAP, Line Key - 2.

 

When I'm calling to some destination using Account 1 (with pressing Line Key 1) all works as expected.

When I'm calling same destination using Account 2 (with pressing Line Key 2), if callee side is hanging up, phone receives BYE, but not accepting it with 481 Call Leg/Transaction Does Not Exist code. So, the call on the phone continues.

 

I was wondering actually is there is possible to somehow fix this behavoir.

1. Is there any parameter on the phone that will say "end the call if no RTP within X seconds"?

2. Is there a possibility to set up different display names per line key, something like "reg.X.line.Y.label", but with a possibility that I can distinct on PBX from which line key call is made?

 

Hopefully, it's more clear.

 

Message 3 of 7
Igor Olhovskiy
Occasional Contributor

Re: VVX 411 not processing BYE

And just to compare logs

 

--- OK
<134>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |2|00|CCallBase::IsChallenged 'BYE' Dialog Tag 'D2AA12FE-671A9B97' pRequest Tag 'D2AA12FE-671A9B97' state 'Confirmed'
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|<<<<<<<< REG[1] Data Received at TCP
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    BYE  SIP/2.0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Via: SIP/2.0/TLS dev.mycompany.pbx:5061;branch=z9hG4bKd368.fd6495dd85efddf959dcf2107d17625d.0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Via: SIP/2.0/UDP 8.8.4.4:5060;received=8.8.4.4;rport=5060;branch=z9hG4bKPj2a18b8a5-6840-474d-b7d4-b3c2f6e2dec9
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    From: <sip:88881@dev.mycompany.pbx;user=phone>;tag=6ba57649-b747-4844-aa45-6a7954189bf3
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    To: <sip:65825@mycompany.pbx>;tag=D2AA12FE-671A9B97
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    CSeq: 6656 BYE
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Call-ID: 377bdd1829d9f30db64a4978279a92e1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Reason: Q.850;cause=16
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Max-Forwards: 69
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    User-Agent: Asterisk PBX 13.33.0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Max-Forwards: 70
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Content-Length: 0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    
<134>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |2|00|new UA Server Non-INVITE trans state 'callingTrying', timeout=0 (0x40f3baa8)
<134>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |3|00|UA Server Non-INVITE BYE trans state 'callingTrying'->'completed' by 200 resp 65 timeout(0x40f3baa8)
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|CStkDialog::SetDialogState: Dialog 'id007e7381' State 'Confirmed'->'Terminated'
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|doDnsListLookup(tls): doDnsSrvLookupForARecordList for '8.8.8.8' port 5061 returned 1 results
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|doDnsListLookup(tls): result 0 '8.8.8.8' port 5061 isInBound 0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|doDnsListLookup(tls): doDnsSrvLookupForARecordList for 'dev.mycompany.pbx' port 5061 returned 1 results
<131>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |4|00|doDnsCheckForDuplicateRecord: Found duplicate record '8.8.8.8' port 5061 at index 0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|CTrans:: SendCommand | this=0x40f3baa8, bVQMonMessage=0, m_pCall->m_pUser->m_bOBFailOverReRegOn=0, m_pCall->m_pUser->m_bVQMonFailoverEnabled=1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|Send: (TLS) entry for address 8.8.8.8 port 5061 can Connect 1 canFailOver 1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|Send: (TLS) address 8.8.8.8 port 5061 can Connect 1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |0|00|IsThisSocket : Found Socket (189)
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |0|00|Send : Found Socket (189) 
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|CPlcmSipTcpSocket::Send TLS queuedTxData = 0 TotalLen 588 loop count 1 maxQueueDepth 40000
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sip  |1|00|CPlcmSipTcpSocket::Send TLS Sent 588 loop count 1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|>>>>>>>> REG[1] Data Sent to TCP 8.8.8.8:5061
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    SIP/2.0 200 OK
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Via: SIP/2.0/TLS dev.mycompany.pbx:5061;branch=z9hG4bKd368.fd6495dd85efddf959dcf2107d17625d.0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Via: SIP/2.0/UDP 8.8.4.4:5060;received=8.8.4.4;rport=5060;branch=z9hG4bKPj2a18b8a5-6840-474d-b7d4-b3c2f6e2dec9
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    From: <sip:88881@dev.mycompany.pbx;user=phone>;tag=6ba57649-b747-4844-aa45-6a7954189bf3
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    To: "65825" <sip:65825@mycompany.pbx>;tag=D2AA12FE-671A9B97
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    CSeq: 6656 BYE
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Call-ID: 377bdd1829d9f30db64a4978279a92e1
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Contact: <sip:65825@172.26.64.20;transport=tls>
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    User-Agent: PolycomVVX-VVX_411-UA/6.4.2.3008
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Accept-Language: en
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    Content-Length: 0
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|    
<135>Apr 21 14:02:59 172.26.64.20 64167f9a92e1|0421140259|sipt |0|00|>>>>>>>> REG End of data sent


--- nOk

<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|<<<<<<<< REG[-1] Data Received at TCP
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    BYE  SIP/2.0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Via: SIP/2.0/TLS dev.mycompany.pbx:5061;branch=z9hG4bK4bfd.7f028ba76c0a6b8a1b28f518a27628cf.0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Via: SIP/2.0/UDP 8.8.4.4:5060;received=8.8.4.4;rport=5060;branch=z9hG4bKPj2c6444d0-42dc-4de1-af8e-cbdeb6d7a130
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    From: <sip:*67666%2388881@dev.mycompany.pbx;user=phone>;tag=6574fe71-0a35-4486-a8a0-6e8b234d8dca
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    To: <sip:65825@mycompany.pbx>;tag=20B5514B-38941E13
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    CSeq: 32558 BYE
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Call-ID: e4a4a3f61da031e05523c292899a92e1
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Reason: Q.850;cause=16
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Max-Forwards: 69
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    User-Agent: Asterisk PBX 13.33.0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Max-Forwards: 70
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Content-Length: 0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    
<134>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |2|00|new UA Server Non-INVITE trans state 'callingTrying', timeout=0 (0x40f3d4e8)
<134>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |3|00|UA Server Non-INVITE BYE trans state 'callingTrying'->'completed' by 481 resp 65 timeout(0x40f3d4e8)
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|doDnsListLookup(tls): doDnsSrvLookupForARecordList for '8.8.8.8' port 5061 returned 1 results
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|doDnsListLookup(tls): result 0 '8.8.8.8' port 5061 isInBound 0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|doDnsListLookup(tls): doDnsSrvLookupForARecordList for 'dev.mycompany.pbx' port 5061 returned 1 results
<131>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |4|00|doDnsCheckForDuplicateRecord: Found duplicate record '8.8.8.8' port 5061 at index 0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|Send: (TLS) entry for address 8.8.8.8 port 5061 can Connect 1 canFailOver 1
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|Send: (TLS) address 8.8.8.8 port 5061 can Connect 1
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |0|00|Send: Call or User is NULL
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |0|00|IsThisSocket : Found Socket (189)
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |0|00|Send : Found Socket (189) 
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|CPlcmSipTcpSocket::Send TLS queuedTxData = 0 TotalLen 568 loop count 1 maxQueueDepth 40000
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |1|00|CPlcmSipTcpSocket::Send TLS Sent 568 loop count 1
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|>>>>>>>> REG[-1] Data Sent to TCP 8.8.8.8:5061
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    SIP/2.0 481 Call Leg/Transaction Does Not Exist
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Via: SIP/2.0/TLS dev.mycompany.pbx:5061;branch=z9hG4bK4bfd.7f028ba76c0a6b8a1b28f518a27628cf.0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Via: SIP/2.0/UDP 8.8.4.4:5060;received=8.8.4.4;rport=5060;branch=z9hG4bKPj2c6444d0-42dc-4de1-af8e-cbdeb6d7a130
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    From: <sip:*67666%2388881@dev.mycompany.pbx;user=phone>;tag=6574fe71-0a35-4486-a8a0-6e8b234d8dca
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    To: <sip:65825@mycompany.pbx>;tag=20B5514B-38941E13
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    CSeq: 32558 BYE
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Call-ID: e4a4a3f61da031e05523c292899a92e1
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    User-Agent: PolycomVVX-VVX_411-UA/6.4.2.3008
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Accept-Language: en
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    Content-Length: 0
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|    
<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sipp |0|00|>>>>>>>> REG End of data sent

 

I see a problem in line

<135>Apr 21 14:03:13 172.26.64.20 64167f9a92e1|0421140313|sip  |0|00|Send: Call or User is NULL
Message 4 of 7
SteffenBaierUK
Polycom Employee & Community Manager

Re: VVX 411 not processing BYE

Hello @Igor Olhovskiy ,

 

the issue is most likely as you are using the same SIP account/Credentials and therefore are forking between the same account. 

 

I do not understand why you would need a different Digitmap on the same account.

An End Point "should" never be responsible for what a user can dial. The SIP switch "should" do this.

 

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

 

----------------

If official support is required please check how to phone or open a case here

----------------
The title Poly Employee & Community Manager is a community setting and does not reflect my role. I am just a simple volunteer in the community like everybody else. All posts and words are my own & do not represent the views of Employer.

----------------


⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓ SIGNATURE ⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓⇓
Notice: This community forum is not an official Poly support resource, thus responses from Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
Please also ensure you always check the VoIP , Video Endpoint , Microsoft Voice , PSTN or other FAQ's in the different sections
Message 5 of 7
Igor Olhovskiy
Occasional Contributor

Re: VVX 411 not processing BYE

Dear Steffen,

 

I have a task to ease the user to dial numbers with prefixes. User is using same account, but depending on prefix dialed, a bit different logic on the PBX is involved.

Idea was to create separate line keys so user can choose what type of prefix he want to use now in a quick way.

For me it's really no difference how to pass this info on PBX, via prefix, via FROM number, but I need to know from which line key call was made from.

For historical reasons there is no easy possibility to make a different account in this case.

 

Cheers,

Igor

Message 6 of 7
Chad_A
Polycom Employee

Re: VVX 411 not processing BYE

Just to confirm for posterity's sake, you are using the same SIP To: URI/AOR and the phone will process this on the first matching registration. When you make a call from line 2 and get a new request in the BYE, the phone will try to map this to a call on the first registration.

 

Having two independent registrations with the same SIP AOR is not supported 

Message 7 of 7