Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Issue with external proxy registered Jabber client making external calls

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:

proxied+registration+VCSe.png

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.

Jabber Call Flow 1.jpg

Jabber Call Flow 2.jpg

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

48EnabledLocal Zone - no domainAnyAnyNoAlias pattern matchRegex(.+)@mydom.com.*ReplaceContinueLocalZone View/Edit
50DisabledLocalZoneMatchAnyAnyNoAny alias


ContinueLocalZone View/Edit
50EnabledLocal zone – full URIAnyAnyNoAlias pattern matchRegex(.+)@mydom.com.*LeaveContinueLocalZone View/Edit
400EnabledExternal IP address search ruleAnyAnyNoAny IP address


ContinueTest Zone View/Edit
800EnabledExpressway Query- E.164 and URIAnyAnyNoAny alias


ContinueTest 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

Everyone's tags (4)
2 ACCEPTED SOLUTIONS

Accepted Solutions

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

If I add a  provisioning licence to the VCS-E as well as the VCS-C, then the  relevant users from the specific group will also be added to the VCS-E,  thus adding many user accounts to the VCS-E - whilst I don't mind adding  one additional account to the VCS-E, adding many seems like I could be  asking for trouble!

Well, if you replicate users database from TMS to VCSe by enabling provisioning, you will only have to create accounts in TMS, we don't have to create accounts directly in VCSe. As of VCS 7, the provisioning database received is consider as local database of VCS.

Suite Provisioning Extension - Deployment Guide", where it states:

User accounts can only reside on one Cisco VCS (or Cisco VCS cluster). Therefore if your network has a combination of Cisco VCS Expressways and Cisco VCS Controls (where some endpoints - such as soft clients - may register to either the Control or the Expressway), we recommend that you configure and enable provisioning only on the Cisco VCS Control (or Control cluster). If a soft client or other endpoint registers to a Cisco VCS Expressway, provisioning requests will be routed (using search rules) to the Cisco VCS Control associated with the Expressway via the appropriate traversal zone.

I am really aware about this statement. But I don't enable provisioning replication in VCSe in order to have VCSe provisioning the clients, I enable it just to import users from TMS to use for device authentication. All the provisioning messages are still forwarded to VCS Control as the guide suggests.

How do I do this? That's simple, I enable provisioning replication in VCSe but I remove all the SIP routes (not search rules) used to forward provisioning messages to the local provisioning server in VCSe, then all the provisioning messages are sent to VCS Control as though VCSe had no provisioning feature. Therefore, the provisioning is made by VCS Control. VCSe has provisioning replication only to import users for authentication.

As VCSe has a local database imported from TMS, I am able to registere all external endpoints (jabber, generic SIP clients and etc) to VCSe with authentication enable.

Maybe you will say, "it is not recomended to have users database stored in a server that is accessible via internet". Well, if you create the users manually in VCSe, is it not the same if importing from TMS? What I think is really not recommended is to import users from LDAP to your VCSe, this deployment, I never use! Therefore, if you are not using LDAP (your case), the provisioning password has nothing to do with LDAP password, maybe even your "usernames" has nothing to do with LDAP, so, importing users from TMS to VCSe is not a security issue for most customers.

For me, security issue is to use one single SIP credential to authenticate all the jabber clients, mainly because this credential is sent through internet within a clear text SIP NOTIFY message.

So, what I REALLY  want to achieve is for the end user to be able to use their own password  and user name to be able to log on both locally and remotely. With a  provisioned client this is no problem - without, I run into issues. To  achieve what I want , I would need to either :

  1. Add provisioning to the Expressway,
  2. OR allow for proxying and develop some CPL

Correct?

In my opinion, the best option is 1:

  • Import users from TMS to VCSe by enabling provisioning, but only for device authentication (leave the provisioing job with VCS Control)
  • Create registration allow list in VCSe to improve security
  • In VCSe, use CPL and/or search rules  to disable external users to use your VCSe as a public SIP Server (the field "request must be authenticated" in search rule configuration is a nice option).

I won't suggest to use proxied registration, I don't like it. The license counting issue is "stupid" for me.

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".

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

The only thing you need to do is to remove ALL the SIP routes in VCSe, so that VCSe will route all the provisioning messages towards VCSc as though it had no provisionin feature enable.

Use the following commands in VCSe:

To show the current SIP routes, use the command:

xconfiguration SIP route

To delete SIP routes, use the command:

xCommand SIPRouteDelete

After deleting the SIP routes, you should have the provisioning messages being forwarded to VCS Control.

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".
31 REPLIES

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

Do you have SIP Poison mode enable in the traversal zone's configuration? Do you have interworking enable?

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".

Issue with external proxy registered Jabber client making extern

Hi Paulo,

SIP Poison -      NO on both VCS-E and VCS-C

Interworking -      "Registered only" on both VCS-E and VCS-E, however I have tried switch this off and on is different orders on both with no effect.

In fact, just double check the Interworking with all option and indeed this make no difference.

Re: Issue with external proxy registered Jabber client making ex

Ok Cris.

Let me perform some tests, I will use X-Lite and Jabber with proxied registration, just to see If I can have it working. I only tested this scenario with external jabbers calling each other through 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".

Re: Issue with external proxy registered Jabber client making ex

Hey Cris,

I simulated your problem by using a proxied registration scenario just like you have (but without VCS cluster). I used Jabber client and X-Lite client from internet registered to VCSc through proxied registration in VCSe. My test was sucessfull, I was able to make calls from Jabber to X-lite and vice versa.

After analysing the network logs and search history, this is what I have found:

  1. Both clients register to VCS control normally via proxied registration
  2. When jabber calls X-lite, the call is first send to VCSe and it matches VCSe's dial plan. Then VCSe route de INVITE to VCSc
  3. VCSc receives the invite and matches it against its dial plan. Here is the important point, VCSc does not match the call to a search rule towards traverzal zone, instead, VCS route the call by using a search rule towards its LocalZone (this is the right behavior, because endpoints are registered to VCSc).
  4. VCSc does not show any search history forwarding the invite back to VCSe, therefore only one search appears in search history and the target is localzone with the result "Found"
  5. Although VCSc does not show a search attempt toward VCSe, VCSc does sends a invite back to VCSe (without matching any rule). In VCSe I do see that invite being receive again, but VCSe does not match it againt its dial plan, because VCSe recognizes the destination as proxied registered device

See the result of the call below. As I stated many time, there are two calls being showed in VCSe, because the call comes from VCSe, goes to VCSc and comes back to VCSe. So VCSe considers as being two different calls although there is only a single one.

VCS Control

VCS Expressway

Therefore, I think your scenario is not working because you don't have correct search rules in VCSc towards LocalZone. You just have correct search rules towards Traversal Zone.

Try to adjust your dial plan based upon the description I posted above.

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".

Issue with external proxy registered Jabber client making extern

Hi Paulo,

I'm not sure, but I think you might have got hold of the wrong end of the stick. I think what you have demonstrated here is a External proxied client calling another external proxied client (albiet with one of those use a non Jabber client). I understand about the double call issue and this is not a problem, and NOT the probelm we are seeing. I can call other externally registered client OK.

What I meant by the third party device is something completely independent of the VCS system - i.e. registered elsewhere out in Internet land - a completely different domain not hosted on the VCSs in question (maybe I should have called it independent rather than third party). For this to happen, the call MUST egress through the VCS-E DNS Zone.

So the Internally registered device call call the independent third party - the call routes out from the VCS-C to the VCS-E, then out through the DNS Zone. However, with the externally registered device, the search stops at the VCS-C.

The only two ways I have been able to achieve this is to have a 2nd traversal zone between VCS-E and VCS-C (as mentioned above), OR open up the DNS Zone on the VCS-E to be able to route calls from its default zone (as mentiioned in the original post - so in this case, the externally registered client bypasses sending the call via the VCS-C - but this also open up the VCS-E for malicious routing of calls - or so I believe).

Does this make more sense?

Issue with external proxy registered Jabber client making extern

Hi Chris!

First of all, thank you for the very great documented question. Your diagrams are nice made!

As the question can not be rated I gave you +5 on an other posting for that!

Some thoughts, what I bet what kills your call here is the loop detection found under

VCS Config > Calls

That is most likely on on the VCS-E (default). If you want a loop call you would need to disable it there.

Maybe there are some findme scenaios where it would need to be disabled on the VCS-C as well.

Depending on the deployment disabling loop protection can cause, yes you guessed right, loops :-)

If its just the VCS-C and -E and you have the search rules right (I would for example check that

the VCS-E does not search on your own domains towards the dns zone) it should be ok.

Anyhow, I like to keep it on and use other methods.

How do your search rules on the VCS-E look like?

If you dont mind having the risk of somebody using your vcs as a open proxy (you could also limit this

to the domains by a custom CPL) you could add a search rule allowing from zone ANY.

Then the call will not hit the VCS-C and just be handled on the VCS-E.

Paulo mentioned that in postings before, I also do not really like the proxy registration neither.

Maybe looking into using authentication on the VCS-E and keep the registrations there could be

worth investigating.

Please remember to rate helpful responses and identify

Re: Issue with external proxy registered Jabber client making ex

Hi Martin,

Martin Koch wrote:

Hi Chris!

First of all, thank you for the very great documented question. Your diagrams are nice made!

As the question can not be rated I gave you +5 on an other posting for that!

Well, many thanks . Even so I have updated the diagrams (and search history to match) to show the distinction between domains - even when you think you have completely covered everything it is still possible for people to misinterpret your requests - sorry for leading you astray Paulo.

Martin Koch wrote:

Some thoughts, what I bet what kills your call here is the loop detection found under

VCS Config > Calls

Will look at this tomorrow, however, I think I already have! I think I have played with most settings in many differnt configurations, but will certianly double check this.

Martin Koch wrote:

How do your search rules on the VCS-E look like?

48EnabledLocal Zone - no domainAnyAnyNoAlias pattern matchRegex(.+)@mydom.com.*
50EnabledLocal Zone - full URIAnyAnyNoAlias pattern matchRegex(.+)@mydom.com.*
100EnabledTraversal zone search ruleAnyAnyNoAny alias

700EnabledGDS Query - E.164 MatchAnyAnyNoAlias pattern matchPrefix0
800EnabledDNS Search - URI MatchAnyAllZonesNoAlias pattern matchRegex(?!.*@mydom.com$).*

ReplaceContinueLocalZone View/Edit
LeaveContinueLocalZone View/Edit

ContinueTest Zone View/Edit
LeaveContinueNational GK's View/Edit
LeaveContinueDNS Zone View/Edit

Martin Koch wrote:

If you dont mind having the risk of somebody using your vcs as a open proxy (you could also limit this

to the domains by a custom CPL) you could add a search rule allowing from zone ANY.

Then the call will not hit the VCS-C and just be handled on the VCS-E.

Yeah - sounds like a plan - I need to look into this

Martin Koch wrote:

Paulo mentioned that in postings before, I also do not really like the proxy registration neither.

Maybe looking into using authentication on the VCS-E and keep the registrations there could be

worth investigating.

TBH, our current production enviroment uses registration on the VCS-E (as per https://supportforums.cisco.com/message/3942778#3942778, although Adam talks about AD, the same can be achieved with just TMSPE and local DBs), and I quite like this. However, as we support many educations establishement, we need to be able to support third party SIP clients (such as Linphone), and I simply can't seem to find a third party client that can support this 'double' authentication. Hence the reason for looking at proxying registrations.

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

TBH, our current production enviroment uses registration on the VCS-E (as per https://supportforums.cisco.com/message/3942778#3942778, although Adam talks about AD, the same can be achieved with just TMSPE and local DBs), and I quite like this. However, as we support many educations establishement, we need to be able to support third party SIP clients (such as Linphone), and I simply can't seem to find a third party client that can support this 'double' authentication. Hence the reason for looking at proxying registrations.

I may be missing something here, but as far as I understand, when you attempt to register generic SIP client to VCSe, the authentication will be made on VCSe or on VCSc (if using proxied registration), but it is not double authentication. The double authentication process happens with Jabber, because with Jabber, you first authenticate when provisioning the client and then authenticate again to register the client.

I don't think you will have problems in registering generic SIP clients to VCSe directly. I have a customer that uses X-Lite from internet registered to VCSe with authentication enable. They also have internal and external jabber clients working fine. They use TMS directory as authentication database in both VCSc and VCSe, so all the clients register from internet by using the same users database for authentication. Of course, there is no LDAP authentication, only LDAP importing in TMS. They also have some CPL rules to bring security.

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".

Re: Issue with external proxy registered Jabber client making ex

Hi Paulo,

Again many thanks for the response and further  apologies for my lack of clarity (very tired at that point). Indeed, the  the 'double' authentication I was referencing was with regard to the  Jabber provisioning request, then the SIP registration.

At this moment in time, I have held off from adding the Provisioning licence to the VCS-E simply because this is recommended as something NOT to do in the documentation "Cisco TelePresenceManagement Suite Provisioning Extension - Deployment Guide", where it states:

User accounts can only reside on one Cisco VCS (or Cisco VCS cluster). Therefore if your network has a combination of Cisco VCS Expressways and Cisco VCS Controls (where some endpoints - such as soft clients - may register to either the Control or the Expressway), we recommend that you configure and enable provisioning only on the Cisco VCS Control (or Control cluster). If a soft client or other endpoint registers to a Cisco VCS Expressway, provisioning requests will be routed (using search rules) to the Cisco VCS Control associated with the Expressway via the appropriate traversal zone.

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. Things aren't  too bad from my point of view either as I only have to add one  additional generic user account to the VCS-E  that I can supply a complex password for. However, in this scenario I  need to give out the Generic SIP Authentication username and password to  users that want to connect remotely an that don't use Jabber -  something I would rather avoid.

If I add a  provisioning licence to the VCS-E as well as the VCS-C, then the  relevant users from the specific group will also be added to the VCS-E,  thus adding many user accounts to the VCS-E - whilst I don't mind adding  one additional account to the VCS-E, adding many seems like I could be  asking for trouble!

So, what I REALLY  want to achieve is for the end user to be able to use their own password  and user name to be able to log on both locally and remotely. With a  provisioned client this is no problem - without, I run into issues. To  achieve what I want , I would need to either :

  1. Add provisioning to the Expressway,
  2. OR allow for proxying and open up the DNS Zone to route from the VCS-E (but with Authentication) and develop some CPL

Correct?

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

If I add a  provisioning licence to the VCS-E as well as the VCS-C, then the  relevant users from the specific group will also be added to the VCS-E,  thus adding many user accounts to the VCS-E - whilst I don't mind adding  one additional account to the VCS-E, adding many seems like I could be  asking for trouble!

Well, if you replicate users database from TMS to VCSe by enabling provisioning, you will only have to create accounts in TMS, we don't have to create accounts directly in VCSe. As of VCS 7, the provisioning database received is consider as local database of VCS.

Suite Provisioning Extension - Deployment Guide", where it states:

User accounts can only reside on one Cisco VCS (or Cisco VCS cluster). Therefore if your network has a combination of Cisco VCS Expressways and Cisco VCS Controls (where some endpoints - such as soft clients - may register to either the Control or the Expressway), we recommend that you configure and enable provisioning only on the Cisco VCS Control (or Control cluster). If a soft client or other endpoint registers to a Cisco VCS Expressway, provisioning requests will be routed (using search rules) to the Cisco VCS Control associated with the Expressway via the appropriate traversal zone.

I am really aware about this statement. But I don't enable provisioning replication in VCSe in order to have VCSe provisioning the clients, I enable it just to import users from TMS to use for device authentication. All the provisioning messages are still forwarded to VCS Control as the guide suggests.

How do I do this? That's simple, I enable provisioning replication in VCSe but I remove all the SIP routes (not search rules) used to forward provisioning messages to the local provisioning server in VCSe, then all the provisioning messages are sent to VCS Control as though VCSe had no provisioning feature. Therefore, the provisioning is made by VCS Control. VCSe has provisioning replication only to import users for authentication.

As VCSe has a local database imported from TMS, I am able to registere all external endpoints (jabber, generic SIP clients and etc) to VCSe with authentication enable.

Maybe you will say, "it is not recomended to have users database stored in a server that is accessible via internet". Well, if you create the users manually in VCSe, is it not the same if importing from TMS? What I think is really not recommended is to import users from LDAP to your VCSe, this deployment, I never use! Therefore, if you are not using LDAP (your case), the provisioning password has nothing to do with LDAP password, maybe even your "usernames" has nothing to do with LDAP, so, importing users from TMS to VCSe is not a security issue for most customers.

For me, security issue is to use one single SIP credential to authenticate all the jabber clients, mainly because this credential is sent through internet within a clear text SIP NOTIFY message.

So, what I REALLY  want to achieve is for the end user to be able to use their own password  and user name to be able to log on both locally and remotely. With a  provisioned client this is no problem - without, I run into issues. To  achieve what I want , I would need to either :

  1. Add provisioning to the Expressway,
  2. OR allow for proxying and develop some CPL

Correct?

In my opinion, the best option is 1:

  • Import users from TMS to VCSe by enabling provisioning, but only for device authentication (leave the provisioing job with VCS Control)
  • Create registration allow list in VCSe to improve security
  • In VCSe, use CPL and/or search rules  to disable external users to use your VCSe as a public SIP Server (the field "request must be authenticated" in search rule configuration is a nice option).

I won't suggest to use proxied registration, I don't like it. The license counting issue is "stupid" for me.

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".

Re: Issue with external proxy registered Jabber client making ex

Hi Paulo,

Sorry for coming back to this one (wasn't sure whether to post a new - but really its a follow up to this conversation), but I have only just got around to trying this on our test bed.

So I'm looking to explore the possibilities to use Provisioning on the VCS-E simply to provide a method to deploy user credentials in order that a user can register to the VCS-E, however, pass on the actual provisioning and presence information to the VCS-C in order that those duties can be carried out there and not actually on the VCS-E

As a Basic setup, I have completed the following:

  1. Turn off "SIP registration proxy mode" on the VCS-E
  2. Add the SIP domain to the VCS-E to allow registration
  3. Install the provisioning licence and set up the TMSPE to only replicate 'User' information.
  4. Set up the Default Zone and Subzones to "Check Credentials" (am I correct in thinking this is OK as it will still allow inbound calls but stop unauthenticated provisioning (SUBSCRIBE) requests?)

At this point I can see the user authenticate, but (from the Network Log - see below) of course the provisioning request is directed to the VCS-E then on to the 127.0.0.1 loop back address). Assume that in this example the client is at a fictitious address of 2.2.2.2 and the VCS-E is a 1.1.1.1.

Of course this is where the "xConfig SIP Routes" setup you mention above now comes into play. So, I have read through the VCS Admin guide but it is a little vague about this subject - apart from the command being listed (although it does say that is "for developer use only"), I couldn't find much info. Do I have to add a single route for each message type I want to forward, and do I need ALL the SIP Route config for each rule?

For instance, I can see this is the Network Log (names have been changed to protect the innocent)

2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,232" Module="network.sip" Level="DEBUG": Src-ip="127.0.0.1" Src-port="22410"

SIPMSG:

|SIP/2.0 503 License Count Exceeded

Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK7e73b84872e7059996e3845160f036fe44334.87d275781ab55f2a9b1a69d6cbb3d624;received=127.0.0.1;rport=5060;egress-zone=DefaultZone;proxy-call-id=f2f4477a-fa09-11e2-95a0-0010f31ae17c

Via: SIP/2.0/TLS 2.2.2.2:51896;branch=z9hG4bKa15082332de22bc11234fadd846b90b6.1;received=2.2.2.2;rport=51896;ingress-zone=DefaultZone

Call-ID: 909cc78999684bdb@127.0.0.1

CSeq: 202 SUBSCRIBE

Contact: "VCS Provisioning Service" <127.0.0.1:22410>

From: <>user@mydom.com>;tag=fd99431e6f439c14

To: <>provisioning@mydom.com>;tag=9329846bf91f3428

Record-Route: <127.0.0.1:5060>

Record-Route: <1.1.1.1:5061>

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1405356030-1745526636-438344022";connectivity=1

Content-Length: 0

|


2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,232" Module="network.sip" Level="INFO": Src-ip="127.0.0.1" Src-port="22410" Detail="Receive Response Code=503, Method=SUBSCRIBE, To=sip:provisioning@mydom.com, Call-ID=909cc78999684bdb@127.0.0.1"


2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,230" Module="network.sip" Level="DEBUG": Dst-ip="127.0.0.1" Dst-port="22410"

SIPMSG:

|SUBSCRIBE sip:user@mydom.com SIP/2.0

Via: SIP/2.0/UDP 127.0.0.1:5060;egress-zone=DefaultZone;branch=z9hG4bK7e73b84872e7059996e3845160f036fe44334.87d275781ab55f2a9b1a69d6cbb3d624;proxy-call-id=f2f4477a-fa09-11e2-95a0-0010f31ae17c;rport

Via: SIP/2.0/TLS 2.2.2.2:51896;branch=z9hG4bKa15082332de22bc11234fadd846b90b6.1;received=2.2.2.2;rport=51896;ingress-zone=DefaultZone

Call-ID: 909cc78999684bdb@127.0.0.1

CSeq: 202 SUBSCRIBE

Contact:

From: <>user@mydom.com>;tag=fd99431e6f439c14

To: <>provisioning@mydom.com>

Max-Forwards: 69

Record-Route: <127.0.0.1:5060>

Record-Route: <1.1.1.1:5061>

User-Agent: TANDBERG/774 (MCX 4.6.3.17194) - Windows

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1405356030-1745526636-438344022";connectivity=1

Accept: application/pidf+xml

P-Asserted-Identity: <>user@mydom.com>

X-TAATag: f2f44932-fa09-11e2-bfaa-0010f31ae17c

Content-Length: 0

|


2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,230" Module="network.sip" Level="INFO": Dst-ip="127.0.0.1" Dst-port="22410" Detail="Sending Request Method=SUBSCRIBE, Request-URI=sip:user@mydom.com, Call-ID=909cc78999684bdb@127.0.0.1"


2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,227" Module="network.ldap" Level="INFO": Detail="Authentication credential found in directory for identity: user"

2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,224" Module="network.sip" Level="DEBUG": Src-ip="2.2.2.2" Src-port="51896"

SIPMSG:

|SUBSCRIBE sip:user@mydom.com SIP/2.0

Via: SIP/2.0/TLS 2.2.2.2:51896;branch=z9hG4bKa15082332de22bc11234fadd846b90b6.1;received=2.2.2.2;rport=51896

Call-ID: 909cc78999684bdb@127.0.0.1

CSeq: 202 SUBSCRIBE

Contact:

From: <>user@mydom.com>;tag=fd99431e6f439c14

To: <>provisioning@mydom.com>

Max-Forwards: 70

Route: <1.1.1.1:5061>

User-Agent: TANDBERG/774 (MCX 4.6.3.17194) - Windows

Expires: 300

Proxy-Authorization: Digest nonce="a824ed85c7b23a312439e6f9f6ae5a58f43098cd3f067fba8af094f83b8e", realm="vcs-e.mydom.com", qop=auth, opaque="AQAAANm9RZ5qOXTlkQuvg38NKgzL/cyP", username="user", uri="sip:mydom.com", response="4df9824190d8ee42f9cb93b3fdd9e5fe", algorithm=MD5, nc=00000001, cnonce="d5ad1f6e10962fe2ad18e118543dd476"

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1405356030-1745526636-438344022";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

|

2013-07-31T18:52:21+01:00    tvcs: UTCTime="2013-07-31 17:52:21,224" Module="network.sip" Level="INFO": Src-ip="2.2.2.2" Src-port="51896" Detail="Receive Request Method=SUBSCRIBE, Request-URI=sip:user@mydom.com, Call-ID=909cc78999684bdb@127.0.0.1"

I'm this the SIP Routes will need to take affect of the redirected SIP messages as seen above (in Purple) from the VCS-E to its loopback address, so I guessing I will need something like this:

xConfiguration SIP Routes Route 1 Address: "vcs-c.mydom.com"                                            (can I spefify FQDN?)

xConfiguration SIP Routes Route 1 Authenticated: On

xConfiguration SIP Routes Route 1 Header Name: "Event"                                                      (not sure about this)

xConfiguration SIP Routes Route 1 Header Pattern: "(ua-profile;model=movi)(.*)"                   (really not sure about this!)

xConfiguration SIP Routes Route 1 Method: "SUBSCRIBE"

xConfiguration SIP Routes Route 1 Port: 5060                                                                          (Maybe 5061 with TLS?)

xConfiguration SIP Routes Route 1 Request Line Pattern: ".*@(%localdomains%|%ip%)"     (Hmmm)

xConfiguration SIP Routes Route 1 Tag: "Tag1"                                                                        (really not sure about this!)

xConfiguration SIP Routes Route 1 Transport: TLS                                                                  (These VCS-Es will be on the public Internet)

I haven't tried any of this yet, but I will have to wait until tomorrow now.

Cheers

Chris

Re: Issue with external proxy registered Jabber client making ex

Hi Cris,

The only thing you need to do is to remove ALL the SIP routes in VCSe, so that VCSe will route all the provisioning messages towards VCSc as though it had no provisionin feature enable.

Use the following commands in VCSe:

To show the current SIP routes, use the command:

xconfiguration SIP route

To delete SIP routes, use the command:

xCommand SIPRouteDelete

After deleting the SIP routes, you should have the provisioning messages being forwarded to VCS Control.

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".

Re: Issue with external proxy registered Jabber client making ex

Oh! That's a bit easy! I had expected a lot more work and so studied the SIP packets from the Network Log to try and determine the correct format. Still, I'm sure this time spent will come in handy at some point in the future.....

I'll have a look at the current SIP route to see how they are constructed and see it I can determine how they work, but I now guess that they actually point to the loopback (127.0.0.1).

Re: Issue with external proxy registered Jabber client making ex

Yes, these SIP routes are used to route provisioning messages to the local provisioning server, that's why you see 127.0.0.1 as destination. By removing the SIP routes, the provioining message will be sent towards VCSc using search rules.

Good luck!

=)

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".

Re: Issue with external proxy registered Jabber client making ex

Sorted -Lovely. Thank you. 5 *

Now for some funky CPL....

Re: Issue with external proxy registered Jabber client making ex

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".

Issue with external proxy registered Jabber client making extern

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.

Re: Issue with external proxy registered Jabber client making ex

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".

Re: Issue with external proxy registered Jabber client making ex

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.

Re: Issue with external proxy registered Jabber client making ex

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".

Re: Issue with external proxy registered Jabber client making ex

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

Re: Issue with external proxy registered Jabber client making ex

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".
New Member

Re: Issue with external proxy registered Jabber client making ex

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??

Re: Issue with external proxy registered Jabber client making ex

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".
Cisco Employee

Re: Issue with external proxy registered Jabber client making ex

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.

Re: Issue with external proxy registered Jabber client making ex

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".

Re: Issue with external proxy registered Jabber client making ex

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.

New Member

Issue with external proxy registered Jabber client making extern

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

Cisco Employee

Issue with external proxy registered Jabber client making extern

Hi Team ,

I have opened a bug for this issue .

The bug number is CSCuj50093 .

This will be resolved in x8.1 .

Regards,

Ishan

2987
Views
25
Helpful
31
Replies
CreatePlease to create content