Provisioning settings on VCS Expressway

[tufan.kabacioglu]

Hello,

I have installed a demo environment with TMS, VCS Control, VCS Expressway and MCU. I have no problem in local side. I can login with my Jabber and call local endpoints. But first of all, I can not find enough information about what to do on the Expressway side about provisioning. When I try to login with my Jabber to VcsE on the internet, it forwards me to VcsC ip address (I have no idea how it do that), so i can not login because the ip address of the VcsC is local. What should I do to make the endpoints provision from the VcsE?

I have another problem. I have completed traversal zone configs and i see the vcsc connected to the vcse without any problem. I can start a video conf call to the internet and these type of calls are connected. But there is no video and audio. When I check the call status I see that video and audio rate are 0 bps. What do you think is the problem?

Best regards,

Tufan   

[gubadman]

For the first issue in TMS make sure you have both the following datafilled:

Public SIP Server Address:     VCSe.MyDomain

SIP Server Address:     VCSc.MyDomain

For the Movi/Jabber configuration profile

The second issue sounds like a firewall problem between the control and expressway

Thanks,

Guy

[Tomonori Taniguchi]

Assume you have configured "SIP Server Address" in Provisioning Temprate which pointing to your VCS-C address.

Deploying VCS-E (but not proxy registration), you will also need to configure "Public SIP Server Address" in Provisioning Temprate which should pointing to your VCS-E public IP address.

VCS-E DefaultSubZone and DefaultZone should configure as "Do not check credentials" as Authentication poicy (so VCS-E won't try to authenticate the provisioning request but forward it to VCS-C).

You also need to configure SIP domain on VCS-E (sip domain that use for provisioing).

Then when Movi client attempt register on VCS-E (should have VCS-E address in "External Server" feilds on your Movi sign-in settings), provisioning request forward to VCS-C and handle the negotiation.

Movi client will receive provisioning temprate with VCS-E address (address configure in "Public SIP Server Address") which Movi client will try to register.

[Tomonori Taniguchi]

The second issue, as Guy already reply highly suspect there is firewall that block signal or/and media payload.

If you see one way audio/video, possibly ACK message for SIP Invite (initial call initiate message) has block/deny by firewall.

If you have no audio/video on both direction, possible firewall doesn't allow UDP payload between VCS-C and VCS-E.

I'd recommend to take diagnostic log from VCS-E and VCS-C for further investigation (and contact TAC for further assistant).

[tufan.kabacioglu]

Thanks. First issue has been solved. But i am having the second problem. Actually I registered from the internet and called an internet endpoint. So media don't see VCS-C. Therefore I don't suspect the FW between VCSs. There is something I realized in call status in the VCS-E. It is shown as "False" next to "Media routed" as you can see below.

Best regards,

Tufan

[Alok Jaiswal]

Hi Tufan,

How is the internet endpoint registered to vcs expressway? is it a H.323 or SIP.

Media not routed means expressway seems it as a non-traversal call. But commenting further we need to see how the endpoint is registered and what protocol.

Thanks

Alok

[awinter2]

Hi Tufan,

you will typically see this behavior if you register a SIP device to the VCS-E and the SIP device is not behind a NAT.

In those cases, when placing a call from this SIP device to another device which is available publicly, the VCS-E will usually not take media for the locally registered SIP device. This will pose a problem if the locally registered SIP device is behind a firewall and/or if this locally registered SIP device is registering from a private IP address.

A workaround for this issue could be to place the locally registered SIP device behind a NAT. When the VCS-E sees that the SIP device is NAT'ed, the VCS-E will take media for calls to or from this endpoint.

Hopefully, this problem should be less of an issue with the upcoming X7.2 software for the VCS. In X7.2, we are planning to possibly include a feature which will force media for certain zones and subzones through the VCS regardless of the endpoint being behind NAT or not. It should be noted that although this and other features are planned for X7.2, there is no guarantee that they will all make it into the final release so you will just have to wait and see

- Andreas

[Tomonori Taniguchi]

Does your SIP UA (Endpoint) registered on VCS Expressway is behind firewall or have public IP address?

If above snapshot is from VCS Control, do you have DNS zone on VCS control which VCS Control may try to reach out SIP UA/Endpoint directly after resolved far end ip address.

If you have VCS-C – VCS-E deployment, DNS lookup for call to public network should take care by VCS-E not VCS-C.

[tufan.kabacioglu]

The endpoint is Jabber so it is registered as a SIP endpoint. My Jabber is behind a firewall. Above snapshot is from VCS-E.

[Kyle Williams]

Hi Tufan,

Just wanted to see if you were able to resolve the issue.  Currently we are running into a similar issue on our VCSe.  We have deployed a VCSe with a single internal DMZ address (Public IP address NAT'd to it, Dual-NIC option enabled).  Internal clients talk directly to the internal DMZ address and are able to register to the VCSe and place calls between each other.  The issue we are running into is public devices (from other VCSe's or Jabber) appear to be local on the VCSe so it's not "Media Routed' status stays at false.  From Andreas' note it sounds like there might be a way to force the media routed status in X7.2 but were you able to find a work around until the X7.2 release?

Kyle

[Tomonori Taniguchi]

For SIP call, VCS Expressway treat as traversal call for call between SIP UA and one or both of SIP UA’s sip contact address differs from source IP address.

In other words, one or both SIP UA accessing VCS-E is behind a NAT.

However VCS Expressway treat as non-traversal call for call between SIP UA and both SIP UA’s have same sip contact address and source IP address.

In other words, both SIP UAs accessing VCS-E are NOT behind a NAT (if VCS-E on public network, both SIP UAs has public IP address as well).

The non-traversal call, VCS Expressway will not stay in media route.

Tufan and Kyle, could you please clarify your SIP UAs IP address assignment (behind NAT or have public IP address assignment)?

> From Andreas' note it sounds like there might be a way to force the media routed status in X7.2

> but were you able to find a work around until the X7.2 release?

Cisco is planning to support media encryption policy service from X7.2 release which force VCS to take all signal and media regardless of above scenarios.

The media encryption policy allow administrator to control encryption setting on each call leg (force to encrypt, force to non-encrypt, auto negotiation, etc.).

If you are looking for media routed via VCS-E for all calls, this feature could be solution with current SIP UAs condition.

[Kyle Williams]

Hi Tomonori,

Thanks for the reply.  Our internal clients were privately addressed and going to the DMZ IP address of the VCSe.  After a TAC case we were told that we either had to A) use NAT hair-pinning and have clients register to the public IP address of VCSe or B) implement 2 NICs.

In the end we went with the 2 NIC solution where:

• Public IP address was NAT'd to a private DMZ address.  This outside interface was only used for inbound/outbound external calls.
• Internal IP address in a voice server network.  All endpoints registered to this internal interface.

The above solution allowed us to have all internal endpoints RTP traffic flow directly between the endpoints (Media not routed) and all external calling (jabber.com, etc.) to flow through the VCSe (media routed).

Kyle

[Ovindo Prastyo Utomo]

Hi Tufan,

Is this issue already solved?

Curently I have similiar issue with my jabber and VCS-E.

Please advise if this issue already solved.

Thanks,

Ovindo

[Paulo Souza]

Hi Ovindo,

As this thread was opened last year, I suggest you to open a new thread to discuss your issue.  =)

Regards

Paulo Souza

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