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

We've enabled INVITE validation using the following config options:

voIpProt.SIP.requestValidation.1.request="INVITE"
voIpProt.SIP.requestValidation.1.method="source"
voIpProt.SIP.requestValidation.2.request="OPTIONS"
voIpProt.SIP.requestValidation.2.method="source"

 

It works properly, except when the phone has a second line registration configured on it (eg 101, 102).

When the INVITE is sent addressed to the second line (102), the phone responds "400 Bad Request", as it does when an INVITE comes from a source the phone is not registered to. I've observed this on multiple phones now.

While testing against one phone, I was able to replicate this, and immediately after doing this the phone uploaded an applog containing the following:

0109105127|dns |4|03|doDnsLookupForList: given NULL hostname in task tPktProSys
0109105127|sip |4|03|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
0109105127|sip |4|03|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '41.2' found no records

 

(each of the above lines repeated many times). (41.2) is part of the IP address of the switch that the phone is registered to, where the INVITE came from, and should have been accepted.

I switched the line registration order around (from 101, 102 to 102, 101), and the behaviour switched to match; I could now call 102, but not 101.

This is affecting multiple models of phones, running multiple different versions of firmware.

The phone I am testing against is a VVX300 running 5.1.3.1675.

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

 

Hi Steffen,

I got in contact with Polycom and was given case 723913077 - Validation causing problems with line two.

They looked at this forum post, and asked for some additional information, logs, packet captures etc.

While performing the packet capture, I noticed something which I had not previously; the phone was doing NAPTR and SRV lookups for the registration for the second and third registrations on the phone, which I thought I had disabled/forced the phone to only do A lookups, by specifying the transport of UDPOnly, and specifying the port of 5060 on all registrations.

I checked the config and discovered that the transport and port was only being specified properly for the first registration. I added the transport specification to the second registration and updated the phone's config. After doing so the phone then accepted the call to the second registration, which it had been responding "400 Bad Request" to previously. If I tried against the 3rd registration, which I had not added the transport/port to, then it still refused the INVITE with 400 Bad Request.

So the issue appears to be caused by whether the phone registers by doing an A lookup or a NAPTR/SRV lookup, and/or if the transport is specified.

if I have this in the config:

reg.2.server.1.address="example.com"
reg.2.server.1.port="5060"
reg.2.server.2.address="example.com"

Then the phone does NAPTR/SRV lookups to register, and will not accept INVITEs to this registration. If I have following:

reg.2.server.1.address="example.com"
reg.2.server.1.port="5060"
reg.2.server.1.transport="UDPOnly"
reg.2.server.2.address="example.com"
reg.2.server.2.transport="UDPOnly"

Then the phone does A lookups, registers, and will accept the INVITE. I tested to see if the port specification was part of the issue, by sending the INVITE to the secondary registration via server 2 which did not have the port specified, but it still correctly accepted the INVITE, so it's the transport specification (or lack thereof) alone which is causing this issue.

I performed 3 packet captures. I have 2 phones, phone "A" (IP330) with INVITE validation disabled, and a single registration of 112. Phone "B" (VVX300) has 3 registrations and validation enabled, line 1 is 102, line 2 is 101, and line 3 is 111.

The first packet capture showed:

I can call from B to A with no issues,
I can call from A to B line 1,
I can't call from A to B on line 2 or 3, the phone responds "400 Bad Request" after performing NAPTR/SRV lookups.

Packet capture 2 (after adding the transport specification to reg.2) showed:

I can call from A to B on line 2 now,
I still can't call from A to B on line 3, "400 Bad Request" is returned.

Packet capture 3 (with phone A only registered to server 2), showed:

I can still call from A to B on lines 1 and 2,
I still can't call from A to B on line 3, "400 Bad Request" is returned.

So it appears the resolution to this issue is for me to make sure that all our phones include transport="UDPOnly" in their registration configuration. Once I added this to reg.3 and rebooted the phone I could call all 3 lines/registrations without the phone doing NAPTR and SRV lookups before returning "400 Bad Request".

 

I have made the config changes on our provisioning server and re-enabled the INVITE validation, so we'll see if it works properly in production this time.

View solution in original post

7 REPLIES 7
HP Recommended

Hello Squigley

did you modify the IP address or is this as it is being displayed ?

 

I can only urge you to open a Ticket on this (and provide me with the number) so we can verify this and fix if this is broken.


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

Best Regards

Steffen Baier

Polycom Global Services

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

Hi Steffen,

 

I didn't modify the IP address, that's exactly as it displayed in the log it uploaded.

 

I'm in the process of trying to open a ticket, there were/are issues with our partner registration which I've been trying to get resolved so that we can open tickets.

 

In the mean time I figured I would open a thread here in case it was something you knew about.

 

I enabled syslogging on the phone, and tried calling a registration on a line other than the first line, and got the following:

 

sip  |0|00|listener: Received packet from [switch ip]:5060
sip  |0|00|<<<Data Received UDP
sip  |0|00|    INVITE sip:111@10.100.0.221:5080 SIP/2.0
sip  |0|00|    Via: SIP/2.0/UDP [switch ip]:5060;branch=z9hG4bKWQPJIAhIqTWVT8VLE684AE
sip  |0|00|    Call-ID: 20150112151844045104-508a49ea1a0a17f284f0f0f66fa5fcd2
sip  |0|00|    Contact: <sip:[switch ip]:5060;transport=udp>
sip  |0|00|    CSeq: 201 INVITE
sip  |0|00|    Expires: 180
sip  |0|00|    From: "VERSATURE CORP" <sip:[redacted]>;tag=WQPJIAhIqTWVT8VLE684AE
sip  |0|00|    Max-Forwards: 20
sip  |0|00|    To: <sip:111@example.com>
sip  |0|00|    Date: Mon, 12 Jan 2015 15:18:44 GMT
sip  |0|00|    Server: NetSapiens SiPBx 1-1224g2
sip  |0|00|    Allow-Events: as-feature-event
sip  |0|00|    Allow-Events: call-info
sip  |0|00|    Allow-Events: presence
sip  |0|00|    Allow-Events: line-seize
sip  |0|00|    Allow-Events: dialog
sip  |0|00|    Allow-Events: refer
sip  |0|00|    Allow-Events: message-summary
sip  |0|00|    Supported: timer
sip  |0|00|    Min-SE: 600
sip  |0|00|    Session-Expires: 3600
sip  |0|00|    Content-Type: application/sdp
sip  |0|00|    Content-Length: 186
sip  |0|00|    
sip  |0|00|    v=0
sip  |0|00|    o=NetSapiens_Nms 3736716973 3736716973 IN IP4 [switch ip]
sip  |0|00|    s=sip call
sip  |0|00|    c=IN IP4 [switch ip]
sip  |0|00|    t=0 0
sip  |0|00|    m=audio 24122 RTP/AVP 0 18 101
sip  |0|00|    a=rtpmap:101 telephone-event/8000
sip  |0|00|    a=ptime:20
sip  |3|00|CStkDialog::CreateRouteSet: transport set to Target URI 'UDP'
sip  |3|00|CStkDialog::SetAddressLocal localTag set to ''
sip  |3|00|CStkDialog::SetAddressLocal new address added of 1
sip  |2|00|CStkDialog::CStkDialog SetAddressLocal from pRequest To: 'Test' <111@example.com:0>
sip  |2|00|CStkDialog::CStkDialog SetAddressLocal Config 'Test' <111@[switch domain name]:0>
sip  |2|00|CStkDialog::CStkDialog TAG '4A00ABD8-84CB15FF' generated
sip  |2|00|CStkDialog::CStkDialog local addr 'Test' <111@example.com:0> Tag '4A00ABD8-84CB15FF'
sip  |2|00|CStkDialog::CStkDialog exit 0xbb9b18 local list size 1
sip  |2|00|CCallBase::IsChallenged COPIED Dialog Tag to pRequest '4A00ABD8-84CB15FF'
sip  |2|00|CCallBase::IsChallenged 'INVITE' Dialog Tag '4A00ABD8-84CB15FF' pRequest Tag '4A00ABD8-84CB15FF' state 'Trying'
sip  |1|00|Try to do source validation
sip  |1|00|CCallBase::IsTrusted : NAPTR lookup for '[switch primary domain name]' OK
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |1|00|CCallBase::IsTrusted : NAPTR lookup for '[switch secondary domain name]' OK
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '(null)' found no records. 
dns  |4|00|doDnsLookupForList: given NULL hostname 
sip  |4|00|doDnsListLookup(NULL): doDnsSrvLookupForARecordList '' found no records
sip  |3|00|Challenge failed !!
sip  |2|00|new UA Server Non-INVITE trans state 'callingTrying', timeout=0 (0x40e42c88)
sip  |3|00|UA Server Non-INVITE INVITE trans state 'callingTrying'->'completed' by 400 resp 65 timeout(0x40e42c88)
sip  |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '[switch ip]' port 5060 returned 1 results
sip  |1|00|doDnsListLookup(udp): result 0 '[switch ip]' port 5060 isInBound 0
sip  |0|00|Trying to send data to Destination [switch ip] on socket 111
sip  |0|00|>>> Data Send to [switch ip]:5060
sip  |0|00|    SIP/2.0 400 Bad Request

 

If I send the INVITE to the primary line registration, I get the following:

 

sip  |2|00|CCallBase::IsChallenged 'INVITE' Dialog Tag '28140B24-3F0E0E23' pRequest Tag '28140B24-3F0E0E23' state 'Trying'
sip  |1|00|Try to do source validation
sip  |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '[switch primary domain name]' port 5060 returned 1 results
sip  |1|00|doDnsListLookup(udp): result 0 '[switch ip]' port 5060 isInBound 0
sip  |4|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList '(null)' found no records. 
sip  |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '[switch secondary domain name]' port 5060 returned 1 results
sip  |1|00|doDnsListLookup(udp): result 0 '[switch secondary ip]' port 5060 isInBound 0
sip  |1|00|CCallBase::IsTrusted Source IP:[switch ip] and Server IP[switch ip]
sip  |1|00|CCallBase::IsTrusted Source IP:[switch ip] and Server IP[switch secondary ip]
sip  |2|00|new UA Server INVITE trans state 'proceeding', timeout=0 (0x40e48528)
sip  |1|00|Dialog 'id8e73b81f' State 'Trying'->'Early'
sip  |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '[switch ip]' port 5060 returned 1 results
sip  |1|00|doDnsListLookup(udp): result 0 '[switch ip]' port 5060 isInBound 0
sip  |0|00|Trying to send data to Destination [switch ip] on socket 111
sip  |0|00|>>> Data Send to [switch ip]:5060
sip  |0|00|    SIP/2.0 100 Trying

 

HP Recommended

Hello Squigley

I gave this a quick try both with simple IP or FQDN registered SIP Lines and could not reproduce this.

 

In order to troubleshoot this we require your config and everything else. Once you got this raise please share the ticket number with myself.

 

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


Best Regards

Steffen Baier

Polycom Global Services

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

 

We're still trying to find out the details of how we can open a ticket to report this issue.

 

In the mean time if you have 2 phones in your lab to test with, I can provide provisioning server details and/or config files, and you can connect 2 phones to our switch, both with 2 lines registered, one with validation on, and one off, and you can test to see that you won't be able to call the second line on the phone with invite validation.

 

Is this something you are willing to test, or would you rather I wait to get the information on how to open the ticket before proceeding?

HP Recommended

Hello Squigley


I am based in the EMEA region and I assume you are in North America so I prefer if the team over there deals with it.

 

From memory I believe you already dealt with Polycom support so if you have a MAC for a phone or a case number I can check who the reseller is.

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

Best Regards

Steffen Baier

Polycom Global Services

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

 

Hi Steffen,

I got in contact with Polycom and was given case 723913077 - Validation causing problems with line two.

They looked at this forum post, and asked for some additional information, logs, packet captures etc.

While performing the packet capture, I noticed something which I had not previously; the phone was doing NAPTR and SRV lookups for the registration for the second and third registrations on the phone, which I thought I had disabled/forced the phone to only do A lookups, by specifying the transport of UDPOnly, and specifying the port of 5060 on all registrations.

I checked the config and discovered that the transport and port was only being specified properly for the first registration. I added the transport specification to the second registration and updated the phone's config. After doing so the phone then accepted the call to the second registration, which it had been responding "400 Bad Request" to previously. If I tried against the 3rd registration, which I had not added the transport/port to, then it still refused the INVITE with 400 Bad Request.

So the issue appears to be caused by whether the phone registers by doing an A lookup or a NAPTR/SRV lookup, and/or if the transport is specified.

if I have this in the config:

reg.2.server.1.address="example.com"
reg.2.server.1.port="5060"
reg.2.server.2.address="example.com"

Then the phone does NAPTR/SRV lookups to register, and will not accept INVITEs to this registration. If I have following:

reg.2.server.1.address="example.com"
reg.2.server.1.port="5060"
reg.2.server.1.transport="UDPOnly"
reg.2.server.2.address="example.com"
reg.2.server.2.transport="UDPOnly"

Then the phone does A lookups, registers, and will accept the INVITE. I tested to see if the port specification was part of the issue, by sending the INVITE to the secondary registration via server 2 which did not have the port specified, but it still correctly accepted the INVITE, so it's the transport specification (or lack thereof) alone which is causing this issue.

I performed 3 packet captures. I have 2 phones, phone "A" (IP330) with INVITE validation disabled, and a single registration of 112. Phone "B" (VVX300) has 3 registrations and validation enabled, line 1 is 102, line 2 is 101, and line 3 is 111.

The first packet capture showed:

I can call from B to A with no issues,
I can call from A to B line 1,
I can't call from A to B on line 2 or 3, the phone responds "400 Bad Request" after performing NAPTR/SRV lookups.

Packet capture 2 (after adding the transport specification to reg.2) showed:

I can call from A to B on line 2 now,
I still can't call from A to B on line 3, "400 Bad Request" is returned.

Packet capture 3 (with phone A only registered to server 2), showed:

I can still call from A to B on lines 1 and 2,
I still can't call from A to B on line 3, "400 Bad Request" is returned.

So it appears the resolution to this issue is for me to make sure that all our phones include transport="UDPOnly" in their registration configuration. Once I added this to reg.3 and rebooted the phone I could call all 3 lines/registrations without the phone doing NAPTR and SRV lookups before returning "400 Bad Request".

 

I have made the config changes on our provisioning server and re-enabled the INVITE validation, so we'll see if it works properly in production this time.

HP Recommended

 

As an update to this ticket, making sure that the transport was specified appears to have resolved the issue.

 

We heard from a customer of ours that they were having issues receving calls, and when I looked I saw "400 Bad Request" from their phones, and noticed that they were using IP430s, running 3.2.7.

 

I downgraded an IP330 from 3.3.5 to 3.2.7 (since we don't have a 430 on hand), and attempted to replicate the issue, which I was able to. With the syslogging turned up, I saw the following in response to a legitimate INVITE (on the first/single line registration):

 

sip |1|00|Try to do source validation
sip |3|00|Challenge failed !!
sip |0|00|>>> Data Send to [switch ip]
sip |0|00| SIP/2.0 400 Bad Request

INVITE source validation looks like it's buggy or broken in 3.2.7, but since 3.2.7 is from May 2012 I don't expect this to be fixed 🙂 I disabled the source validation on this model, and instead changed the listen port on the phone to avoid issues from SIP port probing:

 

voIpProt.local.port="[not 5060]"
voIpProt.SIP.local.port="[not 5060]"

 

Only the first one should have been necessary, based on page A6/160 of the "March, 2009 Edition 1725-11530-310 Rev. C
SIP 3.1.2B" Admin Guide, but it didn't change until I added the second one, which isn't documented in that version of the Admin Guide.

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