cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1498
Views
4
Helpful
8
Replies

Cisco Jabber Im b2b Calls

Hi everyone!

I´m deploying the following scenario:

Cucm --> exp-c --> exp-e

I have registered sx10 and cisco jabbers on Cucm and I have implemented mra and b2b on expressway solution. From sx10 I can dial to external domain, external ip address and everythings work fine.

Also, I uploaded jabber-config.xml for uri dialing from jabbers users but I have a problem: When I dial b2b calls from a jabber user, the call arrive to expressway-c but this uses the mra zone to expressway-e, then "Service Unavailable" error appear . I have already added the b2b zone and work well from sx10 endpoint but no from jabbers users.

 

Anyone can help me?

 

Regards!

 

1 Accepted Solution

Accepted Solutions

Something odd is going on here. It looks like Jabber is still trying to make this call as an MRA call.

Try adding a SIP Route Pattern (domain pattern) in CUCM for externaldomain.es and point it at your 5560 B2B SIP Trunk to Expressway. Then restart Jabber and try the call again. If it does not succeed please post the search history again.

View solution in original post

8 Replies 8

Sushant Sharma
Level 1
Level 1

Hi Dear,

check in search history why same call using different different zones to reach destination

i understood when you are dialing from sx 10 its working fine and going out from b2b zone

but in case of jabber dialing same destination but going out from MRA zone

 

same destination ( but using different  zone )

 

Please check both call search history u will get idea where you are missing exactly

shawnangelo
Level 1
Level 1

What version UCM are you running? Also please post jabber-config.xml, output of both calls search history on Exp-c and Exp-e.

Hi,

Thanks for your both replies.

The version are:

    - Cucm: 10.5.2.10000-5
    - EXP-C/E: X8.5.1

The jabber config:


<config version="1.0">
<Directory>
 <DirectoryServerType>UDS</DirectoryServerType>
</Directory>
<Policies>
 <Screen_Capture_Enabled>true</Screen_Capture_Enabled>
 <File_Transfer_Enabled>true</File_Transfer_Enabled>
 <EnableVideo>true</EnableVideo>
 <UserDefinedRemoteDestinations>true</UserDefinedRemoteDestinations>
 <EnableSIPURIDialling>true</EnableSIPURIDialling>
 <DirectoryURI>mail</DirectoryURI>
</Policies>
<Options>
 <AllowUserCustomTabs>true</AllowUserCustomTabs>
</Options>
</config>


Also, I saw, on the expressway-c that the originating zone of the fails call is Defaultzone (type default) but the originating zone of the good call is type Neighbor called: "cucm traversal b2b".

Fails call

Zone (1)
Name: DefaultZone
Type: Default

Good Call

Zone (1)
Name: Cucm Traversal B2B
Type: Neighbor

The jabbers, are registered from internet across the expressway-e.

Regards!

If you can copy and paste the full search history from each call that would reveal why the failed call is hitting the default zone.

Hi again!

 

Ok, i copy the search history:

 

Well call (from sx10 codec to external uri):

 

  • Search (315)
    • State: Completed
    • Found: True
    • Type: SIP (INVITE)
    • CallRouted: True
    • CallSerial Number: 568f229f-fc17-403a-834c-18a8c90b5a88
    • Tag: a0f74c73-9e3d-4a13-b30f-66ef03093b6f
    • Source (1)
      • Authenticated: False
      • Aliases (1)
        • Alias (1)
          • Type: Url
          • Origin: Unknown
          • Value: 2000@internaldomain.es
      • Zone (1)
        • Name: Cucm Traversal B2B
        • Type: Neighbor
      • Path (1)
        • Hop (1)
          • Address:  ipcucm:5560
    • Destination (1)
      • Alias (1)
        • Type: Url
        • Origin: Unknown
        • Value: sip:000130003@externaldomain.es
    • StartTime: 2015-09-22 13:10:31
    • Duration: 2.93
    • SubSearch (1)
      • Type: Transforms
      • Action: Not Transformed
      • ResultAlias (1)
        • Type: Url
        • Origin: Unknown
        • Value: 000130003@externaldomain.es
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: Url
          • Origin: Unknown
          • Value: 000130003@externaldomain.es
        • SubSearch (1)
          • Type: FindMe
          • Action: Proxy
          • ResultAlias (1)
            • Type: Url
            • Origin: Unknown
            • Value: 000130003@externaldomain.es
          • SubSearch (1)
            • Type: Search Rules
            • SearchRule (1)
              • Name: LocalZoneMatch
              • Zone (1)
                • Name: LocalZone
                • Type: Local
                • Protocol: SIP
                • Found: False
                • Reason: Not Found
                • StartTime: 2015-09-22 13:10:31
                • Duration: 0
                • Gatekeeper (1)
                  • Address: ipexp-c:0
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 000130003@externaldomain.es
              • Zone (2)
                • Name: LocalZone
                • Type: Local
                • Protocol: H323
                • Found: False
                • Reason: Not Found
                • StartTime: 2015-09-22 13:10:31
                • Duration: 0
                • Gatekeeper (1)
                  • Address: ipexp-c:0
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 000130003@externaldomain.es
            • SearchRule (2)
              • Name: B2B Out
              • Zone (1)
                • Name: Exp-e Traversal B2B
                • Type: TraversalClient
                • Protocol: SIP
                • Found: True
                • StartTime: 2015-09-22 13:10:31
                • Duration: 2.91
                • Gatekeeper (1)
                  • Address: ipexpr-e:7011
                  • Alias (1)
                    • Type: Url
                    • Origin: Unknown
                    • Value: 000130003@externaldomain.es

 

Bad call (from jabber codec to external uri):

 

  • Search (313)
    • State: Completed
    • Found: False
    • Reason: Service Unavailable
    • Type: SIP (INVITE)
    • CallSerial Number: c94f04ae-05bb-48c2-85c2-92d95ad36310
    • Tag: 03a7cb30-73da-4be7-a071-b49028627f85
    • Source (1)
      • Authenticated: True
      • Aliases (1)
        • Alias (1)
          • Type: Url
          • Origin: Unknown
          • Value: 11307@ipcucm
      • Zone (1)
        • Name: Traversal Zone MRA
        • Type: TraversalClient
      • Path (1)
        • Hop (1)
          • Address: ipexp-e:7001
        • Hop (2)
          • Address: 10.10.1.179:63679
    • Destination (1)
      • Alias (1)
        • Type: Url
        • Origin: Unknown
        • Value: sip:000130003@externaldomain.es
    • StartTime: 2015-09-22 11:43:28
    • Duration: 0.29
    • SubSearch (1)
      • Type: Directed
      • Path (1)
        • Hop (1)
          • Address: ipcucm
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value: sip:000130003@externaldomain.es;box-call-serial-number=09b9c907-5d74-4971-8fe1-7923e6bc9acc
        • Zone (1)
          • Name: DefaultZone
          • Type: Default
          • Protocol: SIP
          • Found: False
          • Reason: Service Unavailable
          • StartTime: 2015-09-22 11:43:28
          • Duration: 0.28
          • Gatekeeper (1)
            • Address: ipexp-c:5071
            • Alias (1)
              • Type: H323Id
              • Origin: Unknown
              • Value: sip:000130003@externaldomain.es;box-call-serial-number=09b9c907-5d74-4971-8fe1-7923e6bc9acc

 

Regards!!!

 

Something odd is going on here. It looks like Jabber is still trying to make this call as an MRA call.

Try adding a SIP Route Pattern (domain pattern) in CUCM for externaldomain.es and point it at your 5560 B2B SIP Trunk to Expressway. Then restart Jabber and try the call again. If it does not succeed please post the search history again.

Hi,

It seems to work...I configured the sip route patter to external domain and worked properly. After that I deleted the sip route patter again and I called back again and also worked ... I don´t understand anything...

 

I´m going to test everything again and to make more test.

 

Thanks for your help!!!

 

Regards!

Once the pattern was deleted it should not have worked, that is a little odd. Did you reset the SIP Trunk after deleting the pattern? Give that a shot and see if it makes a difference.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: