cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8836
Views
30
Helpful
21
Replies

CUCM, VCS-Core and Edge, B2B Calling

Andrew M12
Level 1
Level 1

I have CUCM ver 9.1(2) and VCS 8.1.1 in my environment, the VCS-C and VCS-E are currently setup to do MRA which is working fine for the vpn-less Jabber.

We also have a number of SX series Telepresence codecs dotted about which are registered to the CUCM and used for internal video conferencing, now the company is wanting the ability for outside video conferencing so need to setup the B2B capability (licencing has been sorted out already for Rich Media Sessions)

I've been ploughing through a number of docs on this, I have not found one yet specifically for CUCM registered devices and VCS doing nothing but firewall traversal, so the guides I've been working from are for enabling CUCM registered devices to talk to VCS registered devices and just taking relevant bits such as Neighbour zones and SIP trunks from it.

Does anyone know of a guide specifically for the direction Cisco appear to want us to go, which is Telepresence devices registered to CUCM and the VCS just doing firewall traversal.

Or a guide on the firewall traversal part only and I can tack it on to my notes from the other adapted guides.

 

My current notes have the following tasks I think I need to do to get this working

- setup partition and CSS on the CUCM for Telepresence calls

- setup SIP trunk on CUCM pointing to Expressway-C (have subnotes on requirments for SIP Trunk Security profile and the SIP Profile)

- SIP route pattern(s) on the CUCM pointing to the SIP trunk

- Enterprise parameters on the CUCM such as Cluster FQDN, Organization Top Level Domain and URI Lookup Policy

 

- On the VCS-C a neighbour zone pointing to the CUCM

- Search rule to route inbound calls to CUCM neighbour zone

 

Is this looking correct so far?  If so then what else will I need to in relation to traversal zones and VCS-E call routing to get calls in and out the business?

 

thanks in advance

Tigre

2 Accepted Solutions

Accepted Solutions

George Thomas
Level 10
Level 10

That looks about right. The one thing i would do is for caller ID. In the SIP profile, I would enable "Use Fully qualified domain name for routing requests" checkbox. Also, I would enable Early offer if you are running 9.1.2SU1 (SU1 has a setting to enable early offer without an MTP, inserting the MTP will cause video issues). Also, on the SIP trunk, there is a setting for Calling and Connected party info format. Change that to the required setting for Caller ID. Also, if you look at the Expressway C/E guides, you might need to change the port number of the SIP trunk since the VCS C/E you are using is also being used for MRA which uses port 5060 for registrations etc.

VCS-E, you just need the normal traversal zone back to VCS-C and the appropriate search rules to send calls to VCS-C.

Also, I believe you are using Expressway C/Expressway E. VCS-C/VCS-E and Expressway C/E are two different products. :P

Please rate useful posts.

View solution in original post

Update as promised. This is now working, there was a minor configuration error which I'll highlight here to save other people any stress on deploying this

 

When setting up the SIP trunk for B2B purposes in a number of documents it mentions if you have MRA then be sure to use a different port than the default SIP ports 5060 so this is what I did choosing to use port 5560

In fact what you need to do is on the SIP Trunk Security profile change the port, so I had 5560

On the Expressway neighbour zone you must change the port so again 5560

But on the actual SIP trunk on the CUCM you must still keep it as port 5060

 

Here's an alright guide for setting up MRA and B2B, if you check out the bottom of page 29 you will see the discussion on why to not use 5060 if MRA is in play. Also it goes on to show you how to configure the SIP Trunk Security profile and then the SIP trunk itself, and the only mention of having port 5060 on the SIP trunk is a small screenshot on page 31

 

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/Feb2014/CVD-CollabEdgeUsingBE6000-Apr14.pdf

 

View solution in original post

21 Replies 21

George Thomas
Level 10
Level 10

That looks about right. The one thing i would do is for caller ID. In the SIP profile, I would enable "Use Fully qualified domain name for routing requests" checkbox. Also, I would enable Early offer if you are running 9.1.2SU1 (SU1 has a setting to enable early offer without an MTP, inserting the MTP will cause video issues). Also, on the SIP trunk, there is a setting for Calling and Connected party info format. Change that to the required setting for Caller ID. Also, if you look at the Expressway C/E guides, you might need to change the port number of the SIP trunk since the VCS C/E you are using is also being used for MRA which uses port 5060 for registrations etc.

VCS-E, you just need the normal traversal zone back to VCS-C and the appropriate search rules to send calls to VCS-C.

Also, I believe you are using Expressway C/Expressway E. VCS-C/VCS-E and Expressway C/E are two different products. :P

Please rate useful posts.

Thanks George for the advice

The use FQDN for routing requests is in my subnotes for the SIP Profiles but I'll check out the early offer and Caller ID parts in case I missed that.

I will check my automatic zones that the MRA setup creates to make sure there isn't a SIP port conflict with the neighbour zone created to the CUCM for B2B

Since posting this I've read some more and for the VCS-E I believe I need these

- traversal zone to VCS-C, have notes on settings recommended for it, also need to ensure the SIP ports are different to my MRA traversal zone

- search rule to send inbound to that traversal zone, matching my company's domain

- DNS zone for outbound calling

- search rule to send outbound calls to DNS zone, matches anything that isn't my company's domain


That's off the top of my head as my notes are in the office and I'm not there for a while.

Yup our setup is an Expressway-C/E one due to having the MRA configured up first, now I'm doing the B2B part I'm consciously calling it VCS-C/E to keep it fresh in my mind what I'm working on.
Was nice of Cisco to keep it all so simple with the naming parameters ;)

Correct, you need a separate traversal zone to send calls to VCS-C and eventually to CUCM. When you create a new traversal zone, make sure to change the port since the port 7001 has already been used by the UC Traversal zone. I bet you will need search rules on the VCS-C as well to send calls to CUCM.

Correct on the search rule/DNS zone. 

Please rate useful posts.

OK great George, thanks for the conversation. Have been out of action the past week and will be picking up on this tomorrow, think I have enough information to put a plan of action together

 

Appreciate your time

Excellent response by George as usual. Tigrepokje, what is the update on this. Its always good to update the forum for the benefit of others
 

Please rate all useful posts

The change document for this work was drafted and approved, it will be implemented sometime this week and will update then

In preparation for this, are there any test URIs out there that can be called to confirm the system is working?

The current status of this is that the configuration has been done on the CUCM and Expressway's but unable to make an outbound call as yet

Checked the DNA on CUCM and it agrees it will route the call to the SIP trunk leading to Expressway-C via the Neighbour zone on there.

The Neighbour zone is showing Active for all CUCM nodes

Used the Locate function on the Expressway-C and it agrees it would route the call to the Traversal Zone to the Expressway-E, the Traversal zone is Active

Used the Locate function on the Expressway-E and it agrees it would route the call to the DNS zone, the zone is On

Used the network tools on Expressway-E to confirm DNS resolution is working ok

It looks like the call is not getting past the SIP trunk as I could not see any Call history on either Expressways or a Search history, so the call didn't reach them.

Checking the CUCM logs it shows a "503 Service Unavailable" with "Reason: Q.850; cause=41" that means Temporary Failure, so that is highly useful! There are some common causes of 503 Service issues which I've checked off already, for anyone following this thread I will list here

 

- the CUCM SIP trunk is receiving traffic from another IP than that on the SIP trunk. I've checked on my system and configured the SIP trunk to use the hostname, FQDN and the IP address of my Expressway-C with same failure The SIP trunk checkbox for "Run on all active Unified CM Nodes" has been ticked from the beginning

 

- the device on the end of the SIP trunk is pointing at a CUCM not in the CCM Group assigned to the SIP trunk. Again on my systems Neighbour Zone it is configured for all 3 of my CUCM nodes and I listed them in the same order as the CCM group the SIP trunk uses.

 

If anyone has any comments/recommendations on the 503 Service Unavailable then myself and others watching this thread would be interested to hear them?

Can you attach the cucm logs here? Please inlcude calling and called number and time of call. Ensure cucm logs is set to detailed.

Please rate all useful posts

Thanks Ayodeji

See attached for the logs

Time of call 17:50

Calling - 8806

Called - test@webex.com

 

No rush on checking them, I've just found yet another guide on setting this up so I'm going to run through that now against my config in case I've missed something simple out, happens to the best of us

From the DA, it looks like the called number is changed from test@webex.com to moc.xebew? What is this? ANd yes the call never made it out of CUCM..

07194045.004 |17:50:38.840 |AppInfo  |Digit analysis: analysis results
07194045.005 |17:50:38.840 |AppInfo  ||PretransformCallingPartyNumber=8806
|CallingPartyNumber=8806
|DialingPartition=B2B_Telepresence_PT
|DialingPattern=([mM][oO][cC].[xX][eE][bB][eE][wW])
|FullyQualifiedCalledPartyNumber=moc.xebew
|DialingPatternRegularExpression=([Mm][Oo][Cc].[Xx][Ee][Bb][Ee][Ww])
|DialingWhere=
|PatternType=Enterprise
|PotentialMatches=NoPotentialMatchesExist
|DialingSdlProcessId=(0,0,0)
|PretransformDigitString=moc.xebew
|PretransformTagsList=
|PretransformPositionalMatchList=moc.xebew
|CollectedDigits=test
|UnconsumedDigits=
|TagsList=
|PositionalMatchList=
|VoiceMailbox=moc.xebew

Please rate all useful posts

That is webex.com backwards, then the collected digits is 'test' thus making up the called number of test@webex.com

Believe it is how domain pattern matching occurs

Yep, you are indeed correct. Looking deeper into the logs it seem that the disconnect request is happening on the inbound leg of the call. ie from tandberg to cucm. Have you tried another endpoint ie Jabber.

++Here CUCM attempt to setup the call and we get a new CI for the outboung leg++++

07194061.000 |17:50:38.841 |SdlSig   |CcSetupReq                             |restart0                       |SIPD(2,100,74,12)                |Cdcc(2,100,212,186977)           |2,100,13,45716.45^10.1.2.110^SEPE4C72266FC40 |[R:N-H:0,N:6,L:0,V:0,Z:0,D:0] CI=48162576 CI.branch=0  sBPL.plid=65 sBPL.l=1 sBPL.pl=5 sBPL.msd=0  FDataType=0opId=0ssType=0

 

++However before the setup is complete, there is a drop party request on the inbound CI+++

07194071.000 |17:50:38.844 |SdlSig   |DropPartyReq                           |await_command                  |MatrixControl(2,100,135,176691)  |Cdcc(2,100,212,186977)           |2,100,13,45716.45^10.1.2.110^SEPE4C72266FC40 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] ClearType= 0
07194072.000 |17:50:38.844 |SdlSig   |AuDisconnectRequest                    |wait                           |ConnectionManager(2,100,207,1)   |MatrixControl(2,100,135,176691)  |2,100,13,45716.45^10.1.2.110^SEPE4C72266FC40 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI1=48162575

 

Perhaps we should look at the logs on the tandberg endpoint too. To see if it is actually originating the disconnect

Please rate all useful posts

Have tried using Jabber but getting the same issue. Below are the logs for that time period, I cannot see any info on the call at all

 

Ive run through another guide now, the configuration side looks fine

Was checking the logs on the SX10 itself, appears to be reporting the same thing about 503 Service Unavailable, I had the logging on it set to "Extended Logging"

(NB - the address 10.1.99.198 in this case is not the SX10, it is my laptop as I was using the SX10's webgui to remotely control the device and make the call)

 

Currently discussing this issue with Cisco TAC, will update as and when more info comes

 

 

Line 1113: Sep 10 15:24:56.367 a9 appl[1529]: 6097.58 CuilApp   User admin(1001) about to execute command '/Phonebook/Search ContactType: any Limit: 100 Offset: 0 PhonebookType: local SearchString: test@webex.com' from 10.1.99.198.

Line 1114: Sep 10 15:24:56.375 a9 appl[1529]: 6097.58 CuilApp   User admin(1001) about to execute command '/CallHistory/Recents DetailLevel: Full Limit: 100 Offset: 0 SearchString: test@webex.com' from 10.1.99.198.

Line 1115: Sep 10 15:24:56.384 a9 appl[1529]: 6097.59 CuilApp   User admin(1001) about to execute command '/Phonebook/Search ContactType: any Limit: 100 Offset: 0 PhonebookType: corporate SearchString: test@webex.com' from 10.1.99.198.

Line 1117: Sep 10 15:24:58.634 a9 appl[1529]: 6099.84 CuilApp   User admin(1001) about to execute command '/Dial callType: Video number: test@webex.com' from 10.1.99.198.

Line 1125: Sep 10 15:24:59.154 a9 appl[1529]: 6100.36 MainEvents I: OutgoingCallInvoked(p=3) remoteURI='sip:test@webex.com' localURI='sip:8806@oni.co.uk' bookingID=''

Line 1164: Sep 10 15:24:59.859 a9 appl[1529]: 6101.07 MC I: CallParticipant: calledUri: sip:test@webex.com

Line 1190: Sep 10 15:24:59.890 a9 appl[1529]: 6101.10 SipPacket   INVITE sip:test@webex.com SIP/2.0

Line 1196: Sep 10 15:24:59.892 a9 appl[1529]: 6101.10 SipPacket   To: <sip:test@webex.com>

Line 1295: Sep 10 15:24:59.960 a9 appl[1529]: 6101.17 SipPacket   To: <sip:test@webex.com>

Line 1306: Sep 10 15:24:59.967 a9 appl[1529]: 6101.18 SipPacket   To: <sip:test@webex.com>;tag=1393374~8642d04e-70cd-49a5-b73c-5ca5fe21b218-48171693

Line 1313: Sep 10 15:24:59.970 a9 appl[1529]: 6101.18 SipPacket   ACK sip:test@webex.com SIP/2.0

Line 1318: Sep 10 15:24:59.972 a9 appl[1529]: 6101.18 SipPacket   To: <sip:test@webex.com>;tag=1393374~8642d04e-70cd-49a5-b73c-5ca5fe21b218-48171693

Line 1328: Sep 10 15:24:59.979 a9 appl[1529]: 6101.19 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:test@webex.com' cause=[normal('') 'LocalDisconnect']

Line 1333: Sep 10 15:24:59.986 a9 appl[1529]: 6101.19 MainEvents I: CallDisconnected(p=3) remoteURI='sip:test@webex.com' causeToLocal=[disconnected('Service Unavailable') 'RemoteDisconnect'] causeToRemote=[normal('') 'LocalDisconnect']

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: