07-03-2013 11:04 AM - edited 03-18-2019 01:24 AM
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
Solved! Go to Solution.
10-02-2013 09:47 AM
Hi Adnan,
We worked round the issue. We no longer Proxy the registration, but register the user directly to VCS-E.
We actually have enabled Provisioning on the VCS-E to allow TMS to push user to the device although actual provisioning takes place on the VCS-C. You have to run some command line rule to delete some SIP routes on the VCS-E that are put in place through the act of adding the Provisioning Licence, and as such and can bet the bank that this is NOT a Cisco recommended practice (.... but works great for us is out situation).
However, we still have issue with external users placing calls, but this is more to do with where that external user maybe located - i.e. are they inside another institution behind another cooperate firewall. Essentially, whilst the Jabber user may be able to register to the VCS-E, if they place a call they will NOT receive any media as UDP packets from the VCS-E are blocked at the other institutions firewall. This could be resolved if Jabber where able to utilise the firewall traversal system built into the VCS-E - essentially creating an outbound connection from Jabber to the VCS-E to then enable return media via this established link, but it doesn't.
I did post about this as well (https://supportforums.cisco.com/thread/2235817, although this post starts out about a question with reagrd to another issue), and have asked for a feature request to be submitted by out Cisco Partner - which I hope they have done. Ishan - I would love to see this resoved in x8.1!!!
10-02-2013 11:42 AM
Chris Swinney wrote:
Ishan - I would love to see this resoved in x8.1!!!
ALthough I would just love to see x8 first ................
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide