requestValidation what value for x?

[Anonymous]

I am looking in the admin guide in the section pertaining to requestValidation. It seems fairly well documented, except for what value goes in for x?


<voIpProt.SIP.requestValidation voIpProt.SIP.requestValidation.x.method="source" voIpProt.SIP.requestValidation.x.request="INVITE" />

1 seems like the obvious beginning. When would I use 2?

[SteffenBaierUK]

Hello @MHammett,

welcome to the Polycom Community.

A quick community search shows this => here <=

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

[Anonymous]

That doesn't seem to explain it clearly.

I can assume the OP said 1 for line 1 and 2 for line 2, but this isn't explicitly stated anywhere I've found yet.

[SteffenBaierUK]

Hello @MHammett,

The 1,2 etc is not for the line it is for the Source Identification being used.

We support INVITE, ACK, BYE, REGISTER, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, REFER, PRACK, UPDATE

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

[Anonymous]

I don't think we're on the same page. I'm not yet to the request method. I'm at the x in the example in the original post.

I can't find anything on "Source Identification" either.

[SteffenBaierUK]

Hello @MHammett,

I am unclear how there can be a follow up question but the parameter discussed works in pairs:

voIpProt.SIP.requestValidation.1.method

voIpProt.SIP.requestValidation.1.request 

The method aka Source, Method,both or nothing works against the request aka INVITE, ACK , BYE, REGISTER, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, REFER, PRACK, UPDATE

If you want the method with a value of source against the Invite but for x aka 2 the cancel against the digest.

We usually use this parameter against ghost calls as described => here <= and it is applied against all registrations.

If you still have questions that cannot be answered by the Community please open a ticket.

In order to raise a support ticket you need to work with your Polycom reseller as they need to do this for you.

End Customers are unable to open a ticket directly with Polycom support.

If this is some sort of an Internet discounter please post either your phone's MAC address or your Polycom devices serial so I can look up who would be able to support you. This may not be who you purchased the Polycom device from.

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

[Anonymous]

There are followup questions because the question hasn't actually being answered.

I have seen the thread you linked to. I am here looking to avoid ghost calls. Note the example given specifically mentions reg.1, which is where I got the correlation from requestValidation.1 and reg.1.

I've also been looking at an Administrator's guide. I assume the version is irrelevant as the functionality would be the same. https://supportdocs.polycom.com/PolycomService/support/global/documents/support/setup_maintenance/pr...

So a complete example with one form of validation would be:
voIpProt.SIP.requestValidation

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

That would only accept INVITE messages that match the servers registered to.

So then you could append something like this:
voIpProt.SIP.requestValidation.2.method="digest" voIpProt.SIP.requestValidation.2.request="CANCEL"

voIpProt.SIP.requestValidation.digest.realm="registered_users@server.company.com"

If you wanted to also validate against digest CANCEL messages from the authentication process?

If that's the case, then what's the point of the "both" method?

[SteffenBaierUK · Accepted solution]

Hello @MHammett,

For the greater good of the community I ran this by a colleague of mine.

What is the x and y for in the voIpProt.SIP.requestValidation parameters?

• x requires an integer value from 1 – 20.
• y requires an integer value from 1 – 20.

When validating a request, you may choose to validate multiple different SIP methods differently such that all INVITE and REFER requests have source address validation, NOTIFY messages are only validated when received for the dialog & talk events whereas other SUBSCRIBES are not validated, and that BYE messages receive digest authentication

voIpProt.SIP.requestValidation.1.request="INVITE"
voIpProt.SIP.requestValidation.1.method="source"
voIpProt.SIP.requestValidation.2.request="REFER"
voIpProt.SIP.requestValidation.2.method="source"
voIpProt.SIP.requestValidation.3.request="NOTIFY"
voIpProt.SIP.requestValidation.3.request.1.event="dialog"
voIpProt.SIP.requestValidation.3.request.2.event="talk"
voIpProt.SIP.requestValidation.3.method="source"
voIpProt.SIP.requestValidation.4.request="BYE"
voIpProt.SIP.requestValidation.4.method="digest"

Source address validation should be any IP address that is included in the set of IPs from reg.1.server.1.address, reg.1.server.2.address, reg.1.server.3.address, etc.

If source validation is desired, it is Polycom's recommendation to use Re-Registration On Failover (RROFO) instead of the older requestValidation parameters as this will provide source validation based on addresses returned using DNS SRV or A record queries as well as provide failover control.

To Enable RROFO, set one of the following global or per registration settings to "1"

voIpProt.server.x.failOver.reRegisterOn
voIpProt.SIP.outboundProxy.failOver.reRegisterOn
reg.x.server.y.failOver.reRegisterOn
reg.x.outboundProxy.failOver.reRegisterOn

Any further follow up questions need to be raised as a support ticket as already outlined.

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

[Anonymous]

Sorry for being a pain in the backside, but that last post is exactly what I was looking for. Hopefully people can Google their way to this answer.