UC Techtorial CUCM v8.5+ … Social Miner … - Talk 2 Cisco IvanS .pdf · 2011-05-13 · Cisco Cisco ExpoExpo © 2011 Cisco and/or its affiliates. ... Remote Destination (RD) via

Cisco Public© 2011 Cisco and/or its affiliates. All rights reserved. 1Cisco Expo

Cisco Expo

2011

UC TechtorialCUCM v8.5+ …Social Miner …

Ivan Sýkora – Systems Engineer, CCIE #7398,

xmpp:[email protected]

2© 2011 Cisco and/or its affiliates. All rights reserved.Cisco Expo Cisco Public© 2011 Cisco and/or its affiliates. All rights reserved.Cisco Expo

• CUCM 8.5

• SME

• SIP trace

• QSIG

• Transparency & Normalizace

• Social Miner

• Demo ukázka


© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 4

• SIP Early Offer

• SIP Normalization and Transparency

• Call Routing Enhancements

• Session Management Edition Key Enhancements

Scalability, Load-balancing, SIP Call Trace

• New Native Mobility Support

Direct Connect UC Clients to Communications Manager on Android, iPhone, Blackberry, Nokia devices

4


• HD Video Interoperability

HD Interop among UC clients, TP and 3rd party with Media Experience Engine (MXE)

HD Resolution among UC endpoints/clients and 3rd party in H.264 codec

Cisco E20 Personal Video Endpoint Native in UCM 8.5

• Contact Center Enhancements

Agent Greeting – provide consistent customer experience

Whisper Announcements – provides call context prior to answering the Customer call

Petre,risti tyden se schazime s klukama na poste. Zvaz pripadne svoji ucast, Jarda asi nebude proti.IvanS

Cisco Confidential© 2010 Cisco and/or its affiliates. All rights reserved. 6

8.0

• RT, Servers/Core Work LDAP Filtering

• SAF/ Hunt CTI/ CLID FXO SDI Trace Reduction

• CSF 1.5, iPhone (R1+)–Dusting

• PCAP TCO

• Eth Wall, Call Inter.

• GGSG Features

• Call PU Line Group CTI Fixes

• EMCC, Encrypted Recording Con’tinuation of ECC

RSVP, ViPR

• Default Gateway in IPv6

• DiagPortal Annunciator (SIP)

• CTI Set2 : CallFwd Flag for CFS

• Off Path ASA Support

• IME Validation Security

• Pi12 for Grayback/Toledo

• IME Link Server Distributed Trace

• Parse large incoming Q.SIG messages

• Globalization of Ctd. Pty. Num.for ICME

• Skyhook

1HCY2011

1HCY 2010

2HCY2011

1HCY2012

2HCY 2009

8.5• Pajaro/Rendezvous, Pajaro Voicemail, US Dial Plan

• Whisper Coach, Agent Greeting

• C-Series Servers

• Video – Native interop& 3rd Party Interop – Phase 1

• Session Manager

• Performance

• OPTIONS Ping

• Serviceability, CAC

• EO, Q.SIG/SIP

• Mobility for SME

• RT-Lite SIP, R Lite SCCP IPv6

• Single Sign On

2HCY 2010

8.0(2)

• IME

8.0(3)

• Secure Indication Tone – Transfer

8.6• UCR2008• Rainbow – Volaris• RHEL5.5, Secure Linux• 9.2(1) Phone FW• VMWare Phase 2• Video – Phase 2 3rd Party Interop,

Preso Share, etc.• AI VOS – Ph 1 Productization• TFTP Scalability• Call Completion on Busy/SIP

9.0




2HCY10

UC 8.5

2HCY11

UC 7.1(3) UC 9.0

2HCY09

• Tandem Performance & Golden Bridge Test

• Multi vendor SIP and Q.SIG Interop with Nortel, Siemens, Avaya, Microsoft

• CUBE on ASR Integration testing

• SIP Trunk with CUBE• SIP Session Management

SRND• Fall Launch Material

including Roadmap• CUBE(Ent) to 5000 Calls

• Enterprise Scalability• SIP Serviceability Features• Call Routing Enhancements• Early Offer• OPTIONS Ping• Improved SIP Interop• B2BUA Tandem

Functionality• Call Admission Control• Clustering Over the WAN• Q.SIG/SIP • Mobility Requirements

1HCY10

UC 8.0

• B2B• RSVP w/ SIP

Preconditions• SAF (limited)• CURRI• CUBE(Ent) with T.38• CUBE(Ent) with

SWMTP• CUBE(Ent) to 15,000

Calls


SIP Trunking

Contact Center trunking

Application interconnects

Security

Multifunction (WAN & SBC)

Device consolidation

Device re-use

– Noise Cancellation


Scalability

• Increased usage of SME nodes for trunk processing and routing

• Enhanced per-cluster concurrent calls (25,000) and CPS (150) from 8.0 levels (15,000 and 100, respectively)

Load balancing

• Increased remote destinations for H.323 and SIP trunks (16)

• Enables greater load balancing across trunk groups

Session Manager Cluster

SIP Trunk Group

SIP Trunk Group

Cisco Unified Border Element

Unified CM Clusters


SAF Network – AS 100

DN Pattern ―to DID‖ rule IP address Protocol

1XXX 0:+1212444 10.2.2.2 SIP

8XXX 0:+1408902 10.2.2.2 SIP


1XXX 0:+1212444 10.2.2.2 SIP

8XXX 0:+1408902 10.8.8.8 SIP

SME SAF CCD Routing Table


1XXX 0:+1212444 10.1.1.1 SIP

8XXX 0:+1408902 10.8.8.8 SIP


1XXX 0:+1212444 10.2.2.2 SIP

8XXX 0:+1408902 10.2.2.2 SIP


1XXX 0:+1212444 10.2.2.2 SIP

1XXX 0:+1212444 10.1.1.1 SIP

Leaf 1 SAF CCD Routing Table Leaf 8 SAF CCD Routing Table

SME

1X

XX

8X

XX

PSTN

1XXX

1X

XX

PSTN

8XXX

8X

XX

PSTN

1XXX8XXX

10.2.2.2

10.1.1.1 10.8.8.8

Static (Non SAF) Trunk

SME can use SAF to distribute Internal DN ranges and To PSTN Prefixes

All intercluster IP calls route via SME

If SME is unreachable — Leaf cluster route calls to the local PSTN

If Leaf cluster is unreachable — SME routes calls to PSTN


1000 2000

3rd Party PBX or UCM

• Point Directory Number (DN) routing to SME

• Standard mobilityprovision

• Configure 3rd Party Desk Phone as a Remote Destination

CUCM-SMECM 8

MVS

NCC

e.g. Mobile: DN: 2000

Mobile #: 2145555555

e.g. 3rd party desk phone

2000 as an RD:

DN : 2000

RD#: 9728132000

3b. SME rings the

Remote Destination

(RD) via DN 2000,

which maps to 3rd

party PBX phone

number.

Call gets routed back

to 3rd party PBX via

trunk

1. 1000 calls 2000

2. Call routes to

SME via trunk

3a. SME rings the mobile via DN

2000, which maps to the mobile #,

and call gets routed to

PSTN/Cellular network via GW

whenever mobile is not in WiFI

mode.


Enterprise A

CUCM Cluster 1

CUCM Cluster n

PBX m

CUBE CUBE

IP PSTN

Leaf UC

Systems

SME

PSTN

2) XACMLReq (mcgpn=+19725550141, mcdpn=+19725550101)

3) XACMLRes(permit,continue,

modify callingnumber=+19725550100)

Policy Server

Bob

+19725550141

1) Dial 914695550101

4) Setup (cgpn=19725550100, cdpn=14695550101)

CUCM ADMIN

SME Administrator

assigns an

External Call

Control Profile to a

translation pattern

to intercept the

outbound call and

apply policy

http://developer.cisco.com/web/curri/home



• Enables transparent multi-protocol integration between Applications (e.g. Messaging, Collaboration) and multiple PBX vendors

• Calling/Called Party/DN information is retained

E.G. Callback, MWI, Transfer/Forward features work seamlessly

• Link/Trunk usage is optimized through path replacement

Cisco

Collaboration

MeetingPlace

SIP/SCCP

Cisco Messaging

Cisco Session Manager

Q.SIG over H.323ANNEXM.1

MGCP Q.SIG

Q.SIG over SIP

SIP/H.323


CUCM Session Management Edition - Features

CUCM 8.5 SIP Trunk – QSIG over SIP Trunks

QSIG over

SIP Trunk

QSIG over

SIP Trunk

QSIG over

SIP Trunk

QSIG over

SIP Trunk

QSIG over

SIP Trunk

QSIG over

SIP Trunk

QSIG over SIP is a pivotal CUCM

feature - Today, H323 Annex M1 ICT

Trunks are chosen by most

customers since they offered unique

QSIG features such as ―call back‖

between IP Phones in different

CUCM clusters. Likewise, QSIG TDM

PBXs connect to CUCM clusters via

MGCP Trunks from IOS Gateways.

When QSIG over SIP Trunks is considered in conjunction with the benefits that SIP

Trunks offer with CUCM 8.0 – e.g. SIP Options Ping, SIP Preconditions for RSVP Call

Admission Control, simpler configuration for Signaling Authentication and Encryption,

a greater range of codecs supported in comparison with other Trunk types etc……

SIP is likely to become the Trunk protocol of choice for the majority of our UC

customers.


Q.SIG Over SIP - Introduction

It makes SIP Trunk devices behave like a QSIG device

Following SIP Messages will carry a corresponding QSIG message as message body. Message body is binary encoded

SIP Message QSIG Message

INVITE SETUP

180 Ringing ALERT

183 Session Progress PROGRESS

200 OK CONNECT

INFO DISCONNECT

INFO RELEASE

BYE RELEASE COMPLETE

INFO FACILITY


CallBack

Callback on Busy Subscriber and Callback on No Response are supported with Connection Retention & Connection Release mode

Message Waiting (MWI)

This feature allows served user to be sent a Message Waiting Indication and also enables the indication to be cancelled

Path Replacement

For some supplementary services like, Call Transfer and Forwarding, the transit CUCM node is in the bearer path. In order to optimize the route, the requesting nodesends a rerouting number in a Path Replacement Proposal APDU in FACILITY message to the other node


Two fields in DN admin configuration to specify Alerting and Connected name.

Unicode – variable length 16 bit to specify languages that uses 16-bit(extended) character set.

ASCII – to encode languages that uses ASCII character set.

QSIG APDU carrying Names

Calling Name in QSIG SETUP message

Called Name in QSIG ALERT message

Connected Name in QSIG CONNECT message

Busy Name in QSIG DISCONNECT message



SIP Call Trace is a new feature in RTMT which let users trace calls and generate SIP message ladder or sequence diagram.

Feature added to support troubleshooting issues in SME scenario.

A new type of trace logs called calllogs, is introduced for sip call tracing. RTMT uses these logs to search for calls using the user entered search criteria and generate the ladder diagram.

Log files are downloaded from the server based on time stamps specified in the search criteria.

This tool also allows users to save the ladder diagram in html files on their machine which can be easily emailed for trouble shooting purposes.


Added new Enterprise Parameter to enable/disable Call Tracing globally.

This is to address potential performance issue due to amount of Call Tracing.


Users can search/trace for calls based on DNs (Calling Number, Called

Number), Start Time, and Duration.







• Enables Session Manager to modify and pass content from inbound to outbound SIP messages

• Flexible script language

• Trunk-specific scripts and parameters

• Example: Interwork Diversion and History-Info headers

• Allows Session Manager to interwork with a variety of Service Providers and 3rd

Party PBX’s

Cisco Session Manager

Turret

SIP Transparency and Normalization


• SIP is a complex, evolving, flexible protocol

Differing interpretations and degrees of compliance

Backward compatibility not always supported

Proprietary extensions are often necessary

Many different ways to accomplish goals

• SIP interoperability problems are very common

• SIP Transparency and Normalization

Provides powerful capabilities for UCM/SME to address interoperability problems

Usable by system administrators and supporting engineers with programming expertise and SIP knowledge

No need to wait for software updates for UCM/SME or other SIP systems


• Transparency

• Ability to pass through known and unknown message components from one SIP trunk to another

• For example, pass a proprietary header from incoming trunk to outgoing trunk

• Normalization

• Transformations on inbound and outbound SIP messages and content bodies

get and modify request/response line

get, add, modify, and remove parameters

get, add, modify, and remove headers

get, add, and remove content bodies

specific APIs for manipulating SDP


Display name and number interworking

PGW’s ISUP to SIP implementation is based on ITU-T Q.1912.5, which states that when interworking from ISUP to SIP the ACgPNwill map into the From Header and the CgPN will map into the P-Asserted-Identity Header. CUCM will always favor the value in the P-Asserted-Identity header. But Deutsche Bahn wishes to display the ACgPN in the From header instead. With scripting it is easy to remove or modify the P-Asserted-Identity.

There are many other examples and issues with display names and numbers.

Diversion Mask

Calling and called numbers can be transformed using a variety of configuration options as they traverse CUCM. However, this is not true for redirected numbers. With scripting, it is simple to apply a number mask to the Diversion header.

This capability is useful because many solutions require the number in the Diversion header to be externalized.

History-Info to Diversion (inbound)

Many SIP Trunk side endpoints (e.g. PBX’s in particular) support the History-Info header instead of the Diversion header for conveying redirected information. With scripting, it is simple to convert the inbound History-Info headers into Diversion headers which are understood by CUCM.

This solution has been successfully applied for interoperating Unity voicemail on CUCM connected to a Nortel PBX. In this case, when Nortel forwards the call to voicemail, it sends INVITE with History-Info to CUCM. Without the conversion from History-Info to Diversion, CUCM ignores the History-Info header, thereby loosing the voicemail box number.

Diversion to History-Info (outbound)

Opposite of the above for outbound messages.

SME 181 Transparency and Normalization

Microsoft requires CUCM to send 181 when the call is forwarded. A feature was implemented in CUCM to generate 181 in a previous release. However, for trunk to trunk calls, CUCM does not pass the 181 through to the other side. Inside it generates a 180 on the other side. This will be an issue for SME deployments with OCS on one side and CUCM on the other. With scripting, it is possible to transparently pass through the reason header from one side to the other. It is used to convert the would be 180 into a 181 making it appear as though SME transparently passed 181 through.


Unsolicited NOTIFY

CUCM includes an alphanumeric value in the userpart (i.e. ―voicemail‖) of the SIP URI in the From header contained within the unsolicited NOTIFY sent to control the MWI lamp. Nortel does not like the alphanumeric value and fails to respond or affect the lamp. With scripting it is easy to change the userpart to a numeric value.

T.38 Fax

An equipment up speeds to fax by sending in an SDP with both an audio m-line and an image m-line. Technically what they are doing is non-standard. But it happens to interoperate with many other vendor’s equipment. CUCM favors the audio m-line and ignores the image m-line causing the fax to fail. Since this happens to work with many other vendors, we get pressure from out customers to make it work. With scripting, this problem is possible to solve by removing and storing the audio m-line on the inbound message. When the response (i.e. SDP answer) is generated, the audio m-line is inserted back into SDP in the appropriate place and the port is modified to be zero.

CUCM 183 upon answer

Due to CUCM internal architecture, CUCM will often generate a 183 with SDP followed quickly by 200 with SDP when a device answers a call. This throws off other vendor’s equipment in many cases. With scripting it is simple to remove any unreliable 18x message. Other possibilities including removing the SDP and converting the 183 to a 180.

Codec reordering and filtering

Codec reordering and filtering is possible using the script environment.

Etc.

© 2009 Cisco Systems, Inc. -- Company Confidential 37

•Architecture


Protocol Independent Call Control

SIP UA

SIP UA

CUCM B2BUA

Endpoint EndpointSIP SIPCcCc

Without Transparency and Normalization

Message Consumed

during conversion to

internal Cc signals

Message Regenerated

from internal Cc signals

Unprocessed SIP &

SDP information is

lost

Protocol IndependentCall Control

with SIP Pass Through

SIP UA

SIP UA

CUCM B2BUA

Endpoint EndpointSIP SIP

Cc with SIP

Cc with SIP

Outbound

Normalization

Inbound

Normalization

Transparency

data

With Transparency and Normalization

Unprocessed SIP

information can be

passed through

Automatically

merge

transparency

data


SIPTcp

SIPHandler

(SIP Stack)

SIPD/Cdpc

Cc

RouteList

SIPD/Cdpc

SIPUdp

Normalization

Inbound

Normalization

happens before

SIP stack

processing

We can even

manipulate things

we don’t process Normalization

Outbound

Normalization

happens after SIP

stack processing

Transparent pass

through from one

leg to the other

SIPHandler

(SIP Stack)

Auto merge

transparency data

is last step before

outbound

normalization


•Normalization


1. Script based approach

• Lua scripting language

• Very light weight (i.e. small foot print)

• Designed to be embeddable

2. At most one script per trunk

3. Script state is maintained per trunk

4. Scripts manifest themselves as a Lua table containing a set of message handlers which use a well defined naming convention

• Request messages

<direction>_<method>

– direction is inbound | outbound

– method is the SIP method name

• Response messages

<direction>_<response-code>_<method>

– direction is inbound | outbound

– response-code is the SIP response code; e.g. 180, 200, 404, etc.

– method is the SIP method name from the CSeq header

A CLI based approach

isn’t flexible enough

+

We didn’t have

resources to provide a

bunch of admin UI

around this in 8.5


•Transparency


1. Triggered via scripting for inbound messages

2. CUCM exposes a Pass Through object to the script message handlers

local passthrough = msg:getPassThrough()

3. Inbound message handlers can add data to the pass through object. For example, to pass through a header

local subject = msg:getHeader(“Subject”)

if passthrough and subject

then

passthrough:addHeader(“Subject”, subject)

end

4. CUCM automatically merges the information in the pass through object into the appropriate outbound message

5. No scripting is required on the outbound side; but if there happens to be one, auto merge takes place just prior to invoking the outbound script


•Configuration


1. Add a script

2. Associate the script with a SIP Trunk

3. Configure Script Parameters

4. Consider script tracing

5. Save and Reset the SIP Trunk


Configure any script

parameters


•Examples


Calling and called numbers can be transformed using a variety of configuration options as they traverse Cisco UCM. However, there is limited flexibility for redirecting numbers. With scripting, it is simple to apply a number mask to the redirecting number carried in the Diversion header. The final destination may screen calls based on the value of the redirecting number.

Scenario:

• 1002 call forwards all calls to 2400

• 1001 (calling number) calls 1002 (redirecting number or original called number)

• Call is forwarded across the trunk to 2400 (called number)

2400

Script & Configuration

1001 1002 forwarded to 2400

INVITE


Configuration:

Note that in this example, there is configuration on the trunk to transform the calling number using the CallerId DN field. The script also requires configuration of a script specific parameter called Diversion-Mask.

• CallerId DN: 000180XXXX

• Script Parameters: Diversion-Mask=000180XXXX

Script:

M = {}

local mask = scriptParameters.getValue("Diversion-Mask")

function M.outbound_INVITE(message)

if mask

then

message:applyNumberMask("Diversion", mask)

end

end

return M


INVITE sip:[email protected]:5060 SIP/2.0

From: <sip:[email protected]>;tag=8d70e7ad-1982-4dd2-872f-6944059d09c8-26221945

To: <sip:[email protected]>

Contact: <sip:[email protected]:5060;transport=tcp>

Diversion: <sip:[email protected]>;reason=unconditional;privacy=off;screen=yes

P-Asserted-Identity: <sip:[email protected]>

Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off



INVITE sip:[email protected]:5060 SIP/2.0

From: <sip:[email protected]>;tag=8d70e7ad-1982-4dd2-872f-6944059d09c8-26221945

To: <sip:[email protected]>


Diversion: <sip:[email protected]>;reason=unconditional;privacy=off;screen=yes

P-Asserted-Identity: <sip:[email protected]>

Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off

Below, only the headers that are germane to this discussion are shown.


Some vendor’s equipment can make use of 181 when the call is forwarded. Other equipment may

not support 181. CUCM’s default behavior is to convert 181 to 180. However, with this feature it is

possible to transparently pass through the 181.

Note that in this example, A and B are named relative to the call direction. A is calling B. The B side

responds with a 181. The B side script passes through enough information for the A side script to

convert the would be 180 into a 181 with the appropriate Reason header.



181 Call is being forwarded180 Ringing

INVITEINVITE

PBX-A PBX-B

Script: B

181 Call is being forwarded

Script: A

181 Call is being forwarded

INVITEINVITE

PBX-A PBX-B


Since the B side script runs first for a 181 response, let’s consider it first. The B-side script

provides an inbound_181_INVITE message handler. This is automatically invoked for the

incoming 181. The handler, obtains the pass through object and the Reason header from the

message. Then it adds an X-Reason header to the pass through object. CUCM will

automatically merge the X-Reason header into the outbound message on the other side.

B = {}

function B.inbound_181_INVITE(msg)

local pt = msg:getPassThrough()

local reason = msg:getHeader("Reason")

if pt and reason

then

pt:addHeader("X-Reason", reason)

end

end

return B


The A-side script provides an outbound_180_INVITE message handler. This is automatically

invoked for the outgoing 180. The handler, obtains the X-Reason header from the message (it would

have been auto merged if the message on the B-side triggered the 181 message handler). The A-

side script then checks for the cause=181 in the X-Reason header value. If that is present, it simply

overwrites the response code and phrase with 181 Call is being forwarded, adds a Reason header,

and removes the X-Reason that was passed across.

A = {}

function A.outbound_180_INVITE(msg)

local reason = msg:getHeader("X-Reason")

if reason

then

if string.find(reason, "cause=181")

then

msg:setResponseCode(181,"Call is being forwarded")

msg:addHeader("Reason", reason)

end

msg:removeHeader("X-Reason")

end

end

return A




Below, only the headers that are germane to this discussion are shown.

SIP/2.0 180 Ringing

From: <sip:[email protected]>;tag=siptclTrunk-1476969522

To: <sip:[email protected]:5060>;tag=071d6b43-a5a4-4a9a-9d50-09bab443ffc2-29790174

Date: Mon, 17 May 2010 20:17:19 GMT

Call-ID: siptclTr-unk-5555--1476969526


P-Preferred-Identity: <sip:[email protected]>

Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off

SIP/2.0 181 Call is being forwarded

From: <sip:[email protected]>;tag=siptclTrunk-1476969522

To: <sip:[email protected]:5060>;tag=071d6b43-a5a4-4a9a-9d50-09bab443ffc2-29790174

Date: Mon, 17 May 2010 20:17:19 GMT

Call-ID: siptclTr-unk-5555--1476969526


P-Preferred-Identity: <sip:[email protected]>

Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off

Reason: SIP; cause=181; text="Call Forward Unconditional"

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 55© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 55© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 55Cisco Confidential 55© 2010 Cisco and/or its affiliates. All rights reserved.


Listen Engage


Airline lost my luggage!

Social

Appliance

1. Capture

2. Analyze & Prioritize

3. Communication Workflow

4. Assign & Engage

CustomerSocial Media

Customer Care Agent




Prosíme, ohodnoťtetuto přednášku.

UC1/L1

Documents

UC Techtorial CUCM v8.5+ … Social Miner … - Talk 2 Cisco IvanS .pdf · 2011-05-13 · Cisco Cisco ExpoExpo © 2011 Cisco and/or its affiliates. ... Remote Destination (RD) via