• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

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!

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

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 

View solution in original post

6 REPLIES 6
HP Recommended

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

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

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.

 

HP Recommended

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
HP Recommended

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

 

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

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

HP Recommended

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 

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.