Solved: Issue with external proxy registered Jabber client making extern - Page 2

Chris Swinney · ‎07-03-2013

Hi All,

This is a bit of a continuation from a discussion started by thorstenn called Problem registering movi to VCSe (VCSc working). That thread was getting a little bloated an this is question has now moved on from that.

Essentially we are setting up a test system in order to allow both Internal and External Jabber users to register and make/receive calls. Whilst the internal users register directly with the internal VCS-C, the external Jabber user will connect via the VCS-E that should proxy the registration (and all other requests) to the VCS-C.

Essentially it this type of scenario:

This is fine - External Jabber user can register with no issues.

The problem comes with the sending of presence information to the external Jabber client from third party devices (although this is OK from the internal registered Jabber client), but more importantly the External Jabber user cannot make calls to external third parties.

To explain what I mean, I have diagrams the following call flows. The first shows the call flows that work, the second shows what fails.

In an attempt to get this working, and as this is a test system, I pretty much rebuilt the dial plan search rule and pre-search transforms as per the "Cisco TelePresence Video Communication Server Basic Configuration (Control with Expressway)" guide, (although I have NOT set a SIP domain on the VCS-E), but no joy.

We do have a VCS-E cluster, but we have even broken this so that there were was only one VCS-E --> one VCS-C, but no joy.

Essentially the search that is invoked on the VCS-C find NO matching rules. Of course the similar search that happens when the local client dial out works OK and is passed up the traversal zone.

The only thing I could think of is a search coming from the traversal zone cannot pass back up the same zone. However, In know other have this scenario working (Paulo answer this for me in the other thread).

Following is the are the search output from a call placed by a local client which connects fine (please not I have edited IP addresses and aliases, but have ensured they are consistent):

Search (185)

State: Completed

Found: True

Type: SIP (INVITE)

CallRouted: True

CallSerial Number: 4066b06a-e407-11e2-84e0-0010f31ed960

Tag: 4066b20e-e407-11e2-b39a-0010f31ed960

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: int-jabber@mydom.com

Zone (1)

Name: SIP

Type: Local

Path (1)

Hop (1)

Address: IP_Add_Client:12177

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:swinster@otherdom.com

StartTime: 2013-07-03 18:37:37

Duration: 9.36

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: Search Rules

SearchRule (1)

Name: Expressway Query- E.164 and URI

Zone (1)

Name: Test Zone

Type: TraversalClient

Protocol: SIP

Found: True

StartTime: 2013-07-03 18:37:37

Duration: 9.34

Gatekeeper (1)

Address: IP_Add_Exp1:7200

Alias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

Now is the search from the same VCS-C with a call comming from the Externally registered Jabber client (ie. via the Traversal zone)

Search (184)

State: Completed

Found: False

Reason: Not found

Info: Policy Response

Type: SIP (INVITE)

CallSerial Number: ef77b7f8-e406-11e2-8d76-0010f31ed960

Tag: ef746c6a-e406-11e2-be5a-0010f31ae17c

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: ext-jabber@mydom.com

Zone (1)

Name: Test Zone

Type: TraversalClient

Path (1)

Hop (1)

Address: IP_Add_Exp1:7200

Hop (2)

Address: IP_Add_Client:12018

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:swinster@otherdom.com

StartTime: 2013-07-03 18:35:21

Duration: 0.01

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: swinster@otherdom.com

SubSearch (1)

Type: Search Rules

The search rule that I believe should be invoke in the dial plan is the last one listed (800):

Priority	State	Rule name	Protocol	Source	Authentication required	Mode	Pattern type	Pattern string	Pattern behavior	On match	Target	Actions

48

Enabled

Local Zone - no domain

Any

No

Alias pattern match

Regex

(.+)@mydom.com.*

Replace

Continue

LocalZone

View/Edit

50

Disabled

LocalZoneMatch

Any

No

Any alias

Continue

LocalZone

View/Edit

50

Enabled

Local zone – full URI

Any

No

Alias pattern match

Regex

(.+)@mydom.com.*

Leave

Continue

LocalZone

View/Edit

400

Enabled

External IP address search rule

Any

No

Any IP address

Continue

Test Zone

View/Edit

800

Enabled

Expressway Query- E.164 and URI

Any

No

Any alias

Continue

Test Zone

View/Edit

The only other thing we have tried is setting up a second traversal zone so essentially there is one zone routing in and one routing out. This did appear to make help as the calls were then connect although we still had no presence info from third parties, and this managed to cause Jabber to crash inconstantly!

Sorry for the long post but I'm sure a some of you will still want further info, so please let me know what I can offer.

Chris

Message was edited by: Chris Swinney Changed images and search histories to reflect domain distinction between endpoints

Chris Swinney · ‎08-01-2013

Sorted -Lovely. Thank you. 5 *

Now for some funky CPL....

Paulo Souza · ‎07-04-2013

Just adding one more cent:

So, because of provisioning with Jabber, I can provide a generic "SIP Authentication" Username and Password that is sent to the client without user knowing what it is. they can then use just their username/password combination and all looks great from their point of view.

I have read the post where Adam suggested this schema. But after reading the post, I came to conclusion that he was suggesting it as "quick fix", that's why he stated clearly it is not the best option. He said "The above is in no way a recommendation but just a little more information to chew on as you look to choose and implement what is best for you."

According to Adam, the best option is to use custom CPL configuration. I totally agree with that, that's why I also suggested CPL above (although I don't like CPL ).

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Chris Swinney · ‎07-04-2013

Hey Paulo,

Many thanks again for this detailed response. Yes, I did see Adams final words WRT his post and yes I did know about the potential for clear text authentication - we do currently only use TLS. Linphone supports it although if you are using self signed cert's (as in the test bed) you need to copy and paste the VCS Server PEM in the Linphone RootCA PEM. A bit of an hassle for users but we will look for use Certified cert's on the VCS-Es.

I have marked your answer above as Correct, even though I think there is no one correct answer for this particular question. However, you have given much to ponder over. I need to read up on CPL (oh joy!). I kinda skipped this bit in the Basic Setup guid and VCS admin guide .

Many thaks - I'm sure I will speak with you again soon.

Paulo Souza · ‎07-03-2013

Hi Cris,

Sorry, as your search history output shows "@mydom.com", I supposed you were talking about a external third party endpoint registered to your infrastructure.

Well, let me give you my understanding on how it should work:

You have jabber registered to VCSc via proxied registration in VCSe, fine! When this jabber makes a call, although it is not registered to VCSe directly, the call will be matched against VCSe's dial plan anyhow. So, let's say your VCSe has a DNS Zone working well. If you dial 999@externaldomain.com, on VCSe, you should route this call directly to DNS Zone, you shouldn't route it to VCSc and then route it back to VCSe, it makes no sense for me.

I know that you are aware about that behavior, and I know you don't want to use this method, but for me, it makes no sense routing the call to VCSc and then routing it back to VCSe. To avoid unknown users to reach your DNS Zone, you could set "Request must to be authenticated" in search rule configuration, then only registered/authenticated clients will be able to use this route. You could also use CPL to limit the access, as Martin suggested.

Well, in my opinion, the worse part of using proxied registration is exactly this behavior of routing things to VCSc and then routing them back to VCSe. I really don't like this. I prefer to use many CPL scripts and a complex dial plan than using proxied registration.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Chris Swinney · ‎07-03-2013

Hi Paulo

Paulo Souza wrote:

Hi Cris,

Sorry, as your search history output shows "@mydom.com", I supposed you were talking about a external third party endpoint registered to your infrastructure.

I have updated this in the diagrams and search history to make it clearer - apologies for causing confusion.

Paulo Souza wrote:

...you should route this call directly to DNS Zone, you shouldn't route it to VCSc and then route it back to VCSe, it makes no sense for me.

Yes - didn't want to open the thing up to an open proxy routing anyone's calls.

Paulo Souza wrote:

You could also use CPL to limit the access, as Martin suggested.

Well, in my opinion, the worse part of using proxied registration is exactly this behavior of routing things to VCSc and then routing them back to VCSe. I really don't like this. I prefer to use many CPL scripts and a complex dial plan than using proxied registration.

Looks like I have a bit MORE reading to do - I have only dabeled with CPL at this moment in time.

Paulo Souza · ‎07-03-2013

Paulo Souza wrote:
...you should route this call directly to DNS Zone, you shouldn't route it to VCSc and then route it back to VCSe, it makes no sense for me.

Yes - didn't want to open the thing up to an open proxy routing anyone's calls.

If you use the option "request must to be authenticated" in search rules, only authenticated devices will be able to reach the routes. If an external unknown endpoints sends a call to VCSe, VCS will never treat the endpoint as authenticated (unless you configure it) even if the endpoint marks the message as "authenticated", VCS won't trust it.

I use that as solution. I also use CPL, which is really required in some cases.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Chris Swinney · ‎07-04-2013

Cheers Paulo - see my reply above. I think I have a better understanding now.

Paulo Souza · ‎07-04-2013

Hi Cris,

Thanks for "right answer".

It is really nice to have topics like that where we can put all the possibilities over the table and then choose the best option according to the environment we are dealing with. It is really helpful!

Best regards,

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

labombaa69 · ‎07-04-2013

Hi All,

Just a clarification for me so I understand,

The externally registered Jabber is registered to the VCS-E or the VCS-C ??

If he's registered to the VCS-e and authenticated to the VCS-c and trys to make a call, Don't you have to have a non traversal license as well as traversal?? could this be the issue??

Paulo Souza · ‎07-04-2013

Hi Alan,

The externally registered Jabber is registered to the VCS-E or the VCS-C ??

Here, we are talking about an external jabber registered to VCS Control through proxied registration on VCSe. It is different scenario.

If he's registered to the VCS-e and authenticated to the VCS-c and trys to make a call, Don't you have to have a non traversal license as well as traversal?? could this be the issue??

If you have an external client registered directly to VCSe, when this client makes a call, this call will take traversal call license as well. It works normally. In another words, in this case, you don't need non-traversal call licenses in VCSe in order to allow your exeternal registered clients to call another external endpoints.

I hope this help.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Zac Colton · ‎07-31-2013

I read through some of the discussion here. I have an alternate design what will allow authenticated registration of Jabber on the Control and Expressway (without proxying the registration) and does not require the need to Provisioning data directly on the VCS Expressway. This design is for Active Directory authentication of Jabber clients, but the same basic principals will also work with using the Provisioning supplied credentials:

The VCS Control would have Active Directory Service enabled and joined to the Active Directory Domain. For the VCS to authenticate Movi/Jabber credentials against Active Directory before the SUBSCRIBE for provisioning is sent to the provisioning service, the Default Zone would be set for Check Credentials. For the SUBSCRIBE requests coming from the Expressway, the Traversal Zone on the VCS Control would also be set for Check Credentials. This will handle the authentication for provisioning.

The next part is the registration of the Movi/Jabber client. The subzone that the client will register to also needs to be set for Check Credentials. This is all you need for internal registrations (registration at the VCS Control).

For the Expressway, things get a little more complicated. For the provisioning subscription, the SUBSCRIBE is forwarded to the VCS Control. With the Traversal Zone on the VCS Control set for Check Credentials, you are all set. Now on to the registration to the Expressway. The subzone that the client will register to will need to be set for Check Credentials. Since the VCS Expressway does not have direct access to Active Directory, we need to utilize local credentials on the Expressway. A set of credentials will need to be configured in VCS Configuration > Authentication > Devices > Local Database. You will create a single name and password that all Movi/Jabber clients will use. The end user does NOT need to know of these credentials. The username and password is supplied to the Movi/Jabber client through the provisioning data that it has received. To configure that data, on the TMS, you need to configure a SIP Authentication Username and SIP Authentication Password in the provisioning configuration. For these options to be available, you need to make sure that you have uploaded the xml configuration template for the version of Movi/Jabber that you are using. The xml file is included with the full zip package of the client that can be downloaded from www.cisco.com. So that will take care of the Expressway registration. Now this creates an interesting situation with the VCS Control. The internal Movi/Jabber client will receive the same provisioning configuration, and will attempt to use those same credentials when registering to the VCS Control. The VCS Control is already set to authenticate the registration request against Active Directory, and ONLY Active Directory.

You will need to create an Active Directory account that matches those credentials. The Active Directory account does not need any special access. It is used for authentication purposes only. A few things to keep in mind: the SIP Authentication Username and SIP Authentication Password are stored in the provisioning configuration in clear text. That means that the data is sent in clear text. To be sure that this data is not compromised on the wire, be sure that you are using TLS for your Movi/Jabber SIP communication.

Paulo Souza · ‎07-31-2013

Hi Zac,

Thanks for sharing.

We did considered this possibility as well. If you read some topics above you will find it, just CTRL+F "adam".

This is option is pretty nice, but there is some problems in my opinion:

You will have only one single clear text password being sent to all devices through internet. I know we can use TLS to improve security, but it is not 100% safe.
It is not applicable for generic SIP clients, because for them, you cannot send this informatin through provisioning
You cannot use AD authentication for most generic SIP clients, because of the lack of NTLM support

The only situation where I would use this method is when having an environment with: Only Jabber clients; VCSc integrated to AD for authentication; VCSe cannot be integrated to AD because the customer does not allow (I agree!). Otherwise, I would not use AD for authentication, only for importing, and I would replicate provisioning database to VCSe just for device authentication, keeping the provisioning process towards VCSc, and I would set generic SIP clients and Jabber to register to VCSe with authentication. I would also implement CPL in VCSe to improve security.

This is just my opinion. I am not saying it is the best option or the only one, it is only my thoughts.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Chris Swinney · ‎08-01-2013

Yeah, thanks Zac. As Paulo points out, the main drawback to the solution (for us as least), is that we do not and cannot provide AD integration at any point in the VCS deployment.

My 'new' post is actually half way up this page, but due to the threaded view on these forums it is dificult to spot. It was in response to Paulos "correct answer" and was aimed back at Paulo (but of course, anyone else feel free to chip in). For your refernce - CTRL + F "Jul 31, 2013 7:49 PM" and you should find.

Adnan Kolakovic · ‎09-16-2013

Hi Chris,

I have the same issue as per your original post. I read through all of the responses, and it seems that there was no solution to the original problem, but rather changing the solution and how the provisioning works.

Does anyone have a solution for the original problem? Where the Jabber is registered to the VCS-C (proxied registration from VCS-E), and unable to call external clients (other companies)?

Thanks

Addy

Ishan Sambhi · ‎09-29-2013

Hi Team ,

I have opened a bug for this issue .

The bug number is CSCuj50093 .

This will be resolved in x8.1 .

Regards,

Ishan

Issue with external proxy registered Jabber client making external calls