Globalized Dialplan Implementation

Note: For calling and called party transformation patterns CSS, if applied at DP, make sure that phones and gateway for specific site are in different DPs

Localized Calls Ingress on Phones - Once the user enters the dialed number

1. In case the called number is in globalized format (typically +E164), CUCM should accept it and start matching process
2. In case the called number isn't in globalized format, TPs should be used to globalize it (typically +E164). TPs must configured to accept all dialing habits from local users
3. In case the calling number is in globalized format (typically +E164), CUCM should accept it
4. In case the calling number isn't in globalized format, under Phone Configuration Window > Caller ID For Calls From This Phone > Calling Party Transformation CSS should be used to match Calling Party Transformation Pattern and globalize the calling number. You can apply this CSS at DP level instead of per phone

Note: Don't use TPs to globalize Calling Party Information because TPs aren't compatible with URI dialing

Localized Calls Ingress on Gateways - Once the gateway receives call from PSTN

1. The called number can be globalized using one of the following methods:
1. Using Call Routing Information - Inbound Calls section under the trunk or gateway. You can configure the number of significant digits and add prefix to these digits. For example, if the received called number is 5051234, you can configure the significant digits as 4 (1234) and prefix +1408561 which will convert the number to +14085611234
2. Using TPs to match the received called number and globalize it to standard format (typically +E164) used in CUCM. The Calling Search Space configured under Call Routing Information - Inbound Calls should have access to the TPs.
3. On H323/MGCP gateways, use Incoming Called Party Settings to globalize the received called number based on TON attribute. This configuration can be applied on DP as well instead of per gateway. Alternatively, under the same section, you can use CSSes to use Called Party Transformation Patterns. For this, you need to keep other fields as Default
2. The calling party information should be globalized using Incoming Calling Party Settings either based on TON attribute or CSSes combined with Calling Party Transformation Patterns. For example, a calling number received with TON as 'National' requires to prefix '+' sign, country code and area code. While a number received with TON as 'International' requires to prefix '+' sign only.

Localized Calls Egress - Once the call is delivered to phone or gateway with globalized calling and called numbers

1. For calls delivered to phone after globalized routing, use Remote Number > Calling Party Transformation CSS to localize the calling number. The localized number will be presented on phone display but the number stored in Missed Calls or Received Calls directory will remain in globalized format for Type-B phones. For Type-A phones, the localization will impact the directory as well.
1. If the globalized calling number represents a local user, it should be localized to 4-digits extension
2. If the globalized calling number represents a subscriber number, it should be localized to subscriber format
3. If the globalized calling number represents a international/national number, it should be localized to international format
2. For calls delivered to gateway after globalized routing, use Calling Party Transformation CSS to localize the calling number and TON to suitable format. For example, for calls existing San Francisco gateway, any globalized calling number with +1415! should be localized to strip '+', country code, area code and change TON to subscriber. Other calls existing San Francisco gateway with globalized calling number with +1! should be localized to strip '+', country code, and change TON to national.
3. For calls delivered to gateway after globalized routing, use Called Party Transformation CSS to localize the called number and TON to format suites the telco. For SIP Trunks, the TON can't be set and have to be 'Unknown'

Calling Search Spaces in Globalized Dialplan

The calling search spaces configured for each site should generally allow for:

• Localized intra-site dialing habits of the site - This will hit TPs
• Localized off-net dialing habits of the users at the site - This will hit TPs
• Applicable local telephony services such as emergency calls, directory, and operator services
• The globalized form of on-net and off-net numbers - This will hit RPs/DNs directly

Note: In case of overlap between globalized RP patterns and DNs/TPs, use Urgent priority to overcome the problem

CUCM Digit Manipulation Order of Operation

Digit manipulation can be applied at different levels during call routing process. As the call is being processed, the order by which digit manipulation applied is as follow:

You can see that the closer to the gateway, the higher the precedence of the manipulations. It is important to remember that if you manipulate on RP without modifying RL-RG manipulations (left them as default values), RP manipulations will take effect. If you modify any parameter in RL-RG manipulations (even if one), RP manipulations will be fully ignored. Same is applicable with Xformation Patterns and RL-RG manipulations.

Example#1

Let's assume that you changed 'Calling Party Transform Mask' under RP > Calling Party Transformations and changed 'Called Party Number Type' under RL-RG > Calling Party Transformations, in this case all settings under RP > Calling Party Transformations will be ignore including 'Calling Party Transform Mask'. The settings  under RL-RG > Calling Party Transformations will be used even the empty one for 'Calling Party Transform Mask'.

Example#2

Let's assume that you changed 'Calling Party Transform Mask' under RP > Calling Party Transformations and changed 'Called Party Number Type' under RL-RG > Called Party Transformations, in this case all settings under RP > Calling Party Transformations will be used and all settings under RL-RG > Called Party Transformations will be used.

Video Signaling Attributes

To start with important concept, in video calls each endpoint will advertise its receive capabilities for which the sending endpoint will use to encode.  Therefore, we can have asymmetric video streams. This is different from audio calls where both endpoints needs to agree on common audio stream parameters (codec, dtmf, etc)

Video Stream Negotiation

There are multiple attributes negotiated in video stream SDP

Bandwidth Attribute

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)

Video Codec Attributes

Video codec advertised by each endpoint is considered to be the desired receive codec. In below SDP body multiple codecs are advertised in the preference order (98 is H264 followed by 99 which is H263).

…

m=video 16446 RTP/AVP 98 99

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=rtpmap:98 H264/90000                            H.264/ Sampling Rate 90000 Hz

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;maxbr=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:99 H263-1998/90000                       H.263 version 2/ Sampling Rate 90000 Hz

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

a=rtcp-fb:* nack pli

a=rtcp-fb:* ccm tmmbr

H264

In H264 codec, there are two layers present which and Video Coding Layer (VCL) and Network Abstraction Layer (NAL).

The VCL layer creates a coded representation of the video image by partitioning the video frame into slices with each slice partitioned into Macroblocks (rectangular samples of pixels). The slices are grouped in NALU. Depending on the packetization mode advertised by endpoints, single or multiple NALUs can be encapsulated in single RTP packet.

Note: Multiple RTP packets can represent a single frame

Let's go deeper in H264.

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;maxcpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

profile-level-id=428016             The Profile-Level-ID describes the minimum set of features/capabilities that are supported by this endpoint

packetization-mode=1                These parameters describe the features and capabilities beyond those of the profile-level-id that are supported by this endpoint

max-mbps=245000

max-fs=9000

max-cpb=200

max-br=5000

max-rcmd-nalu-size=3456000

max-smbps=245000

max-fps=6000

Profile-Level-ID consists of 6 hex-digits. The first 4 hex-digits define the profile-id while the other 2 hex-digits define the level.  In our case the profile-id is 4280 while the level is 16. Profile-Level-ID must be symmetrical for the call

Profile-ID describes the subset of coding tools that the codec supports by the endpoint. The profile ID 4280 represents baseline profile (BP,66) which supports encoding features such as  Flexible Macroblock Ordering, Arbitrary Slice Ordering, Redundant Slices.

Profile Level describes the resolution, frame rate and bit rate that the endpoint can support. Level 16 in hex, which is 22 in dec, represents level 2.2 = 352 x 480 pixels @ 30 frames per second.

packetization-mode=1	Values (0,1,2) 0 = a single NALU packet sent in an RTP packet, no fragments 1= multiple NALUs can be sent in decoding order. Fragments allowed 2= multiple NALUs can be sent out of decoding order. Fragments allowed The negotiated packetization mode for the call must be symmetrical
max-mbps=245000	Max Decoding speed = Max Macroblocks/sec = 245000 (Baseline profile level 2.2 value = 20250)
max-fs=9000	Max Frame Size = 9000 Macroblocks (Baseline profile level 2.2 value = 1620)
max-cpb=200	Max Coded Picture Buffer size = 200 kbits (Baseline profile level 2.2 value = 4 kbits)
max-br=5000	Max video bit rate = 5000 kbps, Baseline profile level 2.2 value = 4000 kbps
max-rcmd-nalu-size=3456000	Max NALU packet size (bytes) that the receiver can handle
max-smbps=245000	Max Static Macroblock processing rate – macroblocks/second
max-fps=6000	Max Frames Per Second in 1/100s of a frame/second = 60 fps (Baseline profile level 2.2 value = 30 fps)

Offer (H.264 and H.263 Offered)

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200; max-br=5000; max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:99 H263-1998/90000

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

Answer (H.264 selected – Symmetric Attributes - Asymmetric attributes)

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=108000;max-fs=3600;max-cpb=200; max-br=5000; max-rcmd-nalu-size=1382400;max-smbps=108000;max-fps=6000

RTCP Attributes

Video endpoints use RTCP packets as feedback mechanism for rate adaption when packet loss/congestion is encountered. The negotiation of RTCP feedback mechanism is taking place as part of call establishment (part of video negotiation).

Looking at SDP body we can see the following RTCP headers

a=rtcp-fb:* nack pli	“rtcp-fb” RTP Control Protocol (RTCP) - Feedback “*” RTCP-Feedback for any of the offered video codecs NACK – Negative Acknowledgement – indicates the loss of one or more RTP packets PLI – Picture Loss Indication
a=rtcp-fb:* ccm tmmbr	“rtcp-fb” RTCP-Feedback “*” RTCP-Feedback for any of the offered video codecs “ccm” indicates support of codec control using RTCP feedback messages "tmmbr" indicates support of the Temporary Maximum Media Stream Bit Rate Request/Notification

 BFCP Video Attributes

BFCP video stream negotiation is exactly similar to main video stream negotiation. However, it is important to point out two headers in SDP body used to distinguish BFCP video from main video parameters. These two headers are content and label.

For main video stream the content parameter will be main while for BFCP video stream the content parameter will be slides (desktop sharing).

a=content:main

a=label:11

Or

a=label:12

a=content:slides

 The label parameter in BFCP video is very important and is mapped to floor-id in BFCP attributes.

…

a=rtpmap:99 H263-1998/90000

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

a=label:12

a=content:slides

a=rtcp-fb:* nack pli

a=rtcp-fb:* ccm tmmbr

m=application 5070 UDP/BFCP *

c=IN IP4 10.58.9.86

a=floorctrl:c-s

a=floorid:2 mstrm:12