• ×
    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

Hi,

 

I am using a VVX310 and have run into a problem whereby the an extension I am monitoring stops monitoring. I have setup the monitoring of the phone on the web interface so it uses dialog events (RFC4235) instead of presence. 

 

I have setup the phone to do syslogging and here is what I have observered. If I reboot the phone the monitoring of BLF works perfectly until the next SUBSCRIBE is sent to the server. At this point the version field in subscription table on my opensips servers  returns to 0, however the subscription table on the phone remains at last state. 

 

Now when a NOTIFY is sent to the phone the version in the dialog is less than the version the phone has stored and the packet is discarded. 

 

I get this message in the logs

 

Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|<<<Packet Received 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    NOTIFY sip:2852298@10.64.5.88:5061 SIP/2.0 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Max-Forwards: 10 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Record-Route: <sip:41.221.230.19;lr=on;ftag=140247534231358> 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Via: SIP/2.0/UDP 41.221.230.19;branch=z9hG4bKc661.7a706fc6.0 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Via: SIP/2.0/UDP 127.0.0.1;rport=45934;received=41.221.232.40 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    From: <sip:2852265@telviva.com>;tag=140247534231358 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    To: <sip:2852298@telviva.com>;tag=14D1271D-6953509C 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Contact: <sip:2852265@telviva.com> 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Call-ID: 89577251-1bb1ff40-e5488f23@10.64.5.88 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    CSeq: 99540957 NOTIFY 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    User-Agent: Enswitch presence server 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Event: dialog 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Subscription-State: active;expires=3214 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Content-Type: application/dialog-info+xml 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Content-Length: 366 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    X-Enswitch-RURI: sip:2852298@41.221.230.19:5060 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    X-Enswitch-Source: 41.221.232.40:45934 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|     
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    <?xml version="1.0" encoding="UTF-8"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:2852265@telviva.com"> <dialog id="1402486218.12185406" direction="initiator"> <state>terminated</state> <local> <identity>sip:2852265@telviva.com</identity> </local> <remote> <identity>*1</identity> </remote> </dialog> </dialog-info>  
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |1|00|CStkDialog::OnEvRequest for CSeq 99540957 deleted NOTIFY Server 1 of 1 CSeq 99540946 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |2|00|CCallBase::IsChallenged 'NOTIFY' Dialog Tag '14D1271D-6953509C' pRequest Tag '14D1271D-6953509C' state 'Confirmed' 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |2|00|new UA Server Non-INVITE trans state 'callingTrying', timeout=0 (0x40e333c8) 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |3|00|UA Server Non-INVITE NOTIFY trans state 'callingTrying'->'completed' by 200 resp 65 timeout(0x40e333c8) 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '41.221.230.19' port 0 returned 1 results 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |1|00|doDnsListLookup(udp): result 0 '41.221.230.19' port 0 isInBound 0 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Trying to send data to Destination 41.221.230.19 on socket 127 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|>>> Data Send to 41.221.230.19:5060 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    SIP/2.0 200 OK 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Via: SIP/2.0/UDP 41.221.230.19;branch=z9hG4bKc661.7a706fc6.0 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Via: SIP/2.0/UDP 127.0.0.1;rport=45934;received=41.221.232.40 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    From: <sip:2852265@telviva.com>;tag=140247534231358 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    To: "2852298" <sip:2852298@telviva.com>;tag=14D1271D-6953509C 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    CSeq: 99540957 NOTIFY 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Call-ID: 89577251-1bb1ff40-e5488f23@10.64.5.88 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Contact: <sip:2852298@10.64.5.88:5061> 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Record-Route: <sip:41.221.230.19;lr=on;ftag=140247534231358> 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Event: dialog 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    User-Agent: PolycomVVX-VVX_310-UA/5.0.2.2756 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Accept-Language: en 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|    Content-Length: 0 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |0|00|     
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |2|00|CTrans::InitRetrans for UA Server Non-INVITE NOTIFY state 'completed' Server 1 of 1 (0x40e333c8) 
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip  |1|00|Dialog '1402486218.12185406' State 'Trying'->'Terminated' 

<<<<<here is what I think is the problem>>>>>>>
Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip |2|00|CCallNoCall::Notified full dialog-info 1 of 1 version rx 3 local 15 Jun 11 13:30:38 polycom_0004f281e5bf 10.64.5.88 0611133020|sip |3|00|CCallNoCall::HandleVersionValidation full dialg-info 1 of 1 ignored. Version is stale (3 <= 15)

 

 

According to RFC4235, this is correct behaviour. However the we send a dialog message with a state='full' which should force the phone to subscription table to be flushed and repoluated. 

 

 

   The table is also associated with a version number.  The version
   number MUST be initialized with the value of the "version" attribute
   from the "dialog-info" element in the first document received.  Each
   time a new document is received, the value of the local version
   number is compared to the "version" attribute in the new document.
   If the value in the new document is one higher than the local version
   number, the local version number is increased by one and the document
   is processed.  If the value in the document is more than one higher
   than the local version number, the local version number is set to the
   value in the new document and the document is processed.  If the
   document did not contain full state, the subscriber SHOULD generate a
   refresh request (SUBSCRIBE) to trigger a full state notification.  If
   the value in the document is less than the local version, the
   document is discarded without processing.

   The processing of the dialog information document depends on whether
   it contains full or partial state.  If it contains full state,
   indicated by the value of the "state" attribute in the "dialog-info"
   element, the contents of the table are flushed and then repopulated
   from the document.

 

The RFC is a bit vague on the details but in my opinion the tabled on the phone should be flushed an updated if a dialog with state="full" is received. 

 

Anyone else had a similar issue?

 

Thanks,

Michael

 

2 REPLIES 2
HP Recommended

Michael,

Has there been any answers that you found, or have been given by Polycom?

 

Thanks,

Dan W.

HP Recommended

According to RFC4235:

   "If it contains full state, indicated by the value of the "state" attribute in the "dialog-info"  element, the contents of the table are flushed and then repopulated from the document."

 

The table is still maintained, including the local version number. It's just the respective rows in the table that gets removed/flushed.

 

† 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>.