Multiple SIP registrar on CUBE

[Difan Zhao]

Hi guys,

My company had contractor setup all the SIP trunks. Now I took it over but I am with limited knowledge on voip in general. We have four registrars and I see right now I am authenticating with each one with all of the credentials configured... Here is my sip-ua config

sip-ua
credentials username 5873496659 password 7 xxx realm Realm
credentials username 119775_cube password 7 xxx realm seattle2.voip.ms
credentials username 119775_cubeyvr password 7 xxx realm vancouver.voip.ms
credentials username 4033013400 password 7 xxx realm voip.pasonvoip.infosat.com
authentication username 119775_cube password 7 xxx realm seattle2.voip.ms
authentication username 119775_cubeyvr password 7 xxx realm vancouver.voip.ms
authentication username 5873496659 password 7 xxx realm Realm
authentication username 4033013400 password 7 xxx realm voip.pasonvoip.infosat.com
no remote-party-id
retry invite 2
retry register 10
timers connect 100
registrar 1 ipv4:10.185.36.107:5060 expires 3600
registrar 2 ipv4:50.23.160.51:5060 expires 200 auth-realm seattle2.voip.ms
registrar 3 ipv4:162.213.157.82:5060 expires 200 auth-realm vancouver.voip.ms
registrar 4 dns:voip.pasonvoip.infosat.com expires 60
sip-server ipv4:10.185.36.107:5060

So for the registrar #1, I am authenticating with all four usernames configured. Is there a reason why and is there a way to stop that sort of behavior?

Also what is the difference between "credentials" and "authentication" in the config? What is the "sip-server" config for in the last line? Apparently it is only for one of the registrars, not any others... Do I need this line?

Thank you and have a great weekend

Difan

[ADAM CRISP]

Let me answer the last question first.

The Authentication username command is used to give the router a username to use if another SIP server challenges it for Authentication.

This is typically used for making telephone calls

For example when you send a call to a Service provider:
1. You send a SIP Invite message to the SP to make a call
2. The SIP service provider replies with a 100 trying message
3. The SIP service provider send back a 407 Authentication required message and within the message will include an "authentication realm". The Authentication realm might be as in your example: voip.pasonvoip.infosat.com
4. Your router looks in the list of authentication usernames and spots one with the voip.pasonvoip.infosat.com realm. It then send the SIP invite message again to the SP, but this time includes the 4033013400 SIP username and a hash of the password.

The sip-server command under sip-ua gives the router a default sip route to use unless a better one is configured elsewhere in the configuration. (normally in dial-peer) -

Registrations:
There are certain SIP addresses that your router owns.
This means if a SIP call is received by this router, the call belongs on this router and the call proceeds with the router terminating the call

For example:
You have an FXS port on the router with a phone plugged in. It has number 1234. The router will accept a call to sip:1234@your-router
or
You have a call manager express router with an ephone-dn number 4321, the router will accept a call to sip:4321@your-router

The registrar command under sip-ua gives the router a server to send SIP register messages to.
The registration process exists primarily to tell a 3rd party system which contact addresses are valid on your router and what IP address you have. This builds something called the AOR - Address of Record.
If you have a registrar configured under SIP-UA, by default the router will try to register all addresses that the router owns
This is why under ephone-dn you often see the keyword - no reg primary - meaning don't register this address

The credential keyword simply gives the router some extra contact addresses to register externally. This is often required to when registering to a sip service provider that requires you to register with a particular contact.

About getting the router to stop sending registers to the wrong registrar - haven't tried - but check out the auth-realm option. This might do it.

i.e. registrar 1 ipv4:10.185.36.107:5060 expires 3600 auth-realm Realm

hope this helps.

Adam.

[Difan Zhao]

Hey thanks a lot Adam. You clarified many questions for me. Unfortunately the auth-realm did not work... I tried the following config and I somehow still see multiple authentication with other usernames. But with some of the knowledge now thanks to you I will do some research myself too.

registrar 4 dns:voip.pasonvoip.infosat.com expires 60 auth-realm voip.pasonvoip.infosat.com

So another question is that the source IP used by the registration and the IP used for the invite. So the dial-peer has "voice-class sip bind control/media xxx". I think that this is for the Invite, correct? So can I specify the source IP/interface for the register messages?

The problem I have right now is that I want to use a different interface/IP for some registrar but they all somehow come from one interface Gi0/0/0. It is not compliant with the routing table too. Actually only one registrar (#1) should use Gi0/0/0 based on the routing table and the others should use Gi0/0/2. However they all used Gi0/0/0 as the source IP for the registrar... What config might have cuased this? Is it the "SIP server" config or is it the "Bind" config under voice service voip / sip ?

Thanks!

Difan

[Mohammed al Baqari]

Your understanding is correct. 407 message associated with INVITE will require authentication command to kick in.

For question 2, the source address for register messages will be based on global config. (voice service voip > sip > bind)

[Difan Zhao]

Thanks Mohammed. Notes taken.

However I still have the problem that the CUBE uses all the usernames configured to try to register with the registrar. That does not happen when it is authorizing the INVITE where only the correct one is being sent based on the realm configured. I have tried "auth-realm Realm" as Adam suggested but that did not work... Any ideas? Thanks!

[ADAM CRISP]

Hi,

Please can you:

1. Post the output of debug ccsip messages for the registration attempts to registrar #1, I would like to see all the contacts being registered.

2. re-post your sip-ia configuration section if it's changed.

3. Please advise on whether or not you have any sip outbound-proxies configured.

(these will be under voip service voip, sip)

4. Please confirm you have no ephone-dn's, other directory numbers, pots dial-peers, analogue ports or similar with numbers configured that are the same as the ones listed in your sip-ua section

All four authentication usernames have a realm configured, so each username should be used for that realm only, so I want to make sure I understand your question correctly.

Thanks

Adam

[Difan Zhao]

Hi Adam,

I will get you the "debug ccsip messages" tomorrow. Right now however I can share with you this show output. As you can see that all the registrar are using all the credentials configured

CACALPV2-VCUBEA03-01#sho sip-ua register status
--------------------- Registrar-Index  1 ---------------------

Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
119775_cube                      -1         50           no  normal
119775_cubeyvr                   -1         50           no  normal
4033013400                       -1         59           no  normal
5873496659                       -1         1989         yes normal

--------------------- Registrar-Index  2 ---------------------

Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
119775_cube                      -1         105          yes normal
119775_cubeyvr                   -1         51           no  normal
4033013400                       -1         27           no  normal
5873496659                       -1         51           no  normal

--------------------- Registrar-Index  3 ---------------------

Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
119775_cube                      -1         29           no  normal
119775_cubeyvr                   -1         79           yes normal
4033013400                       -1         22           no  normal
5873496659                       -1         29           no  normal

--------------------- Registrar-Index  4 ---------------------

Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
119775_cube                      -1         89           no  normal
119775_cubeyvr                   -1         52           no  normal
4033013400                       -1         0            no  normal
5873496659                       -1         11           no  normal

Only difference in the sip-ua config is that for the one that I am testing, I added "auth-realm" for the registrar

sip-ua
 credentials username 5873496659 password 7 xxx realm Realm
 credentials username 119775_cube password 7 xxx realm seattle2.voip.ms
 credentials username 119775_cubeyvr password 7 xxx realm vancouver.voip.ms
 credentials username 4033013400 password 7 xxx realm voip.pasonvoip.infosat.com
 authentication username 119775_cube password 7 xxx realm seattle2.voip.ms
 authentication username 119775_cubeyvr password 7 xxx realm vancouver.voip.ms
 authentication username 5873496659 password 7 xxx realm Realm
 authentication username 4033013400 password 7 xxx realm voip.pasonvoip.infosat.com
 no remote-party-id
 retry invite 2
 retry register 10
 timers connect 100
 registrar 1 ipv4:10.185.36.107:5060 expires 3600
 registrar 2 ipv4:50.23.160.51:5060 expires 200 auth-realm seattle2.voip.ms
 registrar 3 ipv4:162.213.157.82:5060 expires 200 auth-realm vancouver.voip.ms
 registrar 4 dns:voip.pasonvoip.infosat.com expires 60 auth-realm voip.pasonvoip.infosat.com
 sip-server ipv4:10.185.36.107:5060

Not sure about the sip oubound-proxy though... I don't think so. I did "show run | in outbound" and it returned nothing.

Absolutely no ephone-dns, pots dial-peer, analog lines and such. Only SIP trunks are present

Thanks!!

Difan

[Nikita Sokolov]

In a Cisco UBE multihome environment, all sets of credentials configured under the SIP user agent are sent
to all configured registrars, regardless of realm configuration. This meansthat if a Cisco UBE registers multiple
service providers, the credentials for both service providers are sent out to both. While the correct credentials
will register, the incorrect sets will fail, possibly resulting in security measures taken by the service provider
for failed registration attempts.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-multi-trunks.pdf

[Ruslan Akhmyatzanov]

I suppose that since version Cisco IOS 15.6(2)T it's possible to change this behaviour by configuring Multi-Tenant 

Here's the example from the CUBE configuration guide:

Router# show run | sec tenant
Voice class tenant 1
registrar 1 ipv4:10.64.86.35:9051 expires 3600
credentials username aaaa password 7 06070E204D realm aaaa.com
outbound-proxy ipv4:10.64.86.35:9057
bind control source-interface GigabitEthernet0/0
Voice class tenant 2
registrar 1 ipv4:9.65.75.45:9052 expires 3600
credentials username bbbb password 7 110B1B0715 realm bbbb.com
outbound-proxy ipv4:10.64.86.40:9040
bind control source-interface GigabitEthernet0/1 

[Mohammed al Baqari]

Hi Difan,

The authentication behavior can handle challenges from different service providers for SIP REGISTER and SIP INVITE/Other messages.

The credentials command is used to trigger SIP Register requests wherever registration is required.

This is how they are used:

1. If the realm specified in the challenge matches the realm in the authentication configuration for a POTS dial peer, the system uses the corresponding username and password.
2. If the realm specified in the challenge doesn't match the configured authentication for the POTS dial peer, then it will check for credentials configured for SIP UA.
3. If the realm specified in the challenge does not match the realm configured for credentials, then it will check for authentication configurations for SIP UA.
4. If the system does not find a matching authentication or credential for the received realm, then the request is terminated.
5. If there is no realm specified for the authentication configuration, then the system uses the username received from the challenge to build the response message.

For part 2 of the question, this is usually used to point dial-peers to 'sip-server' keyward instead of specifying the IP address in each dial-peer.

[Difan Zhao]

Thanks Mohammed. That makes sense. I see that when doing the registration, the registrar would give me an 401 unauthorizaed for SIP REGISTER. Then I would use the "credential" config to authenticate. However I also see that the registrar would send 407 proxy authentication required for SIP INVITE/Other. Is it when the "authentication" config is used? Is the understanding correct?

Please also see my other question in my response to Adam down below...

Thanks,

Difan