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
