Sunday, October 23, 2016

Inter-Cluster Music on Hold (MoH)


You need to enable the network infrastructure to support multicasting including multicast routing and PIM
MMoH can't be transcoded, doesn't support E-LCAC/RSVP and doesn't support MTP
MMoH isn't supported on ICT video calls

The concept of Intercluster MoH is similar to Intracluster MoH. The same two steps:

  1. Stop the current media stream
  2. Start new stream with MoH server

In the scenario of ICT, the holder phone will select the source audio file, while SIP/H323 trunk will select the MoH server. Therefore, we will always have the holdee phone and MoH server in two separate clusters.

Stop the Current Media Stream

To disable the current media stream in SIP protocol, an SDP INVITE message is sent from the holder cluster with C=IN IP4 0.0.0.0 and a=inactive. The holdee cluster will respond with 200OK including a=inactive. This is always Early Offer regardless of the trunk configuration

 

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK201f1b3afe
……
Content-Type: application/sdp
Content-Length: 240
v=0
o=CiscoSystemsCCM-SIP 8 2 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24588 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK201f1b3afe
……
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsCCM-SIP 8 2 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 32004 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

To disable the current media stream in H323 protocol, the holder cluster sends TCS=0 (EmptyCapabilitySet). Then both clusters will exchange Close Logical Channel (CLC) and ACKs.


Start New Stream with MoH Server

Unicast Moh

SIP ICT can be configured as Delayed Offer or Early Offer. However, the flow of MoH messaging is fixed regardless of the ICT type.

  1. Holder cluster will send non-SDP INVITE message to establish call between holdee and MoH server

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2242496dea
From: < sip:2000@10.170.10.200> ;tag=8~7689b99f-a889-44ca-94c1-e77fb5464394-28366982
To: < sip:3000@10.45.230.10> ;tag=8~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384555
Date: Sun, 13 Dec 2015 10:19:28 GMT
Call-ID: f7c7c980-66d14628-4-c80aaa0a@10.170.10.200
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: < sip:2000@10.170.10.200>
Remote-Party-ID: < sip:2000@10.170.10.200> ;party=calling;screen=yes;privacy=off
Contact: < sip:2000@10.170.10.200:5060;transport=tcp>
Content-Length: 0

  1. After exchanging provisional messages, Holdee cluster will send 200OK with SDP contents indicating the supported capabilities of Holdee

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2242496dea
……
Content-Type: application/sdp
Content-Length: 417
v=0
o=CiscoSystemsCCM-SIP 8 3 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 32202 RTP/AVP 9 0 8 116 18 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

  1. Holder Cluster will verify the capabilities of the Holdee and accordingly select the suitable capabilities of the MoH stream
  2. Holder Cluster will send ACK message to holdee cluster confirming the agreed capabilities

ACK sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2346a41b8
From: < sip:2000@10.170.10.200> ;tag=8~7689b99f-a889-44ca-94c1-e77fb5464394-28366982
To: < sip:3000@10.45.230.10> ;tag=8~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384555
Date: Sun, 13 Dec 2015 10:19:28 GMT
Call-ID: f7c7c980-66d14628-4-c80aaa0a@10.170.10.200
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 188
v=0
o=CiscoSystemsCCM-SIP 8 3 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 10.170.10.200
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendonly

Note that the message is including the following attributes:

a=X-cisco-media:umoh - This indicates to Holdee Cluster that the MoH stream is going to be Unicast Moh
c=IN IP4 10.170.10.200 - This indicates to Holdee Cluster the IP of the MoH server, for Holdee phone/gateway to connect. The port will be 4000
a=sendonly - This indicates to Holdee Cluster that the direction of the stream is unidirectional from MoH Server to Holdee phone/gateway

Multicast Moh

For MMoH the messaging is slightly different. MMoH isn't supported with EO ICT

  1. Holder cluster will send non-SDP INVITE message to probe the capabilities of the holdee

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK932d17d236
From: < sip:2000@10.170.10.200> ;tag=14~7689b99f-a889-44ca-94c1-e77fb5464394-28367010
To: < sip:3000@10.45.230.10> ;tag=14~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384562
Date: Sun, 13 Dec 2015 11:18:50 GMT
Call-ID: 44af9e00-66d15415-7-c80aaa0a@10.170.10.200
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: < sip:2000@10.170.10.200>
Remote-Party-ID: < sip:2000@10.170.10.200> ;party=calling;screen=yes;privacy=off
Contact: < sip:2000@10.170.10.200:5060;transport=tcp>
Content-Length: 0

  1. After exchanging provisional messages, Holdee cluster will send 200OK with SDP contents indicating the supported capabilities of Holdee

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK932d17d236
……
Content-Type: application/sdp
Content-Length: 418
v=0
o=CiscoSystemsCCM-SIP 14 3 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27928 RTP/AVP 9 0 8 116 18 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone

  1. Holder Cluster will verify the received capabilities and select the ones matching MoH server configuration
  2. Later, Holder Cluster will send ACK message confirming the selected capabilities back to Holdee Cluster

ACK sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK94686a6d9e
From: < sip:2000@10.170.10.200> ;tag=14~7689b99f-a889-44ca-94c1-e77fb5464394-28367010
To: < sip:3000@10.45.230.10> ;tag=14~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384562
Date: Sun, 13 Dec 2015 11:18:50 GMT
Call-ID: 44af9e00-66d15415-7-c80aaa0a@10.170.10.200
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 207
v=0
o=CiscoSystemsCCM-SIP 14 3 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24618 RTP/AVP 9
a=X-cisco-media:mmoh
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive

Note that the message is including the following attributes:

c=IN IP4 0.0.0.0 - This indicates to Holdee Cluster that MoH stream is inactive
a=X-cisco-media:mmoh - This indicates to Holdee Cluster that the MoH stream is going to be Multicast Moh
a=inactive - This indicates to Holdee Cluster that MoH stream is inactive

  1. Holder Cluster will send SDP INVITE message to establish the call between MoH Server and Holdee

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK952d3086b5
……
Content-Type: application/sdp
Content-Length: 199
v=0
o=CiscoSystemsCCM-SIP 14 4 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 239.1.1.1
t=0 0
m=audio 16384 RTP/AVP 0
a=X-cisco-media:mmoh+ConnSendOnly
a=rtpmap:0 PCMU/8000
a=ptime:20
a=recvonly

Note that the message is including the following attributes:

c=IN IP4 239.1.1.1 - This indicates to Holdee Cluster the Multicast Group address for holdee endpoint to join using IGMP report
a=X-cisco-media:mmoh+ConnSendOnly - This indicates to Holdee Cluster that Moh stream will be multicast and unidirectional
a=recvonly - This indicates to Holdee Cluster that Moh stream will be unidirectional

  1. Holdee Cluster will respond with 200OK message indicating that Holder settings have been accepted

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK952d3086b5
…….
Content-Type: application/sdp
Content-Length: 219
v=0
o=CiscoSystemsCCM-SIP 14 4 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 239.1.1.1
t=0 0
m=audio 16384 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=recvonly
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

  1. In the background, holdee will initiate IGMP process to join the MMoH stream

Note the difference between UMoH and MMoH signaling

  1. In UMoH, single Delayed Offer exchange is used to connect the Holdee to MoH server and get the stream
  2. In MMoH, two transactions are used
    1. Delayed Offer exchange with C=IN IP4 0.0.0.0/a=inactive to probe the capabilities of the holdee
    2. Early Offer exchange for holdee to join multicast group and get the stream

Resume Calls

Resuming held call follow the same steps which are:

  1. Stop the current media stream with MoH Server
  2. Start new stream with Holder. In this stage new codec negotiation will take place similar to new call setup. Also, this signaling will follow trunk type as EO or DO

at No comments:
Labels:

How CUCM Allocates Bandwidth for Video Stream?


The bandwidth attribute is presented in SDP body as b=:. This specifies the maximum amount of receive bandwidth supported by the endpoint.

The bandwidth attribute can be present in the session section and/or media section of the SDP body.


There are three types of Bandwidth Modifiers which can be present in the bandwidth header inside the SDP body:

  • Transport Independent Application Specific (TIAS) in bps: Bandwidth does NOT include the lower layers (e.g. RTP bandwidth only)
  • Application Specific (AS) in kbps: Bandwidth includes the lower layers (e.g. TCP/UDP and IP)
  • Conference Total (CT):  Max Bandwidth that a Conference Session will use

Example:

o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
s=SIP Call
b=TIAS:6000000                                    Transport Independent Application Specific bandwidth (RTP) in bits/sec
b=AS:6000                                         Application Specific bandwidth (RTP/UDP/IP) in kbps
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
b=TIAS:64000
… attributes of multiple audio codecs in the offer
…
m=video 16446 RTP/AVP 98 99
b=TIAS:6000000

For this endpoint – the maximum media stream bandwidths that can be received :

= 6 Mbps for all voice and video streams including UDP and IP headers (AS session bandwidth)
= 64kbps for voice RTP traffic – not including UDP and IP headers (TIAS audio)
= 6 Mbps for video RTP traffic – not including UDP and IP headers (TIAS video)

CUCM uses the following logic to communicate bandwidth modifiers to endpoints:

  • When generating an Early Offer or Re-Invite, CUCM uses the session modifier(s) type based on the configuration of the SIP Profile > SDP Session-Level Modifier for Early Invite and Re-invites (TIAS, AS, both)
  • When generating an Answer, CUCM uses the same session modifier(s) type received in the initial offer
  • When generating an Answer, Early Offer or Re-invite, CUCM uses the same bandwidth value for all session modifiers types

CUCM will use the following rules to select the video bandwidth to be used during the call and communicated to endpoints in bandwidth modifiers:

  • When CUCM receives an Offer or Answer from an endpoint, it checks whether there is a session level bandwidth modifier in the SDP:
    • If there is a session level bandwidth modifier, CUCM retrieves the bandwidth value from the modifier. If there is more than one modifier type, it retrieves the modifier in the following order of preference: Transport Independent Application Specific (TIAS), Application Specific (AS), Conference Total (CT).
    • If there is no session level bandwidth modifier, CUCM retrieves the bandwidth value from the sum of the media level bandwidth modifiers (e.g audio + video + bfcp video + fecc video).
  • The allocated bandwidth is the maximum of what the two endpoints support. If the maximum bandwidth is higher than Region Bandwidth, CUCM will replace the advertised value to the endpoints with the value in the region and the allocated bandwidth will be the region bandwidth. If the maximum advertised bandwidth is lower than region bandwidth, CUCM will use the maximum advertised bandwidth.
  • The selected bandwidth (whether region based or endpoint based) will be evaluated against E-LCAC. If the bandwidth (audio + video) is available, it will be deducted from the location and the call will proceed.  Else, the call will be dropped, retried as audio or AAR depending on the configuration

In CME, bandwidth modifier can be changed using the command 'voice-class sip bandwidth video tias-modifier bandwidth value [ negotiate end-to-end]'
at No comments:
Labels:

Cisco Extend and Connect

This feature isn't supported with Expressway MRA deployment

  • Extend and Connect vs. Single Number Reach
    • Same: Both of these features extend incoming calls to user's remote devices
    • Different:
      • SNR use Remote Destination Profile (RDP) to configure remote destinations. Extend and Connect use CTI Devices to configure remote destinations
      • Extend and Connect utilize Jabber client to control remote device (using CTI) and invoke features such as hold, transfer, conference, etc. SNR uses Enterprise Feature Access Codes to invoke features
      • In Extend and Connect, users can configure their own remote destinations using jabber client. Remote destinations can be configured by admins as well. In SNR, remote destinations can be configured by admins only
      • For outgoing calls, Extend and Connect will use Dial Via Office - Reverse (DVO-R) to dial remote devices and destination numbers then hairpin both call legs on the gateway. SNR will use Mobile Voice Access (MVA) feature for remote device to dial enterprise MVA number then initiate outgoing calls after successful authentication
  • Call Flow
    • Inbound Calls
      • Received incoming call @ jabber extension
      • All shared DNs will ring for incoming call
      • UCM will dial remote destination define by user using jabber client or admin
      • If user answers the call on jabber client, all mid-call features will be available including transfer, hold, conference.
    • Outbound Calls
      • User initiates outbound call using jabber client
      • UCM will dial remote destination using DVO-R
      • User will answer the call and will be redirected to called party.
      • Call will be hairpinned on the gateway
      • Calling Party ID displayed on called party and remote destination will be jabber DN (with digit manipulation applied)
  • Configuration
    • Add End User (local or LDAP)
      • Enable Mobility for End User
      • Assign Standard CCM End User and Standard CTI Enabled permissions
    • Add new phone
      • Select type CTI Remote Device
      • Select the desired Owner User ID (Device name populated automatically)
      • Assign Rerouting Calling Search Space which will be used to for receiving and placing calls to remote destination
      • Assign DN to the phone. This should be same as Jabber extensions
    • Assign CTI Remote Device and Jabber Client to End User
    • Set the Primary Extension on the End User
    • Optionally, you can create Remote Destination Device and assign it CTI Remote Device
      • Remote Destination Device name should be JabberRD to be used with Jabber Client
      • By default, Jabber Client can't add Remote Destination. Set UserDefinedRemoteDestinations in jabber-config.xml to True for users to be able to add remote devices
at 1 comment:
Labels:
Subscribe to: Comments (Atom)

DNS Performance Troubleshooting

When you are troubleshooting internet performance, there are different parts of the connection should be verified:   ·         DNS Pe...