-
×InformationWindows update impacting certain printer icons and names. Microsoft is working on a solution.
Click here to learn moreInformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center.
-
×InformationWindows update impacting certain printer icons and names. Microsoft is working on a solution.
Click here to learn moreInformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center.
- HP Community
- Poly Phones
- Desk and IP Conference Phones
- INVITE validation fails against second line registration
Create an account on the HP Community to personalize your profile and ask a question
01-09-2015 12:11 PM
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.
Solved! Go to Solution.
Accepted Solutions
02-09-2015 03:31 PM
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.
01-12-2015 01:04 AM
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
01-12-2015 08:50 AM
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
01-12-2015 10:51 AM
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
01-15-2015 09:28 AM
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?
01-15-2015 12:05 PM
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
02-09-2015 03:31 PM
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.
02-19-2015 11:59 AM
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.
Didn't find what you were looking for? Ask the community