403 forbidden [TLS required]

[makemetrend]

Hi,

Hoping you could help me on issue that we encountering on oir vantage k175. When we dial vantage to any extensiom, it is working. But wheb we dial the extension of the vantage we encounter an error on traceSM 403 Forbidden TLS Required.

We have cm,sm,smgr. CM to SM signalling is on tcp 5060

Also on smgr ive already added tls and tcp on the listening ports. Ive tried re-adding the listening ports but it is not working.

 

[kyle555]

Does anything get to the Vantage at all when you call it in terms of SIP messaging?
How are you getting to your OPTIM trunk in CM? Through a route pattern? If so, is Secure SIP enabled at the top right?

I'd reckon you've got sips URIs coming across somewhere.

Are you able to register the Vantage as another SIP station - like a 9608 and then register a 9608 on the Vantage's extension to prove the problem follows the endpoint and not the extension?

 

[makemetrend]

Hi kyle, i believe secure sip is enabled on signalling group of cm to sm. Also on the sip proxy list we are using tcp not tls.

 

[kyle555]

And do you have other non-Vantage SIP phones working?

In your sig group, the parameter enforce SIPS URI for SRTP means that it's not enough to be TLS to do SRTP but you also have to be using the SIPS URI scheme, which isn't your problem.

In the route pattern, Secure SIP would make CM use the SIPS URI scheme going out.

That's why I asked if you have other non-Vantage SIP phones working like a 9608 and if you swap their extensions if the problem follows the extension or the device. It could be as simple as a different AAR match for this Vantage extension that hits a route with Secure SIP enabled. In any event, you should always try to be TLS because it makes life easier - things like Presence depend on it. Regardless, if something hits SM from CM with a SIPS URI for a phone registered TCP, then SM is right to forbid you.

Here's a fun little bit from section 26.2.2 of RFC3261

   A SIPS URI can be used as an address-of-record for a particular user
   - the URI by which the user is canonically known (on their business
   cards, in the From header field of their requests, in the To header
   field of REGISTER requests).  When used as the Request-URI of a
   request, [highlight #FCE94F]the SIPS scheme signifies that each hop over which the
   request is forwarded, until the request reaches the SIP entity
   responsible for the domain portion of the Request-URI, must be
   secured with TLS;[/highlight] once it reaches the domain in question it is
   handled in accordance with local security and routing policy, quite
   possibly using TLS for any last hop to a UAS.  When used by the
   originator of a request (as would be the case if they employed a SIPS
   URI as the address-of-record of the target), SIPS dictates that the
   entire request path to the target domain be so secured.

 

[makemetrend]

Hi Kyle!

In addition to this, whenever the phone goes off-hook it goes busy tone we get 480 sips not allowed but when we try to dial when on busy tone, it can dial outside but still no incoming call even if local to local only still TLS required. The route pattern going to SM, the secure is set to no.

 

[kyle555]

Yeah, so phones send a msg to CM inviting themselves - like knowing you went off hook.

That follows the App Sequence which goes to a SIP entity for CM. At no point does the entity define which entity link to use.

So, if the phone is TLS, and the only entity link between CM/SM is TCP, then that's the appropriate error. It's the same as the 403.

Phone TLS to SM to CM as TCP. CM says "SIPS in TLS? Heck no!" and you get that error.
When calling from CM to the phone, SM sees the same thing - SIPS in TCP and uses a 403 instead.