Deploying Multistream Conferencing with vTS and CUCM

With the release of CE8 code for Cisco video endpoints (like the SX10 (8.1), SX20 (also MX200-G2 and MX300-G2) and SX80-based endpoints like the SX80, MX700 and MX800), and the appropriate infrastructure components, multistream video is a possibility.  Multistream video allows an endpoint to send multiple resolution video streams and have the bridge pass the most appropriate streams to the far-end video units.  The far end video unit would receive a full resolution stream of the active speakers, and then low quality streams of the other participants.  The most useful feature of multistream video is the ability to use both screens of a dual-screen video unit to see remote participants (when doing single-stream transcoded mode, you can only do single screen video, and secondary screen content.)  Multistream also allows for ActiveControl layout, which allows the endpoint to choose the video layout vs. the video bridge determining the layout of the participants (which has rudimentary DTMF layout control).

Components used in my lab configuration:

  • SX10 (CE8.1)
  • MX800 (CE8.0.1)
  • (2) 8845 video phones (used to inject more video streams — these endpoints do not support multistream, they do single stream and receive their layout from the bridge)
  • Conductor XC4.1
  • vTS 4.2(4.23)
  • CUCM 11.0(1)21900-11 (Latest and greatest version is a requirement) -or- VCS X8.7.1

This guide assumes you’ve already setup a Rendezvous (aka MeetMe) number/URI that is routed to Conductor/vTS and you’re able to to normal conference calls.  We’ll modify settings to enable multistream.

Guide to configure endpoints and CUCM SIP Profile – http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/solutions/cmrpremises/cmr-premises-deployment-guide-r6-0.pdf

The relevant portion of this configuration is to make sure your SIP trunk to conductor is in a Location that supports full quality video.  I sent the inter-region bandwidth to UNLIMITED in my test system.  Cisco recommends a minimum of 1mpbs per screen, otherwise the vTS bridge may kick that video unit down to single-stream transcoded mode.

Configure the endpoint to support multistream

In CUCM the setting is in the device specific settings, Multistream Mode needs to be set to Auto.  Despite some of the documentation reading otherwise, Auto will attempt to do multistream, there is not actually an On setting.

Configure CUCM

Configure the SIP Profile used by the SIP trunk to Conductor to include the following settings:

  • Allow iX Application Media and Allow multiple codecs in answer SDP are checked on.
  • SDP Transparency Profile is set to Pass all unknown SDP attributes

In System > Service Parameters > Call Manager Service > click advanced > set SIP Maximum Incoming Message Size to 18000.

Configure Conductor

On the Conductor server, under the Conference Template you’re using for your conference, select advanced template parameters and add:

  • Enable iX protocol – True and the box checked
  • Multiscreen layout – ActivePresence and the box checked

No settings on vTS need to be changed, it will automatically do multistream if the endpoints meet the requirements, and CUCM (or VCS) and Conductor are properly configured.

When you join with a multi-stream endpoint you will see the following on vTS Conferences page:

 

vts1

You’ll notice the endpoints that support multistream show Multistream, and the 8845 phone named “Mike White” is Standard because it only supports a single stream.

If we look at the statistics for 5580 (the SX80) you’ll see multiple video streams being sent and received:

vts2

 

Lastly if we look at the call statistics from the video endpoint itself, we see the same information:

endpoint1

 

The touchpanel now shows more details in the layout.  You can see each participant in the conference and the active speaker.

IMG_5313

 

While you can select from several canned layout modes (same typical layouts are you’re used to), this version doesn’t yet support complete drag and drop layout of individual participants where you want them.  If you select a particular participant, you can see information about any of the participants and boot them if you are meeting organizer:

IMG_5314

 

Overall its very cool, and sets the groundwork for much more flexibility in the future with layout control.

 

IMG_5315

Advertisements

Catalyst 3850 IOS 16.1.1

Upgraded my 3850 to Denali 16.1.1 today. The new unified web GUI for the whole switch is pretty slick.  There are a ton of new features. See the Release notes here.  Now this is the first release of 16 so I don’t know I’d jump on it for a production network until there is a bug fix rebuild, or at least without checking the open caveats.

I ran into a problem that the APs would register, the radios just wouldn’t come up. Nothing I tried in the GUI (like bouncing the radios between disabled and enabled) would get them to go Operationally UP.

Turns out the secret was to go into the guy and do a “no ap dot11 5ghz shutdown” and a “no ap dot11 24ghz s.”  The radios came right up and everything is working again.

CUBE SIP Lineside Phone Proxy Configuration

Today I finally worked through getting a Cisco 9971 SIP phone to register to CUCM via CUBE lineside SIP proxy for a tech session I am presenting in a few weeks.   A few notes follow…

Go grab IOS 15.3(3)M2 code and put it on the router you’re using.

The CUBE Cisco Unified Communications Manager Line-Side Support configuration guide is a train wreck and has multiple errors and omissions.  Work through it but make the following changes…

From the Guide…

In the Configure a PKI Trustpoint section make on step enter the line as “crypto pki trustpoint self-trustpoint” (or another unique name that will be used below in a later step).

There is a critical step missing in this section.   Step 8 which actually enrolls the trustpoint.  Type “crypto pki enroll self-trustpoint” (or the unique name yo used when defining the trustpoint.

In the Importing the CUCM and CAPF Key section don’t forget to repeat the process twice, once for the CallManager.pem certificate, and once for the CAPF.pem certificate.  Call the CAPF trustpoint “capf-trustpoint.”

In the Creating a CTL File section Step 2 – the name of the trustpoint is “self-trustpoint” (ignore the 6s), or the unique name you assigned above.

In Step 3 the capf-trustpoint name is “capf-trustpoint” (ignore the 6s)

 

Quit following the configuration guide at this point.

Now bail on the configuration guide and add this to your configuation.  Please note, if you are alreadying doing CUBE or SIP turnks to you gateway YOU MAY NOT WANT TO PASTE THIS IN TO A PRODUCTION VOICE GATEWAY!!

Enable CUBE (recall this is a licensed feature from Cisco)

voice service voip
no ip address trusted authenticate  !- DANGER DANGER DANGER — This is disabled by default and enabling this could open your gateway to TOLL FRAUD.  My system is isolated, and I used this command to allow CUBE to pass RTP from the outside to the inside in my lab environment.  Consult Cisco documentation before enabling this on a CUBE that is exposed to the internet!
allow-connections sip to sip
sip
header-passing
registrar server
nat auto
pass-thru headers unsupp
pass-thru subscribe-notify-events all
pass-thru content unsupp
registration passthrough
extension cucm
!
!

Define your URIs that will be modified

This is the outside interface of CUBE
voice class uri 1 sip
host ipv4:10.21.1.1

This is the inside interface of CUBE

!
voice class uri 2 sip
host ipv4:10.25.1.20

This is the CUCM Publisher

!
voice class uri 3 sip
host ipv4:10.25.1.60

Build the requisite SIP profiles – These can be cut and pasted EXCEPT for the part in Bold that needs to be changed to your CUCM PUB IP address before pasting

voice class sip-profiles 10
request INVITE peer-header sip contact copy “>(;.*)” u01
request REGISTER peer-header sip contact copy “>(;.*)” u02
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request REGISTER sip-header Contact modify “(.*)” “\1\u02”
!
voice class sip-profiles 11
request INVITE peer-header sip contact copy “>(;.*)” u01
request INVITE peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u02
response 200 peer-header sip contact copy “>(;.*)” u03
request CANCEL peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u04
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request INVITE sip-header SIP-Req-URI modify “.*” “INVITE sip:\u0210.25.1.60 SIP/2.0″
response 200 sip-header Contact modify “(.*)” “\1\u03”
request CANCEL sip-header SIP-Req-URI modify “.*” “CANCEL sip:\u0410.25.1.60 SIP/2.0″
!
voice class sip-hdr-passthrulist 10
passthru-hdr Remote-Pary-ID
passthru-hdr Call-Info
passthru-hdr Content-ID
passthru-hdr supported
passthru-hdr require
passthru-hdr Referred-By
!
voice class sip-copylist 10
sip-header SIP-Req-URI
sip-header contact
!
voice class sip-copylist 11
sip-header contact

 

Build the Phone Proxy – Modify anything below in Bold to your IP addresses

voice-phone-proxy cubepp
tftp-server address ipv4 10.25.1.60 local-addr ipv4 10.25.1.20 acc-addr ipv4 10.21.1.1
ctl-file ct1
access-secure
service-map server-addr ipv4 10.25.1.60 port 8443 acc-addr ipv4 10.21.1.1 port 8443
service-map server-addr ipv4 10.25.1.60 port 8080 acc-addr ipv4 10.21.1.1 port 8080
service-map server-addr ipv4 10.25.1.60 port 3804 acc-addr ipv4 10.21.1.1 port 3804
complete

 

voice-phone-proxy tftp-address ipv4 10.21.1.1
port-range 40000 50000
voice-phone-proxy tftp-address ipv4 10.25.1.20
port-range 40000 50000
voice-phone-proxy file-buffer size 30

Build your Dial Peers to proxy registrations

dial-peer voice 2 voip
description DP_facing_CCM
session protocol sipv2
session target ipv4:10.25.1.60
session transport tcp
destination uri 1
incoming uri via 3
voice-class sip extension cucm
voice-class sip call-route url
voice-class sip profiles 11
voice-class sip pass-thru headers 10
voice-class sip copy-list 11
dtmf-relay rtp-nte
codec transparent
!
dial-peer voice 1 voip
phone-proxy cubepp signal-addr ipv4 10.21.1.1 cucm ipv4 10.25.1.60
description DP_Access_Side
session protocol sipv2
session target registrar
session transport tcp tls
destination uri 2
incoming uri request 1
voice-class sip call-route url
voice-class sip profiles 10
voice-class sip registration passthrough registrar-index 1
voice-class sip pass-thru headers 10
voice-class sip copy-list 10
dtmf-relay rtp-nte
codec transparent

Enable the SIP User Agent

sip-ua
timers connection aging 60
registrar 1 ipv4:10.25.1.60 expires 3600 refresh-ratio 100 tcp

 

Test it out

Connect a phone to the inside of the network and register it successfully to your CUCM.  Perform a test call to make sure audio is working.

Move it to the outside (in my case I created VLAN21 and only had it routed on the outside interface of the CUBE router) and delete the CTL/ITL.  Change the TFTP to the outside IP address of CUBE (in my case 10.21.1.1).

If phone proxy is working it will register.  It can take a couple minutes.

 

Some debugging commands

  • show sip registration passthrough status
  • Debug voice dial-peer inout
  • Debug voice phone-proxy all

 

The Relevant Bits of my Lab Router Config

IP Address Scheme:

CUCM – 10.25.1.60

CUBE Inside – 10.25.1.20 (ip routable inside to CUCM)

CUBE Outside – 10.21.1.1 (typically this would be a public IP or natted to the outside)

 

Cisco 2951 Config

version 15.3

!
hostname C2951-LAB
!
crypto pki trustpoint cucm_trustpoint
enrollment terminal
revocation-check none
!
crypto pki trustpoint cucm_capf
enrollment terminal
revocation-check none
!
crypto pki trustpoint self-trustpoint
enrollment selfsigned
serial-number
subject-name CN=C2951-LAB
subject-alt-name 8945_SEC.lab.domain.com
revocation-check crl
rsakeypair pp_uno
!
!
crypto pki certificate chain cucm_trustpoint
certificate ca 6749FF335ACDECF99948DB3A35527681
308202A4 3082020D A0030201 02021067 49FF335A CDECF999 48DB3A35 52768130
0D06092A 864886F7 0D010105 05003064 310B3009 06035504 06130255 53311630
14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30 0A060355 040B1303
534C4331 14301206 03550403 130B534C 434C4142 32352D36 30310B30 09060355
04081302 5554310C 300A0603 55040713 0353434C 301E170D 31333130 32353035
33343236 5A170D31 38313032 34303533 3432355A 3064310B 30090603 55040613
02555331 16301406 0355040A 130D4369 73636F6F 6F6F6F6F 6F6F6F31 0C300A06
0355040B 1303534C 43311430 12060355 0403130B 534C434C 41423235 2D363031
0B300906 03550408 13025554 310C300A 06035504 07130353 434C3081 9F300D06
092A8648 86F70D01 01010500 03818D00 30818902 818100A3 54BD2EFD D87226F1
CDAAC4BA 8567040A 9814A2A3 8057E803 57AD56E4 6933D2E0 05B392F4 0091ECA6
B9609FE8 DC386317 75844DCD 5F78E8BB 055E77D4 AC03B99A EBE4184C A432D784
AB2CAEEB 539DEC55 409D1CC6 EE1E45C4 A8E1F89B 128ABAD9 C80D8DF0 5DD761FB
16B27305 49545567 F53B65E1 4461CF25 1CF5BE53 B8059F02 03010001 A3573055
300B0603 551D0F04 04030202 BC302706 03551D25 0420301E 06082B06 01050507
03010608 2B060105 05070302 06082B06 01050507 0305301D 0603551D 0E041604
14F5EC15 F22A21B2 02EB351E 2F7E9DB7 21226E3D 8F300D06 092A8648 86F70D01
01050500 03818100 321D20AB C0980512 2A9843BC 33D78624 A62E82AC C0CE9387
23EA2E5D 9BE12EFE 1A63114E 316A42B5 F36D73E5 68C93053 902D1FCB 86F0FA59
A14E7845 610F8590 4132D0A9 1A10D393 61D7A14C 6E8DAEEB BF33950F 676F7EE2
A0699D96 7E7121DE 820FE5BB F0332E61 1BDE9F43 D2FEB42C 2623A1B5 E768501D
B624BEBC 49C9500B
quit
crypto pki certificate chain cucm_capf
certificate ca 6109543C30968DE66EB25CE2C58CD0A7
3082029E 30820207 A0030201 02021061 09543C30 968DE66E B25CE2C5 8CD0A730
0D06092A 864886F7 0D010105 05003066 310B3009 06035504 06130255 53311630
14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30 0A060355 040B1303
534C4331 16301406 03550403 130D4341 50462D30 61666333 39323031 0B300906
03550408 13025554 310C300A 06035504 07130353 434C301E 170D3133 31303235
30353334 32395A17 0D313831 30323430 35333432 385A3066 310B3009 06035504
06130255 53311630 14060355 040A130D 43697363 6F6F6F6F 6F6F6F6F 6F310C30
0A060355 040B1303 534C4331 16301406 03550403 130D4341 50462D30 61666333
39323031 0B300906 03550408 13025554 310C300A 06035504 07130353 434C3081
9F300D06 092A8648 86F70D01 01010500 03818D00 30818902 818100A9 F234D83D
13CA75FE 2F9C6041 921DB77A 869CA6E3 29AC94E3 8EBB099F 2C33AE51 A5EFEC3D
B151D31A C2A1A02D 79727287 6F2910E3 DC308D1D E4841409 F6B7131C 5D0A40CA
DA4DDF8A 49682465 2BCA05F5 D3B8CF86 DC2D5136 2CB0F6F6 35747B7D 696AEE6C
F0947654 8A49D275 1D8501CA 1808F948 BAB32B37 8B5AD708 E122E902 03010001
A34D304B 300B0603 551D0F04 04030202 A4301D06 03551D25 04163014 06082B06
01050507 03010608 2B060105 05070305 301D0603 551D0E04 160414DF D666E78A
FCE19727 F039EF69 B44BA2DF B59D3730 0D06092A 864886F7 0D010105 05000381
81003667 BD568296 1280E5EF 26F22309 0901B655 1A694158 4731AAE7 E6EFD071
0FF1D024 F180A918 BC98DAF8 61DBB2BE FFD1A75B 56D49325 F49F75EB E22CB3C0
94447F2D 5E89B4D7 E511E554 374F4E52 7983A054 4F9B9EA3 4305042B EDB15EBD
3B5EDB8D FF4C8C83 5B0FF139 D5D7DD0D 001445F2 93E3DE30 5612DFF0 112B4214 783C
quit
crypto pki certificate chain self-trustpoint
certificate self-signed 01
308202A1 3082020A A0030201 02020101 300D0609 2A864886 F70D0101 05050030
59311530 13060355 0403130C 43323935 312D534C 434C4142 31403012 06035504
05130B46 54583137 3431414B 534B302A 06092A86 4886F70D 01090216 1D433239
35312D53 4C434C41 422E736C 636C6162 2E636973 636F2E63 6F6D301E 170D3134
30343038 31383032 31395A17 0D323030 31303130 30303030 305A3059 31153013
06035504 03130C43 32393531 2D534C43 4C414231 40301206 03550405 130B4654
58313734 31414B53 4B302A06 092A8648 86F70D01 0902161D 43323935 312D534C
434C4142 2E736C63 6C61622E 63697363 6F2E636F 6D30819F 300D0609 2A864886
F70D0101 01050003 818D0030 81890281 8100A67C DB60E221 6621A5B2 2F691BFC
5956086E 6B9AE741 885CAB9D B6898DFC C328A19C E4A4A981 DF0A76EB 1CA33CDA
016E1DE5 FD68FF6F 85F1CEBE 1F5A7D2B CD00F5BB DE3080D7 035A69DD 0C260447
0957E19D 2F27A9ED 0B1F6DE4 45AAACCB 16EE480C 1B7D1F51 7E652D36 DB208A00
F05956C4 07A7483D 1EC310AC F1D05346 CEB90203 010001A3 79307730 0F060355
1D130101 FF040530 030101FF 30240603 551D1104 1D301B82 19383934 355F5345
432E736C 636C6162 2E636973 636F2E63 6F6D301F 0603551D 23041830 16801464
E3A180EB 3CA73479 7E3AF3B7 E1181782 CB0B9630 1D060355 1D0E0416 041464E3
A180EB3C A734797E 3AF3B7E1 181782CB 0B96300D 06092A86 4886F70D 01010505
00038181 00A11F68 786EA2B2 EA741486 EF863E81 BF646077 DBE5CBDC 41159E24
15535334 9CF2427C A8A5271B 4D0D406B 4AB8E2D0 07F0ABCC E369616F 859CC789
EC25802C A34F89DC 2233A7D9 DD7EAE9D 0E2D831D 781D0B0B 54F43C8F 7F8FF899
6184A6D2 E882EF4B 3D2D5EC3 6475ACD5 72E4428D 71A9F0AF 43CB5F74 0CDD97D3
3CD36B8A 6B
quit
!
!
!
!
!
ip dhcp excluded-address 10.21.1.1 10.21.1.99
!
ip dhcp pool VLAN21
network 10.21.1.0 255.255.255.0
option 150 ip 10.21.1.1
default-router 10.21.1.1
!
!
!
ip domain name lab.domain.com
!
!
voice service voip
no ip address trusted authenticate
allow-connections sip to sip
sip
header-passing
registrar server
nat auto
pass-thru headers unsupp
pass-thru subscribe-notify-events all
pass-thru content unsupp
registration passthrough
extension cucm
!
!
voice class uri 1 sip
host ipv4:10.21.1.1
!
voice class uri 2 sip
host ipv4:10.25.1.20
!
voice class uri 3 sip
host ipv4:10.25.1.60
voice class sip-profiles 10
request INVITE peer-header sip contact copy “>(;.*)” u01
request REGISTER peer-header sip contact copy “>(;.*)” u02
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request REGISTER sip-header Contact modify “(.*)” “\1\u02”
!
voice class sip-profiles 11
request INVITE peer-header sip contact copy “>(;.*)” u01
request INVITE peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u02
response 200 peer-header sip contact copy “>(;.*)” u03
request CANCEL peer-header sip SIP-Req-URI copy “sip:([^@]*@)” u04
request INVITE sip-header Cisco-Guid remove
request INVITE sip-header Contact modify “(.*)” “\1\u01”
request INVITE sip-header SIP-Req-URI modify “.*” “INVITE sip:\u0210.25.1.60 SIP/2.0”
response 200 sip-header Contact modify “(.*)” “\1\u03”
request CANCEL sip-header SIP-Req-URI modify “.*” “CANCEL sip:\u0410.25.1.60 SIP/2.0”
!
voice class sip-hdr-passthrulist 10
passthru-hdr Remote-Pary-ID
passthru-hdr Call-Info
passthru-hdr Content-ID
passthru-hdr supported
passthru-hdr require
passthru-hdr Referred-By
!
voice class sip-copylist 10
sip-header SIP-Req-URI
sip-header contact
!
voice class sip-copylist 11
sip-header contact
!
interface GigabitEthernet0/1
ip address 10.25.1.20 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/2
ip address 10.21.1.1 255.255.255.0
duplex auto
speed auto
!
voice-ctl-file ct1
record-entry selfsigned trustpoint self-trustpoint
record-entry capf trustpoint cucm_capf
record-entry cucm-tftp trustpoint cucm_trustpoint
complete
voice-phone-proxy cubepp
tftp-server address ipv4 10.25.1.60 local-addr ipv4 10.25.1.20 acc-addr ipv4 10.21.1.1
ctl-file ct1
access-secure
service-map server-addr ipv4 10.25.1.60 port 8443 acc-addr ipv4 10.21.1.1 port 8443
service-map server-addr ipv4 10.25.1.60 port 8080 acc-addr ipv4 10.21.1.1 port 8080
service-map server-addr ipv4 10.25.1.60 port 3804 acc-addr ipv4 10.21.1.1 port 3804
complete
voice-phone-proxy tftp-address ipv4 10.21.1.1
port-range 40000 50000
voice-phone-proxy tftp-address ipv4 10.25.1.20
port-range 40000 50000
voice-phone-proxy file-buffer size 30
!
dial-peer voice 2 voip
description DP_facing_CCM
session protocol sipv2
session target ipv4:10.25.1.60
session transport tcp
destination uri 1
incoming uri via 3
voice-class sip extension cucm
voice-class sip call-route url
voice-class sip profiles 11
voice-class sip pass-thru headers 10
voice-class sip copy-list 11
dtmf-relay rtp-nte
codec transparent
!
dial-peer voice 1 voip
phone-proxy cubepp signal-addr ipv4 10.21.1.1 cucm ipv4 10.25.1.60
description DP_Access_Side
session protocol sipv2
session target registrar
session transport tcp
destination uri 2
incoming uri request 1
voice-class sip call-route url
voice-class sip profiles 10
voice-class sip registration passthrough registrar-index 1
voice-class sip pass-thru headers 10
voice-class sip copy-list 10
dtmf-relay rtp-nte
codec transparent
!
!
sip-ua
timers connection aging 60
registrar 1 ipv4:10.25.1.60 expires 3600 refresh-ratio 100 tcp
!

 

 

Jabber for Windows 9.7(0) is available on CCO

NOTE:  Although Jabber 9.7 supports Collab Edge MRA, it will not be officially TAC supported until Expressway 8.1.1 releases in the next few weeks.

 

Grab J4W 9.7 here — http://software.cisco.com/download/release.html?mdfid=284324806&flowid=46406&softwareid=284006014&release=9.7%280%29&relind=AVAILABLE&rellifecycle=&reltype=latest

Release notes are here — http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/JABW_BK_CF8F083D_00_cisco-jabber-for-windows-97.html

Please take a look at the release notes.  While Collab Edge MRA is supported in this client it is not TAC supported until Expressway 8.1.1 releases.  There are some notable feature exceptions to be aware of.

From the release notes:

When using Expressway Mobile and Remote Access to connect to services from outside the corporate firewall, the client does not support:

  • LDAP for contact resolution. Instead, the client must use UDS for contact resolution.
  • File transfer, including screen capture, is not supported with on-premise deployments. File transfer using Expressway Mobile and Remote Access is only supported using WebEx Cloud deployments.
  • Desk phone control mode (CTI), including extension mobility.
  • Extend and Connect. You cannot use the Jabber client to make and receive calls on a non-Cisco IP Phone in the office; to control a non-Cisco IP Phone in the office, such as hold/resume; or control a home or hotel phone when connecting with Expressway Mobile and Remote Access.
  • Dial via Office – Reverse calls.
  • Session persistency. The client cannot recover from disruptions caused by network transitions. For example, if a users start a Cisco Jabber call inside their office and then they walk outside their building and lose Wi-Fi connectivity, the call drops as the client switches to use Expressway Mobile and Remote Access.
  • Cisco WebEx Meetings Server. The client cannot access the Cisco WebEx Meetings Server server, or join or start on-premises Cisco WebEx meetings.
  • Sending problem reports. To work around this issue, users can save the report locally and send the report in another manner.
  • CAPF enrollment.
  • Early Media. Early Media allows the client to exchange data between endpoints before a connection is established. For example, if a user makes a call to a party that is not part of the same organization, and the other party declines or does not answer the call, Early Media ensures that the user hears the busy tone or is sent to voicemail. When using Expressway Mobile and Remote Access, the user does not hear a busy tone if the other party declines or does not answer the call. Instead, the user hears approximately one minute of silence before the call is terminated.
  • Self Care Portal.
  • End-to-end media encryption. Media is not encrypted on the call path between the Cisco VCS Control or Cisco Expressway-C and devices that are registered locally to Cisco Unified Communications Manager. The media path outside of the enterprise is encrypted.

Migrating your PRI gateways from h.323 to SIP

One of the recommendations in the CSR version 10 SRND is to use SIP trunks from CallManager to your IOS voice gateway.

This makes sense for multiple reasons:

  1. Avoid dealing with MGCP’s finicky nature when making changes.
  2. A big step towards moving your PSTN connections to SIP trunks and using CUBE as an SBC.
  3. Gateway call forking for call recording.

CUCM 10 includes the ability to fork calls at the gateway to the call recording server.  This is great news for large deployments where using the phone’s BIB for forking isn’t desirable.  Some information about gateway forking is here.

Migrating from h.323

The conversion process is pretty straightforward for anyone running h.323 as they’ll already have all of the necessary dial-peers built typically and will only need to deal with SIP DTMF issues and SIP SDP Early Offer issues for SCCP phones.

In a recent conversion that I did I did the following:

Modified the GW -> CUCM dial peers to look like this:

dial-peer voice 101 voip
preference 1
destination-pattern 5…$
session protocol sipv2
session target ipv4:192.168.65.10
session transport tcp
voice-class codec 1
dtmf-relay sip-notify

There are several ways to deal with DTMF.  I prefer OOB to In-band (rtp-nte / RFC 2833) personally, so I go with sip-notify.

We must make adjustments to the SIP Trunk Security Profile to Accept unsolicited notification so that the DTMF information will be allowed into CUCM.  I copy the normal Non-secure SIP Trunk Security profile to a new name (e.g. Non-secure SIP Trunk Security Profile — GW) and change this option.  I then apply this security profile to the trunk I create from CUCM to the Gateway.

DTMF becomes a problem for SCCP phones unless you do either an Early Offer SIP trunk, or you provide an MTP to deal with it.  There’s an excellent document here – https://supportforums.cisco.com/blog/154706 that discusses all of the various options.

I don’t really like having to force MTP for every call, especially since SIP phones won’t need it for DTMF, so I opted to create a new SIP Profile that enabled Early Offer support for voice and video calls (insert MTP if needed) and apply it to the trunk.

Converting from MGCP

Converting from MGCP is a more significant undertaking.  The PRI configurations all move from CUCM to the Gateway as dial-peers.  I’ll add more to this post to include a sample build of dial-peers to accomplish this.

 

Deploying Cisco Collaboration Edge – Updated

Update

Collab Edge is now supported.  The official Mobile-Remote-Access-via-Expressway-Deployment-Guide is located here.

I’m updating this document to reflect changes made in Expressway-C/E 8.1 that make importing the certificates MUCH easier.

Introduction

This document explains how to deploy Collaboration Edge with on-prem presence (IM&P/CUP) on a non-redundant set of Expressway-E and C VMs.  Deploying with WebEx Messenger is not covered here, but the bulk of the configuration is the same as far as the Expressway piece.

The biggest challenge in the initial deployment was finding all of the necessary documentation!  Things you need to know like certificate chaining, or OpenSSL are in various docs.  I’ve linked all of the documents that I used and tried to summarize things to make it quicker to deploy.

What you’ll need to deploy Collaboration Edge today:

  • CUCM 9.1(2)+
  • IM&P (CUP) 9.1+
  • VCS or “Expressway” X8.1.1+
  • A Collaboration Edge enabled Jabber client:  Cisco Jabber for Windows 9.7+, Cisco Jabber for iOS 9.6, Jabber for Android 9.6+ or Cisco Jabber for MAC 9.6+
  • Updated jabber-config.xml on CUCM with RemoteAccess turned on  (This is no longer required for Jabber 9.6+)
  • Two certificates (one for VCSe another for VCSc) – either signed by your own CA (OpenSSL or similar) or  publically signed certs like GoDaddy, Verisign, etc.

A few notes about nomenclature:

Collaboration Edge is the architecture umbrella term for the VCS/Expressway edge proxy for CUCM-registered clients (Jabber  and TC7.0 TP units).  It’s commonly used to refer to the Jabber piece of it, but will support endpoints too.  (The DX650 will support Collaboration Edge in a future release of firmware.  Traditional IP phones will not be supported, they will use VPN Phone or CUBE lineside proxy.)

Mobile and Remote Access (MRA) is the term used in VCS/Expressway documentation for the VPN-less Jabber (and CUCM-registered TC7.0 endpoint) proxy feature.

Cisco Expressway-Edge is the same software as VCS-Expressway, just packaged for CUCM registered endpoints.  Expressway-Edge is a VCS-Expressway that is deployed as a Mobile and Remote Access proxy or for traversal calls for CUCM registered endpoints.  There is a license file actually changes the title to say “Expressway-E” when it is loaded.  In the rest of the document, I will refer to VCS-Expressway, VCS-E, Expressway-Edge, Expressway-E as Expressway-E since we are primarily talking about MRA.

Expressway-Core is the same story.  It is VCS-Control software deployed as an MRA proxy only with the Expressway-C license loaded.  We call it VCS-Control when it is licensed for device registration, non-traversal calls, FindMe, and other features like Lync interop.  For purposes of this document I’ll call it the Expressway-C below.

Customers with a valid UCSS contract for UCL-Enhanced, CUWL-STD, or CUWL-PRO are entitled to Expressway-Edge and Expressway-Core for free (for MRA) and their license will reflect the Expressway names.  Licenses are charged for the other VCS features mentioned above.  Licenses are required and have a cost for B2B/B2C (Jabber Guest) calls through Expressway-C/E  Each box requires one media session license to get a session through.

VCS-C and VCS-E can have the MRA features turned on and run on a pair and do both functions.  We are still awaiting clarification as to when you must break these apart and run a separate set of VCS (for B2B, interop) and Expressway (for MRA) servers.  (Update:  VCS is supported for limited sized deployments.)

Expressway licenses should be orderable via PUT, or you can use your existing VCS severs by upgrading to X8.1.  (Update: I posted a later post that discusses what to order.)

Prepare CUCM for MRA

1) Create an AXL user if you don’t already have one on CUCM and IM&P.  There’s a good guide here –http://www.uplinx.com/cleanuptool/userguide/index.htm#page=Enable_AXL_on_CUCM.htm

2) Decide if you want to deploy valid security certificates on CUCM, IM&P and CUC.  You will likely want to do this independent of Collaboration Edge as all of the Jabber clients are no longer trusting self-signed certificates.  By providing a publicly trusted cert, Jabber won’t throw Invalid Certificate errors as you log in.  Granted they are only shown once during the very first login if the user accepts them on each client.  If you do put certificates on those components I’d suggest getting them for a 5-year term so you aren’t dealing with it in a year when the certificates expire.

Directory Lookup Considerations

 

MRA only supports UDS as the directory lookup service.  If you are inside you can use LDAP (EDI/BDI), outside UDS.

Jabber-config.xml Update for 9.6 clients

Update:  This section is no longer required as current versions of the clients (Win 9.7, iOS 9.6.1, Android 9.6, OS X 9.6) to do MRA by default, negating the requirement to pull the jabber-config.xml file first (expect in the case of split internal/external domains).


CUCM UC Service Profiles

Make sure that you’ve configure CUCM UC Service Profiles (this should have been done as part of your initial IM&P/CUP deployment and won’t be covered here) and assigned them to the end users.

Deploy Expressway OVAs

For new installations, you’ll need to download and deploy OVAs – http://www.cisco.com/en/US/docs/voice_ip_comm/expressway/install_guide/Cisco-Expressway-Virtual-Machine-Install-Guide-X8-1.pdf – See my previous post about upgrading to X8.1 if you’ve already got VCS installed – here

Recall there is a single OVA that does both Expressway-E/C and VCS-E/C that you need to deploy — it’s just a matter of how you configure and license (request via PUT as mentioned above) it as to what it is called.  Download the OVA from Cisco here

You’ll deploy the Expressway-C on your internal network (presumably on the same VLAN as CUCM and other UC components)  e.g. 10.10.1.30

You’ll deploy Expressway-E one of two ways.  Either on a stick in your DMZ (perhaps 10.99.99.30), or two-legged with the external interface in the DMZ network (e.g. 10.99.99.30 – or on your public address space), and the internal interface on the internal network (presumably on the same VLAN as Expressway-C and other UC components – e.g. 10.10.1.31).

You’ll need to trunk your DMZ to your ESXi host if you haven’t, or figure out how to deal with getting the Expressway-E external  (LAN2) interface in the DMZ network.

Once the VM’s are deployed edit the Expressway-E VM settings to put LAN2 in the DMZ network (alternately you can put LAN2 on the inside and LAN1 in the DMZ).  If you don’t see options for the second NIC, or options for NAT, you are missing the Advanced Networking license.  You need this in order to have it two legged, or do NAT.

Firewall Configuration

I don’t know how long I wasted on my first install because I forgot to modify the ACL to include the additonal ports that MRA requires.  I just assumed that beause VCS was working for B2B that it would work for MRA.  Not the case!

You’ll need to configure NAT on your firewall from a public IP address outside your network to the DMZ address of Expressway-E, or do 1:1 public to your DMZ if you’ve deployed it with a public address.

Look at p.258 of the Expressway Admin Guide for a concise list of ports.

 

A couple notes about DNS records

You will need two DNS servers for MRA to function properly.  Jabber decides if it is inside the network or outside the network depending on what SRV records it can resolve.  Depending on what records it resolves it will either try to use MRA or it will directly connect to CUCM/IM&P.

Internal DNS Server

Create two A records:

  • sjc-expressway-edge-01.domain.com A – (make this name whatever you want) Pointing to the INSIDE interface of Expressway-E for two-legged deployments, or pointing to the DMZ address if it’s on a stick.  The record is used by Expressway-C to lookup and validate the certificate against.  You will use this hostname anywhere you are asked for the expressway server’s name whe configuring the C server.
  • sjc-expressway-core-01.domain.com A – (any name you want) Pointing to Expressway-C.

Create two SRV records:

  • _cisco-uds._tcp.domain.com SRV 0 0 port 8443 – Pointing to CUCM.  (NOT IM&P!)
  • _cuplogin._tcp.domain.com SRV 0 0 port 8443 – Pointing to IM&P  (TBD if this is really required for Jabber 9.6 with IM&P 9.1 – I don’t believe it actually is)

When you launch Jabber, if it can resolve these DNS records, it knows it’s inside and pulls the service profile directly from CUCM and logs in to IM&P and CUCM.

External DNS Server

Create one A record:

  • sjc-expressway-edge-01.domain.com A – (any name you want) Pointing to the public address assigned (or NATted) to your Expressway-E.

Create one SRV record:

  • _collab-edge._tls.domain.com SRV 0 0 8443 – Pointing to Expressway-E (in our case sjc-expressway-edge-01.domain.com)

Configure Expressway-Edge and Expressway-Core

Follow this chapter of the Expressway Admin Guide  – Mobile and Remote Access (feature preview) beginning at p.52 but stop half-way down p.56 (before the beginning of the Certificates section).

A couple notes:  I did not enable TLS verify mode on my CUCM and IM&P server definitions because just wanted to get it up and running.  I’m suggesting putting real certs on CUCM, IM&P, and CUC, and turning TLS verify on, but this can be done later.

The admin guide is located here (p.52-56):

http://www.cisco.com/en/US/docs/voice_ip_comm/expressway/admin_guide/Cisco-Expressway-Administrator-Guide-X8-1.pdf

Certificates

Valid CA-signed certificates are required to setup the traversal zone for MRA.  You can either get public ones, or sign your own with your own CA.  I’ve done it both ways.  The major reason for a valid trusted CA-signed certificate is to stop Jabber from throwing a certificate warning on the initial MRA login to Expressway-E itself.  I highly recommend deploying a publicly trusted CA signed certificate.

Update:  This is fixed in Expressway 8.1.1  Ignore this section below:

Deprecated instructions for VCS 7.x:   The best document out there is this WebEx enabled Telepresence VCS Config document that describes how to chain up the intermediate cert properly here – http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/config_guide/webex_enabled_telepresence/cts_webex_vcse_cert.html

When importing the CA trusted certs, the key is to make sure the intermediate cert appears in the CA trust list ABOVE the root cert.

 

Expressway 8.1 Certificates

You will need to get a specific type of certificate, the multi-SAN (subject alternative names) also called a UCC certificate). 

Expressway-C CSR will be generated with the IM&P, and CUCM SANs.

Expressway-E needs the server itself and domain only as a SAN.

See the Expressway Certificate Guide for detailed information.

For Expressway-E follow this basic flow:

  1. Generate CSR
  2. Add UC Domain (domain.com) and XMPP server information
  3. Download the CSR
  4. Upoad the CSR file to the CA to get the certificate signed
  5. Get the signed server PEM and the root/intermediate chain PEM back from the CA.
  6. Upload the signed server cert to Expressway-E under Maintenance | Security Certificates | Server Certificate
  7. Break apart the CA-intermediate-root certificates into individual PEMs for import – See the WebEX instruction for VCS 8.1 to learn how to do this.
  8. Import into the Trusted CA certificate list: the top-level cert (“CA”), then the root cert, then the intermediate cert found under Maintenance | Security Certificates | Trusted CA Certificates
  9. Reboot to make them active.

Follow the Webex instructions to break apart the CA-intermediate and root PEM into individual certs using Windows so that you can import them into the CA trusted cert list properly.

Repeat this procedure for Expressway-C.

For the customers that I’ve worked with using GoDaddy certificates.  I’ve worked with four certificates – Go Daddy Class 2 CA; Go Daddy Root Certificate Authority – G2; Go Daddy Secure Certificate Authority – G2; the server certificate itself.

I used Chrome on Windows to export the three Go Daddy certificates individually to Base 64 .PEM and then loaded them into the Expressway-E/C trusted CA list.  This worked perfectly for me after loading and rebooting the servers.  The UC traversal zones came right up.

 

Sign your own using OpenSSL if you’d like

If you want to use OpenSSL to create your own CA cert and sign your CSR, it is actually easier than you’d think.

Start at the bottom of p.13 of this document –

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-1.pdf

You’ll follow the procedure twice.  Once for Expressway-E and once for Expressway-C.  Take the CA root cert that you generated and import it into the trusted list on both boxes, and then import your signed server cert on the appropriate box.

Traversal Zone Configuration

Resume the configuration tasks in the Admin guide on p.58 making sure to put the proper settings for both Expressway-E and Expressway-C.

If your certificates are good, you will see the traversal zone go active on both servers under Status | Unified Communications.  If not, double-check your configuration settings, and double-check your certificates.

Troubleshooting Zone Configuration

If the zone won’t go active and you think it looks good, check the logs to see what is happening.  My initial attempt where the certificates were not chained properly showed a continuous loop of TLS failures.  When I had my Expressway-C pointing to the external public address instead of the inside interface of Expressway-E, TLS looked good and even the SSH tunnel showed “up” but traffic wasn’t actually flowing.

The best place I found to troubleshoot this stuff was by putting the Expressway-C and E in “Devel mode” to enable the Experimental menu.  (Instructions for this are found on p.207 of the admin guide.)  The reason for this is because the CollabEdge/MRA feature is still considered experimental.  You need to look at the Developer Logs.  You can enable them for debug level as well as collect a tcpdump.

HTTP Whitelisting

 

Make sure to add your Unity Connection, and any other servers that Jabber needs access to.   Unity Connection requires it for Visual Voicemail to work.

Launch Jabber 9.6 internally

Update:  No longer required unless you are doing separate internal and external domains. (I’ll detail this in a later post.)

Launch Jabber on your client device on the inside network (so that it has direct access to CUCM/IM&P).  When you enter your email address Jabber should automatically discover your servers (using the before setup internal DNS SRV records).  If Jabber does not auto-discover, troubleshoot your SRV records.  The easiest method is to use dig or nslookup.

The quick nslookup method is to:

  1. Launch the program,
  2. Make sure it shows your internal DNS servers (that your device should be pulling via DHCP scope options)
  3. Enter set type=SRV, then type _cisco-uds._tcp.domain.com.  This should resolve to the hostname of CUCM, or the IP address of it.
  4. If using the hostname, exit nslookup and try to ping the hostname.

Once you enter your credentials you will likely be presented with several invalid certs to accept, and your client should connect and have IM, Presence, CUCM, CUC, and be able to IM and do voice/video calls.

Sign out and close Jabber

Launch Jabber 9.6 externally

 

Disconnect from your internal network and make sure your device is outside your network where a) it cannot resolve the internal SRV records, and b) it can resolve the external _collab-edge SRV record and access your Expressway-E from the outside.

Launch Jabber on your device.  Jabber will attempt to resolve _cisco-uds._tcp.domain.com and will fail to do so.  It will also attempt to resolve _cuplogin._tcp.domain.com and will fail.  It will then attempt to resolve _collab-edge._tls.domain.com and get pointed to the public IP address of Expressway-E.

It will then connect to Expressway-E, and a if everything is configured properly it will login and you’ll show connected to IM, CUCM and CUC!

Notes about iOS

 

On iOS the timeout for attempts to login is MINUTES long.   Be very patient for it to either succeed or fail.  It can take a significant amount of time to login successfully on the 9.6 build.  9.6.1 is supposed to be much faster.

If your login fails, click the Send Error Report and email it to yourself.  Open the ZIP file and look through (going from bottom to top) to see where the errors are.  The logs will include more than just the current login attempt, so note the time when you are attempting to login and look at the timestamps in the log.  This is critical so that you aren’t troubleshooting an old login that isn’t relevant to your current problem.

From my experience:

  • When I had firewall issues, I was seeing CONNECTION_TIMEOUT errors when trying to login via MRA, but not when I was inside.
  • When I had neglected to enable RemoteAccess in jabber-config.xml I was seeing RemoteAccess Policy errors.

Summary

I’m impressed with the ability to finally be able to do voice/video calls from anywhere!  It’s about time.  Collab Edge is still considered a Feature Preview by Cisco and isn’t TAC supported yet.  Please send me questions that you have as you attempt to deploy it.

-Mike

CoolTerm – Great Windows / OS X USB-Serial Console App

I typically have used iTerm and the screen command for USB-Serial console access.  But CTRL-Break is a nightmare.  SecureCRT is a great app, but they are up to $99 w/only 1-year of upgrades.

CoolTerm is a fantastic little free Windows and OSX Console program.  With a little tweaking it is perfect for serial console into routers/switches.

Once loaded, make the following changes in Options:

  • Select your USB-Serial adapter on the Port list.  Re-Scan serial ports if you didn’t plug it in before launching.
  • On the Terminal menu option select “CR” for Key Emulation, and Check the “Handle Backspace Character.”

Good to go.  Control-Break is just Command-B on the Mac.  Can’t beat that.