Issue with external proxy registered Jabber client making external calls

[Chris Swinney]

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

Any

No

Alias pattern match

Regex

(.+)@mydom.com.*

Replace

Continue

LocalZone

View/Edit

50

Disabled

LocalZoneMatch

Any

Any

No

Any alias

Continue

LocalZone

View/Edit

50

Enabled

Local zone – full URI

Any

Any

No

Alias pattern match

Regex

(.+)@mydom.com.*

Leave

Continue

LocalZone

View/Edit

400

Enabled

External IP address search rule

Any

Any

No

Any IP address

Continue

Test Zone

View/Edit

800

Enabled

Expressway Query- E.164 and URI

Any

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

[Paulo Souza]

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.

[Chris Swinney]

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.

[Paulo Souza]

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]

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.

[Chris Swinney]

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?

[Martin Koch]

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.

[Chris Swinney]

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?

48	Enabled	Local Zone - no domain	Any	Any	No	Alias pattern match	Regex	(.+)@mydom.com.*
50	Enabled	Local Zone - full URI	Any	Any	No	Alias pattern match	Regex	(.+)@mydom.com.*
100	Enabled	Traversal zone search rule	Any	Any	No	Any alias
700	Enabled	GDS Query - E.164 Match	Any	Any	No	Alias pattern match	Prefix	0
800	Enabled	DNS Search - URI Match	Any	AllZones	No	Alias pattern match	Regex	(?!.*@mydom.com$).*

Replace	Continue	LocalZone	View/Edit
Leave	Continue	LocalZone	View/Edit
	Continue	Test Zone	View/Edit
Leave	Continue	National GK's	View/Edit
Leave	Continue	DNS 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.

[Paulo Souza]

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.

[Chris Swinney]

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?

[Paulo Souza · Accepted solution]

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 :
Add provisioning to the Expressway, 
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.

[Chris Swinney]

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

[Paulo Souza · Accepted solution]

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.

[Chris Swinney]

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

[Paulo Souza]

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.