Jabber Provisioning over VCSE

[Paul Woelfel]

Hi,

how does the VCS Control decide to send the Public or the internal settings.

I'm having an issue at one installation, where the VCS Control always sends the ProvData xml with the internal settings, even if the Subscribe message is proxied from the VCS Expressway.

We're running X7.2.1 and TMS 13.2.2 with TMSPE.

Best Regards,
Paul

[Tomonori Taniguchi]

Are you configure “Public SIP Server Address”, “Public Presence Server URI”, and “Public Phone Book Server URI” in provisioning template?

The “Public SIP Server Address” should point to your VCS-E by either using IP address, SRV, or A/AAAA host name.

VCS-C will not control or filter notify message sending back to client so what you have configure as provisioning template should send to Jabber Video via VCS-E.

[Paul Woelfel]

Hi Tomonori,

yes, we configured all the Public settings to point to the VCS-E. The client connects to the VCS-E to request the provisioning data, which will be forwarded to the VCS-C. The VCS-C answered with the internal settings (bandwidth, sip server aso.).

As far I found out, it considers if the source IP address matches a subzone membership rule (e.q. RFC 1918 address) and treats the endpoint on a match.

I'm interested how the internal process on the VCS-C decides, if the ProvData should contain the public or the internal settings.

BR, Paul

[awinter2 · Accepted solution]

Paul,

When Jabber Video attempts to get provisioning configuration, the provisioning VCS will pick the 'Public' values from the provisioning directory if the provisioning SUBSCRIBE was sent from the Jabber Video client using the address defined in the 'External VCS' address field on the Jabber Video client.

The provisioning SUBSCRIBE contains a SIP header called 'Event', and and the very end of this header, there is a parameter called 'Connectivity'. This parameter will be set to '1' if the SUBSCRIBE was sent using the 'External VCS' address, and set to '0' if sent using the 'Internal VCS' address, as in this example where it is set to '1':

SIPMSG:

|SUBSCRIBE sip:andreas@ciscotp.com SIP/2.0

Via: SIP/2.0/TLS 10.1.1.1:59784;branch=z9hG4bKe980a321dc3f55a2afa41d228f4182ca.1;received=10.1.1.1;rport=59784

Call-ID: a0670e09ec9407d0@127.0.0.1

CSeq: 201 SUBSCRIBE

Contact:

From: <>andreas@ciscotp.com>;tag=2383a23476b4d6fa

To: <>provisioning@ciscotp.com>

Max-Forwards: 70

Route: <10.1.1.2>

User-Agent: TANDBERG/771 (MCX 4.2.0.10318 (multistream))

Expires: 3600

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.2.0.10318;clientid="D919D74C-DCB5-4D63-BBC1-0FAD94B8820C";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

The provisioning VCS will hand out 'Public' values whenever 'connectivity' is set to 1.

Hope this helps,

Andreas

[Paul Woelfel]

I checked the connectivity and found that connectivity is set to 0:

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="D9766613-5C0F-4E01-877C-6D92195A9C3A";connectivity=0

I added the VCSC and VCSE servers to the config and connectivity was set to 1

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="D9766613-5C0F-4E01-877C-6D92195A9C3A";connectivity=1

We wanted to use just the SIP DNS Records to automatically select the correct VCS to send the Provisioning request to. We are using split DNS for the video domain. Internally the _sip._tcp and _sips._tcp point to VCS Control and the public entries point to VCSE.

Is there a way to not enter the internal and external Servers and use DNS to resolve the VCS server to send the Provisioning request to?

[awinter2 · Accepted solution]

Paul,

as far as Jabber Video and Movi go, there is no way for these clients to know if they are located on the outside/public side or on the internal side of the enterprise network without using the 'Internal VCS'/'External VCS' values.

The E20 provisioning is different in that it uses DNS NAPTR to determine this, but this method is quite cumbersome in my personal opinion.

With your split DNS setup, the way to go is to populate 'Internal VCS' with the DNS name for your VCS-C and 'External VCS' with the DNS name for your VCS-E, and then make sure that the 'Internal VCS' DNS name is only resolveable from the inside. This should ensure that the provisioning SUBSCRIBE goes to your VCS-C (With connectivity=0) whenever located on the internal network, and to your VCS-E (With connectivity=1) whenever located on a public network.

The only pitfall here is when using a public hotspot of some sort which sink all DNS requests and redirect all traffic to some sort of captive portal, but this should not pose a problem once you have logged in with the hotspot and DNS is working properly.

[Paul Woelfel]

Thanks Andreas, that clarifys it!

We will use registry keys to set internal and external servers for all users.

Thanks!

[Martin Koch]

I do not see a big issue to have proper DNS records present, if its NAPTR (which I think would be great anyhow

to be properly supported by vcs).

So if the client really needs to know first where he is it can be done via DNS as well, I think its more cumbersome

to anyhow have the NAPTR record for the e20 in place and not to being able to use it for Jabber Video.

And the latest JabberTablet version also has a "enter your email address" I find the right server and connection

type just by quering the DNS. This is how I like it.

You find a posting here:

https://supportforums.cisco.com/message/3817226#3817226

sadly no answer yet.

Besides that the VCS could also tag the inoming packet with where it was received and the

probisioning server could do action on that tag.

Its just a option for the zone away how to map this for jabbervideo. I could even picture an

auto function if you have subzones with link and pipes to define a max bandwidth or have more then

"internal+external", ...