Wednesday, February 17

ShoreTel Virtual Trunk Switch – Configuration and License impact!

ShoreTel currently has three virtual appliances that can be used in place of the Orange ShoreGear voice gateways and conference servers.  These three virtual appliances are shipped within the ShoreTel core Server Software and consist of OVA files and ISO images.  The tree appliances consist of the phone switch; the trunk switch and the Service Appliance, a virtual replacement for the SA-100 and SA-400 conference servers.   Once they are virtualized, they install exactly like the hardware versions of the Orange ShoreGear boxes.   The only noticeable difference, is that the configuration page in the ShoreWareDirector does not seem to offer up the image of the switch as it does with the hardware version.    There are no drop down boxes for configuration of switch feature options in large part because each option is defined by the OVA file.    We note only two ISO images in the FTP root of the HQ server, so we have concluded that  the same ISO is used for the phone switch as is used for the trunk switch, the differences being set by the OVA file.
Each of the virtual devices install in a very similar manner, with little difference as it relates to the bring up under VMware.    Open the proper OVA file and the hardware is appropriately configured.  Launch the machine and you will be required to provide the normal Network configuration data and identify the location of the ShoreTel HQ/FTP server.   After the machine is configured you can log in as root, run Ifconfig to check your network card settings and note the MAC address for configuration in the ShoreWareDirector.    Then bring up the cli interface using “stcli” and you will be greeted with the familiar and easy to navigate ShoreTel Switch menu system.  You will need to add the FTP, NTP and DNS address information.   Having a primary NTP source is of critical importance especially when configuring the Service Appliance used for conferencing applications.
Now that the virtual machine is configured and running you can add it in the ShoreWareDirector.   Again aside from the lack of an orange switch image on the configuration page, it installs like any other ShoreGear device.  From a license perceptive, no harm done until you actually configure a SIP trunk.   In addition to the normal SIP trunk licenses you will need for any of the hardware gateways, the vTrunk switch will require licenses as you add trunks to the virtual appliance.   All in all this is sweet stuff and you should have a ball playing with virtual switches!  The video walks you through the entire setup! – DrVoIP@DrVoIP.com
at No comments:

CISCO Conference Now in Version 11

CISCO for one, has now addressed this in the most recent release of CISCO Unified Call Manager, Version 11.   A new feature, “Conference Now” has been added to the still available meet me conference facilities.    Setup is relatively simple and now provides password protection for conference ports.   Call into the Conference Now IVR application and you will be prompted for a meeting ID and a password.  The password is provided by the “host” who must be a participate before the conference can begin.   Advanced features like calendaring still require an external conference facility, but if you are looking for audio conference security, this is an ideal solution and is bundled as a basic feature of CUCM Version 11!
ConferenceNow

Basic Configuration

Conference Now Configuration is simple and a new line entry in CUCM Call routing administrator web page.  Just give the application a Directory Number, Route Partition, a Description and set the maximum time the bridge should wait for the “host” to join before dumping everyone!   You can also select a Music source that provides the media conference attendees will hear until the host joins!  Then Set Media Resources, Confirm that IVR is registered with phone system and that it is be part of Media Resource Group.
Users must have the “Conference Now” privileged enabled before they can establish conference sessions.   Under User Management you enable the users privilege to use this as a host and set their PIN.  A good practice is to set that users extension number as the Meeting Number.   Granted, not the most secure solution as you basically establish the same attendee access code for all that users conference sessions, but it is way more usable than the previous meet me conference solution.
ConferenceUser

Select or Create Custom Prompts!

There is a library of CISCO provided prompts to support this IVR application, but you can create custom prompts and select them as appropriated!
ConferencePrompts
As embedded Conference facilities go, this is about the best we have seen.   It is a standard Call Manager feature and can be enabled by individual User and provides password protection for Conferences in session!

at No comments:

Thursday, February 19

VoIP bandwidth fundamentals

Bandwidth requirements for Voice over IP can be a tricky beast to tame until you look at the method and factors involved. This guide investigates what bandwidth means for VoIP, how to calculate bandwidth consumption for a VoIP network and how bandwidth can be saved by using voice compression
Voice over IP (VoIP) is the descriptor for the technology used to carry digitized voice over an IP data network. VoIP requires two classes of protocols: a signaling protocol such as SIP, H.323 or MGCP that is used to set up, disconnect and control the calls and telephony features; and a protocol to carry speech packets. The Real-Time Transport Protocol (RTP) carries speech transmission. RTP is an IETF standard introduced in 1995 when H.323 was standardized. RTP will work with any signaling protocol. It is the commonly used protocol among IP PBX vendors.
An IP phone or softphone generates a voice packet every 10, 20, 30 or 40ms, depending on the vendor's implementation. The 10 to 40ms of digitized speech can be uncompressed, compressed and even encrypted. This does not matter to the RTP protocol. As you have already figured out, it takes many packets to carry one word.
The shorter the packet, the shorter the delay
End-to-end (phone-to-phone) delay needs to be limited. The shorter the packet creation delay, the more network delay the VoIP call can tolerate. Shorter packets cause less of a problem if the packet is lost. Short packets require more bandwidth, however, because of increased packet overhead (this is discussed below). Longer packets that contain more speech bytes reduce the bandwidth requirements but produce a longer construction delay and are harder to fix if lost. Many vendors have chosen 20 or 30ms size packets.
RTP packet format
The RTP header field contains the digitized speech sample (20 or 30ms of a word) time stamp and sequence number and identifies the content of each voice packet. The content descriptor defines the compression technique (if there is one) used in the packet. The RTP packet format for VoIP over Ethernet is shown below.
Ethernet
Trailer		Digitized
Voice		RTP
Header		UDP
Header		IP
Header		Ethernet
Header
RTP can be carried on frame relay, ATM, PPP and other networks with only the far right header and left trailer varying by protocol. The digitized voice field, RTP, UDP and IP headers remain the same.
Each of these packets will contain part of a digitized spoken word. The packet rate is 50 packets per second for 20ms and 33.3 packets per second for 30ms voice samples.The voice packets are transmitted at these fixed rates. The digitized voice field can contain as few as 10 bytes of compressed voice or as many as 320 bytes of uncompressed voice.
The UDP header carries the sending and receiving port numbers for the call. The IP header carries the sending and receiving IP addresses for the call plus other control information. The Ethernet header carries the LAN MAC addresses of the sending and receiving devices. The Ethernet trailer is used for error detection purposes. The Ethernet header is replaced with a frame relay, ATM or PPP header and trailer when the packet enters a WAN.
'Shipping and handling'
In reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IP and usually over Ethernet. The headers and trailers are required fields for the networks to carry the packets. The header and trailer overhead can be called the shipping and handling cost.
The RTP plus UDP plus IP headers will add on 40 bytes. The Ethernet header and trailer account for another 18 bytes of overhead, for a total of at least 58 bytes of overhead before there are any voice bytes in the packet. These headers, plus the Ethernet header, produce the overhead for shipping the packets. This overhead can range from 20% to 80% of the bandwidth consumed over the LAN and WAN. Many implementations of RTP have no encryption, or the vendor has provided its own encryption facilities. An IP PBX vendor may offer a standardized secure version of RTP (SRTP).
Shorter packets have higher overhead. There are 54 bytes of overhead carrying the voice bytes. As the size of the voice field gets larger with longer packets, the percentage of overhead decreases -- therefore the needed bandwidth decreases. In other words, bigger packets are more efficient than smaller packets.
Header compression
Cisco has created a header compression technique that is now the standard called RTP header compression. This technique actually compresses the RTP, UDP and IP headers and significantly reduces the RTP, UDP and IP overhead from 40 bytes to between 4 and 6 bytes. The bandwidth consumption for compressed voice packets can be reduced by nearly 60%. This technique has less value for large uncompressed voice packets. The header compression technique is not recommended for the LAN implementations because there is typically more than enough bandwidth for voice calls. The header compression technique should be considered for the WAN implementations, where bandwidth is limited and much more expensive.


RTP packet format
The RTP header field contains the digitized speech sample (20 or 30ms of a word) time stamp and sequence number and identifies the content of each voice packet. The content descriptor defines the compression technique (if there is one) used in the packet. The RTP packet format for VoIP over Ethernet is shown below.
Ethernet
Trailer		Digitized
Voice		RTP
Header		UDP
Header		IP
Header		Ethernet
Header
RTP can be carried on frame relay, ATM, PPP and other networks with only the far right header and left trailer varying by protocol. The digitized voice field, RTP, UDP and IP headers remain the same.
Each of these packets will contain part of a digitized spoken word. The packet rate is 50 packets per second for 20ms and 33.3 packets per second for 30ms voice samples.The voice packets are transmitted at these fixed rates. The digitized voice field can contain as few as 10 bytes of compressed voice or as many as 320 bytes of uncompressed voice.
The UDP header carries the sending and receiving port numbers for the call. The IP header carries the sending and receiving IP addresses for the call plus other control information. The Ethernet header carries the LAN MAC addresses of the sending and receiving devices. The Ethernet trailer is used for error detection purposes. The Ethernet header is replaced with a frame relay, ATM or PPP header and trailer when the packet enters a WAN.
'Shipping and handling'
In reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IP and usually over Ethernet. The headers and trailers are required fields for the networks to carry the packets. The header and trailer overhead can be called the shipping and handling cost.
The RTP plus UDP plus IP headers will add on 40 bytes. The Ethernet header and trailer account for another 18 bytes of overhead, for a total of at least 58 bytes of overhead before there are any voice bytes in the packet. These headers, plus the Ethernet header, produce the overhead for shipping the packets. This overhead can range from 20% to 80% of the bandwidth consumed over the LAN and WAN. Many implementations of RTP have no encryption, or the vendor has provided its own encryption facilities. An IP PBX vendor may offer a standardized secure version of RTP (SRTP).
Shorter packets have higher overhead. There are 54 bytes of overhead carrying the voice bytes. As the size of the voice field gets larger with longer packets, the percentage of overhead decreases -- therefore the needed bandwidth decreases. In other words, bigger packets are more efficient than smaller packets.
Header compression
Cisco has created a header compression technique that is now the standard called RTP header compression. This technique actually compresses the RTP, UDP and IP headers and significantly reduces the RTP, UDP and IP overhead from 40 bytes to between 4 and 6 bytes. The bandwidth consumption for compressed voice packets can be reduced by nearly 60%. This technique has less value for large uncompressed voice packets. The header compression technique is not recommended for the LAN implementations because there is typically more than enough bandwidth for voice calls. The header compression technique should be considered for the WAN implementations, where bandwidth is limited and much more expensive.


  • Bandwidth requirements reduce with compression, G.711 vs. G.729.
  • Bandwidth requirements reduce when longer packets are used, thereby reducing overhead.
  • Even though the voice compression is an 8 to 1 ratio, the bandwidth reduction is about 3 or 4 to 1. The overhead negates some of the voice compression bandwidth savings.
  • Compressing the RTP, UDP and IP headers (cRTP) is most valuable when the packet also carries compressed voice.
Packet voice transmission requirements
(Bits per second per voice channel)
CodecVoice bit rateSample timeVoice payloadPackets per secondEthernet
PPP or Frame Relay
RTPcRTP
G.71164 Kbps20 msec160 bytes5087.2 Kbps82.4 Kbps68.0 Kbps
G.71164 Kbps30 msec240 bytes33.379.4 Kbps76.2 Kbps66.6 Kbps
G.71164 Kbps40 msec320 bytes2575.6 Kbps73.2 Kbps66.0 Kbps
G.729A8 Kbps20 msec20 bytes5031.2 Kbps26.4 Kbps12.0 Kbps
G.729A8 Kbps30 msec30 bytes33.323.4 Kbps20.2 Kbps10.7 Kbps
G.729A8 Kbps40 msec40 bytes2519.6 Kbps17.2 Kbps10.0 Kbps
Note: RTP assumes 40-octets RTP/UDP/IP overhead per packet
Compressed RTP (cRTP) assumes 4-octets RTP/UDP/IP overhead per packet
Ethernet overhead adds 18-octets per packet
PPP/Frame Relay overhead adds 6-octets per packet



The varying designs of packet size, voice compression choice and header compression make it difficult to determine the bandwidth to calculate for a continuous speech voice call. The IP PBX or IP phone vendor should be able to provide tables like the one above for their products. Many vendors have selected 30 ms for the payload size of their VoIP implementations. A good rule of thumb is to reserve 24 Kbps of IP network bandwidth per call for 8 Kbps (G.729-like) compressed voice. If G.711 is used, then reserve 80 Kbps of bandwidth.
If silence suppression/voice activity detection is used, the bandwidth consumption may drop 50% -- to 8 Kbps total per VoIP call. But the assumption that everyone will alternate between voice and silence without conflicting with each other is not always realistic. Silence suppression will be discussed in a later tip.
Most enterprise designers do not perform these calculations. The vendor provides the necessary information. The designer does have some freedom, such as selecting the compression technique for voice payloads and headers, and may be able to vary the packet size.


at No comments:

Wednesday, December 17

Welcome to the World: Cisco Versus Microsoft

Welcome to the World: Cisco Versus Microsoft

Cisco and Avaya, two major VoIP system providers (among other things) are criticizing Lync Server 2010/2013. And not just for missing one thing – it’s an outright attack.
They’re saying Lync is not suitable for full-time use. Microsoft doesn’t supply all the infrastructure elements needed to run it, causing too much complexity and producing an unreliable product.
 I think “feeling the heat” is apt – because it sounds like Cisco and Avaya are suffering from a serious case of sour grapes.
I’m a bit late to the party here – the smear campaign began in late February – but examination of these criticisms is still fair game. Let’s go through the issues Cisco and Avaya are jabbing at Lync with.

The Strategy: Tear Down Instead of Innovate

The attack takes the form of an online campaign + a white paper from Cisco, with Avaya chiming in. They’re attacking several points about Lync Server, from voice & video reliability to total deployment cost.
The white paper is even in tone. But it’s definitely more of a push against Microsoft’s Lync than neutral advisory on Unified Communications.
The entire issue with this campaign is: They’re attacking competition, instead of examining your own product for improvements you can make.
When was the last time we heard of Cisco innovating? I don’t know of anything really impressive lately.
This is an old, old tactic. And one that has a terrible track record. Yet it’s pulled out almost every time companies want a competitor to go away.
Now Avaya, I kind of like their VoIP. They have a good-quality product. We actually haven’t replaced many Avaya systems with Lync yet…their customers like what they have. Great. No problem here.
So I don’t quite understand why Avaya’s jumping on Cisco’s bandwagon. If your product IS solid and well-supported, then it’s just a competition in the marketplace. Something we ALL have to do.

“Limitations” of Lync, and Why The Objections are Hollow

Let me address a few of the points Cisco and Avaya make in their campaign. From one perspective, they might be considered negatives.
Of course, they might be applied to Cisco and Avaya too. Or maybe they’re just options made available to customers. We’ll see.
Cisco (from the article): “Microsoft doesn’t provide phones, video endpoints, voice and video gateways, networking and cloud PSTN connections – leaving customers to find them elsewhere, increasing cost and complexity to implement, manage and troubleshoot Lync installations.”
Maybe this is intentional? Microsoft doesn’t try to take on all of that, leaving the choice up to service partners and clients? They get to choose which providers for things like SIP and cloud hosting, maybe saving money in the process?
(Full disclosure: PlanetMagpie is one of those service partners. We make several provider options available to Lync Server clients. We tested all of them ourselves, so we could recommend appropriate providers to the right size companies. This way smaller firms only pay for the bandwidth they need.)
Cisco (from the white paper): In attacking what it sees as Microsoft’s strategy for Skype, Cisco says that Skype will evolve to run better on Microsoft’s own software than on others. They point to a statement from Steve Ballmer: “We always want Skype to be first and best on Windows.”
One could easily interpret this line to also mean that they want Skype to remain in its dominant position for Windows voice communications. The position it gained over years of great functionality, on its own before the acquisition. Maybe Microsoft just wants to keep that ball rolling? Who wouldn’t?
Avaya (from the article): “[Avaya] questions whether Lync is resilient enough to provide 99.999% uptime for telephony services, long the industry standard among telecom carriers, says Vincenzo Signore, vice president of marketing.”
This is a dodge. The Lync Server software IS perfectly capable of 99.999% uptime. However, because Lync’s setup brings in other elements such as networking and gateways, Lync cannot be expected to muscle each of these into 99.999% uptime all day every day. It’s perfectly reasonable to want full uptime from VoIP hardware – and we take every step in deployment to assure it.
But let’s face it. Glitches happen. A line goes down now & then. This happens in ALL voice & video networking…even Cisco’s and Avaya’s.

What’s this attack really about? Market Share, and they’re losing it

My impression of Cisco and Avaya’s campaign? They’re scared, and they’re trying to discredit Lync before it eats into more of their market share. Lync is doing great–but rather than improve their own products to continue competition, they’re resorting to attack ads and mudslinging.
Problem is, when you sling mud, a lot of it ends up on you too.
Is Lync Server perfect? No. It’s still a younger piece of software, bound to have a few kinks and support issues. That’s okay. It gives us a HUGE assortment of communications tools in exchange.
I’ll end this post by paraphrasing a military saying: “If you’re catching flak, you’re over the target.”
Looks like Lync Server is definitely over the target!

google-site-verification: google37d0dc02207629cd.html
at 2 comments:

CUSP Configuration Example

Configure

This section describes the configuration of four call routing scenarios.

Scenario 1

Call Flow: IP Phone 1 -- CME -- SIP -- CUSP -- SIP -- CUCM -- IP Phone 2
Dial 408 202 2102 from IP Phone 1 registered to CallManager Express (CME) in order to reach IP Phone 2 registered to Cisco Unified Communications Manager (CUCM) via CUSP.
CME acts as a Public Switched Telephone Network (PSTN) in this scenario.The SIP INVITE comes to CUSP from CME.
             
             CLI
             trigger post-normalization sequence 1 policy 
             UC520-Four-to-Full condition TC-UC520-to-PSTN 

  1. GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 util.Normalization - 
Entering Normalization(moduleRequest:post-normalize)
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 conditions.RegexCondition - 
inNetwork='Net-PSTN'
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 conditions.RegexCondition - 
IN_NETWORK: Net-PSTN
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 conditions.AbstractRegexCondition -
pattern(^\QNet-From-UC520\E$), toMatch(Net-PSTN) returning false
[REQUESTI.12] INFO  2013.02.27 19:15:59:254 util.Normalization -
skipping post-normalize, due to either no trigger is configured or triggers 
did not evaluate to true or is configured to by-pass
  2. The Server Group configuration is checked in order to find the element IP address, and the call is routed to the best route possible based on the Q-value and Weight configuration.

    CLI
    !
server-group sip group SG-CUCM.ajeet.com Net-CUCM 
 element ip-address 14.128.64.191 5060 udp q-value 1 weight 50 
 element ip-address 14.128.64.192 5060 udp q-value 1.0 weight 100 
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.12] INFO  2013.02.27 19:15:59:254 loadbalancer.LBFactory - 
lbtype is 0(global)
[REQUESTI.12] INFO  2013.02.27 19:15:59:254 loadbalancer.LBFactory - 
Default lbtype is 3(call-id)
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 loadbalancer.LBBase - 
Entering getServer()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 loadbalancer.LBBase - 
Entering initializeDomains()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 servergroups.
ServerGlobalStateWrapper - Net-CUCM:14.128.64.191:5060:1 
numTries=2--->isServerAvailable(): true
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:254 servergroups.
ServerGlobalStateWrapper - Net-CUCM:14.128.64.192:5060:1 
numTries=2--->isServerAvailable(): true
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 servergroups.AbstractNextHop -
Entering compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 servergroups.AbstractNextHop -
Leaving compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 loadbalancer.LBBase - 
Leaving initializeDomains()
[REQUESTI.12] INFO  2013.02.27 19:15:59:255 loadbalancer.LBHashBased - 
list of elements in order on which load balancing is done : 
{reSgElementWeight=50, reSgElementSgName=SG-CUCM.ajeet.com, 
reSgElementTransport=UDP, reSgElementQValue=1.0, reSgElementPort=5060, 
reSgElementHost=14.128.64.191}, {reSgElementWeight=100, reSgElementSgName=
SG-CUCM.ajeet.com, reSgElementTransport=UDP, reSgElementQValue=1.0, 
reSgElementPort=5060, reSgElementHost=14.128.64.192},
 [REQUESTI.12] INFO  2013.02.27 19:15:59:255 loadbalancer.LBHashBased - 
Hashing on F3E5F396-804811E2-9818EC62-1B7185EE@14.128.100.150
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 loadbalancer.DsHashAlgorithm - 
Entering selectIndex()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 loadbalancer.DsHashAlgorithm - 
Leaving selectIndex()
[REQUESTI.12] INFO  2013.02.27 19:15:59:255 loadbalancer.LBHashBased - 
Index selected 0
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 servergroups.AbstractNextHop - 
Entering compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 servergroups.AbstractNextHop - 
Leaving compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 loadbalancer.LBBase - 
Server group SG-CUCM.ajeet.com selected {reSgElementWeight=50, 
reSgElementSgName=SG-CUCM.ajeet.com, reSgElementTransport=UDP, 
reSgElementQValue=1.0, reSgElementPort=5060, reSgElementHost=14.128.64.191}
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:255 loadbalancer.LBBase - 
Leaving getServer()
  3. The Route Table (RT-CUCM) configuration is checked in order to find the Target Destination (SG-CUCM.ajeet.com).

    CLI
    !
route table RT-CUCM 
 key 1111 target-destination SG-CUCM.ajeet.com Net-CUCM
 end route table
!

    GUI




    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 routingtables.RoutingTable - 
Entering lookup()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 routingtables.RoutingTable - 
Looking up 1111 in table RT-CUCM with rule exact and modifiers=none
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 routingtables.RoutingTable - 
Entering applyModifiers()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 routingtables.RoutingTable - 
Leaving applyModifiers(), returning 1111
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 routingtables.RoutingTable - 
Leaving lookup()
[REQUESTI.12] INFO  2013.02.27 19:15:59:252 nrs.XCLPrefix - 
NRS Routing decision is: RouteTable:RT-CUCM, RouteKey:1111, 
TargetDestination:SG-CUCM.ajeet.com, Network:Net-CUCM
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.12] INFO  2013.02.27 19:15:59:252 loadbalancer.LBFactory - 
lbtype is 3(call-id)
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 nrs.XCLPrefix - 
Stored NRSAlgResult=isFound=true, isFailure=false, Response=-1, 
Routes=[Ruri: SG-CUCM.ajeet.com, Route: null, Network: Net-CUCM, 
q-value=1.0radvance=[502, 503]], PolicyAdvance=null
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 nrs.NRSAlgResult -
set policyAdvance as specified in route=RouteTable:RT-CUCM, RouteKey:1111, 
TargetDestination:SG-CUCM.ajeet.com, Network:Net-CUCM
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 nrs.NRSAlgResult - 
no policyAdvance specified in route
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:253 nrs.NRSAlgResult - 
set policyAdvance as specified in algorithm={lookupkeymodifier=
[ RegexModifier: match= 4082022102, replace= 1111, ignore case= false], 
lookuprule=0, lookupfield=45, lookuplenght=-1, lookuptable=RT-CUCM, 
sequence=100, algorithm=1}
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:253 nrs.NRSAlgResult - 
no policyAdvance specified in algorithm
  4. The Route Policy (Policy-to-CUCM) configuration is checked in order to find the Route Table (RT-CUCM) that matches.

    CLI
    !
policy lookup Policy-to-CUCM
 sequence 100 RT-CUCM request-uri uri-component user
  modify-key 4082022102 1111
  rule exact
  end sequence
 end policy
!

    GUI




    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.XCLPrefix - 
Entering getKeyValue()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector - 
getUriPart: URI - sip:4082022102@14.128.100.169:5060 part 6
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector - 
Requested field 45
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector -
 Returning key 4082022102
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector -
 Retrieved Modifier  RegexModifier: match= 4082022102, replace= 
1111, ignore case= false
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector - 
Input field: 4082022102
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 nrs.FieldSelector -
 Modified field: 1111
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 nrs.XCLPrefix - 
Leaving getKeyValue()
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:252 modules.XCLLookup -
 table=RT-CUCM, key=1111
[REQUESTI.12] INFO  2013.02.27 19:15:59:252 modules.XCLLookup -
 table is RT-CUCM
  5. The Routing Trigger configuration is checked in order to find the Route Policy (Policy-to-CUCM) that matches based on the Trigger Condition (TC-from-PSTN).

    CLI
    trigger routing sequence 1 policy Policy-to-CUCM condition TC-from-PSTN

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<Policy-to-CUCM> actionParameter<>
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:251 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
  6. The Trigger Condition (TC-from-PSTN) is matched.

    CLI
    !
trigger condition TC-from-PSTN
 sequence 1 
  in-network ^\QNet-PSTN\E$
  end sequence
 end trigger condition
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.RegexCondition - 
inNetwork='Net-PSTN'
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.RegexCondition - 
IN_NETWORK: Net-PSTN
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.AbstractRegexCondition -
pattern(^\QNet-PSTN\E$), toMatch(Net-PSTN) returning true
  7. The call is accepted to the network (Net-PSTN) configuration that matches.

    CLI
    sip listen Net-PSTN udp 14.128.100.169 5060

 !
sip network Net-PSTN standard
  no non-invite-provisional
 allow-connections
 retransmit-count invite-client-transaction 3
  retransmit-count invite-server-transaction 5
 retransmit-count non-invite-client-transaction 3
  retransmit-timer T1 500
  retransmit-timer T2 4000
  retransmit-timer T4 5000
  retransmit-timer TU1 5000
  retransmit-timer TU2 32000
  retransmit-timer clientTn 64000
  retransmit-timer serverTn 64000
  tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 
conditions.RegexCondition - inNetwork='Net-PSTN'
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 
conditions.RegexCondition - IN_NETWORK: Net-PSTN 
  8. [DsTransportListener-2] DEBUG 2013.02.27 19:15:59:245 DsSipLlApi.Wire - 
Received UDP packet on 14.128.100.169:5060 ,source 14.128.100.150:57878
INVITE sip:4082022102@14.128.100.169:5060 SIP/2.0
Via: SIP/2.0/UDP 14.128.100.150:5060;branch=z9hG4bK21F2555
Remote-Party-ID: "4082025555" <sip:4082025555@14.128.100.150>;
party=calling;screen=yes;privacy=off
From: "4082025555" <sip:4082025555@14.128.100.150>;tag=81D7430C-1D2
To: <sip:4082022102@14.128.100.169>
Date: Wed, 27 Feb 2013 19:15:59 GMT
Call-ID: F3E5F396-804811E2-9818EC62-1B7185EE@14.128.100.150
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 4091813662-2152206818-2551376994-0460424686
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1361992559
Contact: <sip:4082025555@14.128.100.150:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 410

v=0
o=CiscoSystemsSIP-GW-UserAgent 1007 629 IN IP4 14.128.100.150
s=SIP Call
c=IN IP4 14.128.100.150
t=0 0
m=audio 16930 RTP/AVP 18 101
c=IN IP4 14.128.100.150
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
m=video 17954 RTP/AVP 97
c=IN IP4 14.128.100.150
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0

--- end of packet ---
  9. The Pre-Normalization sequence is executed.

    CLI
    trigger pre-normalization sequence 1 policy CUCM-Prefix-408
condition TC-from-CUCM
    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 util.Normalization - 
Entering Normalization(moduleRequest:pre-normalize)
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.RegexCondition - 
inNetwork='Net-PSTN'
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.RegexCondition - 
IN_NETWORK: Net-PSTN
[REQUESTI.12] DEBUG 2013.02.27 19:15:59:250 conditions.AbstractRegexCondition -
pattern(^\QNet-CUCM\E$), toMatch(Net-PSTN) returning false
[REQUESTI.12] INFO  2013.02.27 19:15:59:250 util.Normalization - 
skipping pre-normalize, due to either no trigger is configured or triggers 
did not evaluate to true or is configured to by-pass
  10. The SIP INVITE is sent to the selected element.
    [REQUESTI.12] DEBUG 2013.02.27 19:15:59:256 DsSipLlApi.Wire - 
Sending UDP packet on 14.128.100.169:32771, destination 14.128.64.191:5060
INVITE sip:4082022102@SG-CUCM.ajeet.com SIP/2.0
Via: SIP/2.0/UDP 14.128.100.169:5061;branch=z9hG4bK.ToYJFeKMyfZGySv.gcLjg~~231
Via: SIP/2.0/UDP 14.128.100.150:5060;branch=z9hG4bK21F2555
Max-Forwards: 68
To: <sip:4082022102@14.128.100.169>
From: "4082025555" <sip:4082025555@14.128.100.150>;tag=81D7430C-1D2
Contact: <sip:4082025555@14.128.100.150:5060>
Expires: 180
Remote-Party-ID: "4082025555" <sip:4082025555@14.128.100.150
>;party=calling;screen=yes;privacy=off
Call-ID: F3E5F396-804811E2-9818EC62-1B7185EE@14.128.100.150
CSeq: 101 INVITE
Content-Length: 410
Date: Wed, 27 Feb 2013 19:15:59 GMT
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4091813662-2152206818-2551376994-0460424686
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
 SUBSCRIBE, NOTIFY, INFO, REGISTER
Timestamp: 1361992559
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 1007 629 IN IP4 14.128.100.150
s=SIP Call
c=IN IP4 14.128.100.150
t=0 0
m=audio 16930 RTP/AVP 18 101
c=IN IP4 14.128.100.150
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
m=video 17954 RTP/AVP 97
c=IN IP4 14.128.100.150
b=TIAS:1000000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E;packetization-mode=0

  11.  Enterprise Parameter > Clusterwide Domain Configuration > Cluster Fully Qualified Domain Name should be the same as the server group name.

Scenario 2

Call Flow: IP Phone 1 -- CUCM -- SIP -- CUSP -- SIP -- CME -- IP Phone 2
Dial 202 2222 from IP Phone 2. 408 should be prefixed with Pre-Normalization in order to reach IP Phone 1.
CME acts as PSTN in this scenario.
  1. The call is accepted on the network (Net-CUCM) configuration that matches.

    CLI
    sip listen Net-CUCM udp 14.128.100.169 5061 

!
sip network Net-CUCM standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3 
 retransmit-count invite-server-transaction 5 
 retransmit-count non-invite-client-transaction 3 
 retransmit-timer T1 500 
 retransmit-timer T2 4000 
 retransmit-timer T4 5000 
 retransmit-timer TU1 5000 
 retransmit-timer TU2 32000 
 retransmit-timer clientTn 64000 
 retransmit-timer serverTn 64000 
 tcp connection-setup-timeout 1000 
 udp max-datagram-size 1500 
 end network
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:373 conditions.RegexCondition - 
inNetwork='Net-CUCM'
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:373 conditions.RegexCondition - 
IN_NETWORK: Net-CUCM
  2. The Route Table (RT-PSTN) configuration is checked in order to find the Target Destination (SG-PSTN).

    CLI
    !
route table RT-PSTN 
 key 4082022222 target-destination SG-PSTN Net-PSTN
 end route table
!

    GUI




    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 routingtables.RoutingTable -
Entering lookup()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 routingtables.RoutingTable - 
Looking up 4082022222 in table RT-PSTN with rule exact and modifiers=none
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 routingtables.RoutingTable - 
Entering applyModifiers()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 routingtables.RoutingTable - 
Leaving applyModifiers(), returning 4082022222
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 routingtables.RoutingTable - 
Leaving lookup()
[REQUESTI.12] INFO  2013.02.28 00:34:03:376 nrs.XCLPrefix - 
NRS Routing decision is: RouteTable:RT-PSTN, RouteKey:4082022222, 
TargetDestination:SG-PSTN, Network:Net-PSTN
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.12] INFO  2013.02.28 00:34:03:376 loadbalancer.LBFactory - 
lbtype is 3(call-id)
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 nrs.XCLPrefix - 
Stored NRSAlgResult=isFound=true, isFailure=false, Response=-1, 
Routes=[Ruri: SG-PSTN, Route: null, Network: Net-PSTN, q-value=1.
0radvance=[502, 503]], PolicyAdvance=null
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 nrs.NRSAlgResult - 
set policyAdvance as specified in route=RouteTable:RT-PSTN, RouteKey:4082022222,
TargetDestination:SG-PSTN, Network:Net-PSTN
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 nrs.NRSAlgResult - 
no policyAdvance specified in route
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 nrs.NRSAlgResult - 
set policyAdvance as specified in algorithm={lookuprule=0, lookupfield=45, 
lookuplenght=-1, lookuptable=RT-PSTN, sequence=100, algorithm=1}
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:376 nrs.NRSAlgResult - 
no policyAdvance specified in algorithm
  3. The Post-Normalization Sequence is executed.

    CLI
    trigger post-normalization sequence 1 policy UC520-Four-to-Full 
condition TC-UC520-to-PSTN 
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 util.Normalization - 
Entering Normalization(moduleRequest:post-normalize)
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 conditions.RegexCondition - 
inNetwork='Net-CUCM'
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 conditions.RegexCondition - 
IN_NETWORK: Net-CUCM
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 conditions.AbstractRegexCondition - 
pattern(^\QNet-From-UC520\E$), toMatch(Net-CUCM) returning false
[REQUESTI.12] INFO  2013.02.28 00:34:03:378 util.Normalization - 
skipping post-normalize, due to either no trigger is configured or triggers 
did not evaluate to true or is configured to by-pass
  4. The Route Policy (Policy-to-PSTN) configuration is checked in order to find the Route Table (RT-PSTN) that matches.

    CLI
    !
policy lookup Policy-to-PSTN
 sequence 100 RT-PSTN request-uri uri-component user
  rule exact
  end sequence
 end policy
!

    GUI




    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 nrs.XCLPrefix - 
Entering getKeyValue()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 nrs.FieldSelector - 
getUriPart: URI - sip:4082022222@14.128.100.169:5061 part 6
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 nrs.FieldSelector - 
Requested field 45
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 nrs.FieldSelector - 
Returning key 4082022222
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 nrs.XCLPrefix - 
Leaving getKeyValue()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 modules.XCLLookup - 
table=RT-PSTN, key=4082022222
[REQUESTI.12] INFO  2013.02.28 00:34:03:376 modules.XCLLookup - 
table is RT-PSTN
  5. The Routing Trigger configuration is checked in order to discover the Route Policy (Policy-to-PSTN) that matches based on the Trigger Condition (TC-from-CUCM).

    CLI
    trigger routing sequence 2 policy Policy-to-PSTN condition TC-from-CUCM

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.RegexCondition - 
inNetwork='Net-CUCM'
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.RegexCondition - 
IN_NETWORK: Net-CUCM
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.AbstractRegexCondition -
pattern(^\QNet-CUCM\E$), toMatch(Net-CUCM) returning true
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<Policy-to-PSTN> actionParameter<>
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:375 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
  6. The Trigger Condition (TC-from-CUCM) is matched.

    CLI
    !
trigger condition TC-from-CUCM
 sequence 1 
  in-network ^\QNet-CUCM\E$
  end sequence
 end trigger condition
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.RegexCondition - 
inNetwork='Net-CUCM'
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.RegexCondition - 
IN_NETWORK: Net-CUCM
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.AbstractRegexCondition - 
pattern(^\QNet-CUCM\E$), toMatch(Net-CUCM) returning true
  7. The Pre-Normalization sequence is executed.

    CLI
    trigger pre-normalization sequence 1 policy CUCM-Prefix-408 
condition TC-from-CUCM 

    !
policy normalization CUCM-Prefix-408
 uri-component update request-uri user 2022222 4082022222
 end policy
!

    GUI




    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:373 util.Normalization - 
Entering Normalization(moduleRequest:pre-normalize
)[REQUESTI.12] DEBUG 2013.02.28 00:34:03:373 conditions.RegexCondition - 
inNetwork='Net-CUCM'
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:373 conditions.RegexCondition - 
IN_NETWORK: Net-CUCM
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 conditions.AbstractRegexCondition - 
pattern(^\QNet-CUCM\E$), toMatch(Net-CUCM) returning true
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<CUCM-Prefix-408> actionParameter<>
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 normalization.
URIComponentNormalizationAlgorithm - normalizing request-uri
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 normalization.
URIComponentNormalizationAlgorithm - 
updating user/phone of the sip:2022222@14.128.100.169:5061 to 4082022222
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:374 util.Normalization -
 Leaving Normalization.normalize()
  8. The SIP INVITE comes to CUSP from CUCM.
    [DsTransportListener-0] DEBUG 2013.02.28 00:34:03:370 DsSipLlApi.Wire - 
Received UDP packet on 14.128.100.169:5061 ,source 14.128.64.192:5060
INVITE sip:2022222@14.128.100.169:5061 SIP/2.0
Via: SIP/2.0/UDP 14.128.64.192:5060;branch=z9hG4bK18012ae333f
From: "SJ Phone 1" <sip:2001@14.128.64.192>;
tag=534264~c1b77ee1-4af9-4a41-aed3-3846cd699427-49616146
To: <sip:2022222@14.128.100.169>
Date: Thu, 28 Feb 2013 00:34:03 GMT
Call-ID: 8be55500-12e1a5fb-ab-c040800e@14.128.64.192
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE,
 REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:14.128.64.192:5060>
;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 2347062528-0000065536-0000000107-3225452558
Session-Expires:  1800
P-Asserted-Identity: "SJ Phone 1" <sip:2001@14.128.64.192>
Remote-Party-ID: "SJ Phone 1" <sip:2001@14.128.64.192>
;party=calling;screen=yes;privacy=off
Contact: <sip:2001@14.128.64.192:5060>
Max-Forwards: 70
Content-Length: 0

--- end of packet ---
  9. The Server Group (SG-PSTN) configuration is checked in order to find the element IP address, and the call is routed to the best route possible based on the Q-value and Weight configuration.

    CLI
    !
server-group sip group SG-PSTN Net-PSTN 
 element ip-address 14.128.100.150 5060 udp q-value 1.0 weight 0 
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

    GUI


    DEBUG
    [REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.12] INFO  2013.02.28 00:34:03:378 loadbalancer.LBFactory - 
lbtype is 0(global)
[REQUESTI.12] INFO  2013.02.28 00:34:03:378 loadbalancer.LBFactory - 
Default lbtype is 3(call-id)
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 loadbalancer.LBBase - 
Entering getServer()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 loadbalancer.LBBase - 
Entering initializeDomains()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 servergroups.
ServerGlobalStateWrapper - Net-PSTN:14.128.100.150:5060:1 numTries=
2--->isServerAvailable(): true
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 loadbalancer.LBBase - 
Leaving initializeDomains()
[REQUESTI.12] INFO  2013.02.28 00:34:03:378 loadbalancer.LBHashBased - 
list of elements in order on which load balancing is done : 
{reSgElementWeight=0, reSgElementSgName=SG-PSTN, reSgElementTransport=UDP, 
reSgElementQValue=1.0, reSgElementPort=5060, reSgElementHost=14.128.100.150}
, [REQUESTI.12] DEBUG 2013.02.28 00:34:03:378 servergroups.AbstractNextHop - 
Entering compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:379 servergroups.AbstractNextHop - 
Leaving compareDomainNames()
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:379 loadbalancer.LBBase - 
Server group SG-PSTN selected {reSgElementWeight=0, reSgElementSgName=SG-PSTN, 
reSgElementTransport=UDP, reSgElementQValue=1.0, reSgElementPort=5060, 
reSgElementHost=14.128.100.150}
[REQUESTI.12] DEBUG 2013.02.28 00:34:03:379 loadbalancer.LBBase - 
Leaving getServer()
  10. The SIP INVITE is sent to the selected element.
    [CT_CALLBACK.13] DEBUG 2013.02.28 00:34:06:260 DsSipLlApi.Wire - 
Sending UDP packet on 14.128.100.169:32772, destination 14.128.64.192:
5060SIP/2.0 200 OK
Via: SIP/2.0/UDP 14.128.64.192:5060;branch=z9hG4bK18012ae333f
To: <sip:2022222@14.128.100.169>;tag=82FA7450-F53
From: "SJ Phone 1" <sip:2001@14.128.64.192>
;tag=534264~c1b77ee1-4af9-4a41-aed3-3846cd699427-49616146
Contact: <sip:4082022222@14.128.100.150:5060>
Require: timer
Remote-Party-ID: <sip:4082022222@14.128.100.150>
;party=called;screen=no;privacy=off
Call-ID: 8be55500-12e1a5fb-ab-c040800e@14.128.64.192
CSeq: 101 INVITE
Content-Length: 276
Date: Thu, 28 Feb 2013 00:34:03 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 
SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Supported: replaces
Supported: sdp-anat
Supported: timer
Server: Cisco-SIPGateway/IOS-12.x
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 6810 2753 IN IP4 14.128.100.150
s=SIP Call
c=IN IP4 14.128.100.150
t=0 0
m=audio 16862 RTP/AVP 18 101
c=IN IP4 14.128.100.150
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Scenario 3

Call Flow: IP Phone 1 -- CME 1 -- SIP -- CUSP -- SIP --  CME 2 -- IP Phone 2
Dial 4001 or 4002 from IP Phone 1 in order to reach extensions on IP Phone 2.
CME 2 is UC520 in this scenario and CME 1 acts as PSTN.
  1. The SIP INVITE comes to CUSP from CME 1 (PSTN).
    [DsTransportListener-3] DEBUG 2013.02.28 05:28:57:360 DsSipLlApi.Wire - 
Received UDP packet on 14.128.100.169:5062 ,source 14.128.100.150:56578
INVITE sip:4002@14.128.100.169:5062 SIP/2.0
Via: SIP/2.0/UDP 14.128.100.150:5060;branch=z9hG4bK2292567
Remote-Party-ID: <sip:85224044444@14.128.100.150>
;party=calling;screen=no;privacy=off
From: <sip:85224044444@14.128.100.150>;tag=84086F7C-10B8
To: <sip:4002@14.128.100.169>
Date: Thu, 28 Feb 2013 05:28:57 GMT
Call-ID: 9559E957-809E11E2-9856EC62-1B7185EE@14.128.100.150
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2446255913-2157842914-2555505762-0460424686
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
 SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1362029337
Contact: <sip:85224044444@14.128.100.150:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 276

v=0
o=CiscoSystemsSIP-GW-UserAgent 3653 4016 IN IP4 14.128.100.150
s=SIP Call
c=IN IP4 14.128.100.150
t=0 0
m=audio 19202 RTP/AVP 18 101
c=IN IP4 14.128.100.150
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

--- end of packet ---
  2. The call is accepted on the network (Net-UC520) configuration that matches.

    CLI
    sip listen Net-UC520 udp 14.128.100.169 5062

 !
sip network Net-From-UC520 standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3 
 retransmit-count invite-server-transaction 5 
 retransmit-count non-invite-client-transaction 3
  retransmit-timer T1 500
  retransmit-timer T2 4000
  retransmit-timer T4 5000
  retransmit-timer TU1 5000
  retransmit-timer TU2 32000
  retransmit-timer clientTn 64000
  retransmit-timer serverTn 64000
  tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
!

    GUI


    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 conditions.RegexCondition - 
inNetwork='Net-UC520'
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 conditions.RegexCondition - 
IN_NETWORK: Net-UC520
  3. The Pre-Normalization sequence is executed.

    CLI
    trigger pre-normalization sequence 1 policy CUCM-Prefix-408 condition 
TC-from-CUCM
    GUI


    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 util.Normalization -
Entering Normalization(moduleRequest:pre-normalize)
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 conditions.RegexCondition - 
inNetwork='Net-UC520'
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 conditions.RegexCondition - 
IN_NETWORK: Net-UC520
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:362 conditions.AbstractRegexCondition - 
pattern(^\QNet-CUCM\E$), toMatch(Net-UC520) returning false
[REQUESTI.10] INFO  2013.02.28 05:28:57:362 util.Normalization - 
skipping pre-normalize, due to either no trigger is configured or triggers 
did not evaluate to true or is configured to by-pass
  4. The Trigger Condition (TC-PSTN-to-UC520) is matched.

    CLI
    !
trigger condition TC-PSTN-to-UC520
 sequence 1 
  in-network ^\QNet-UC520\E$
  end sequence
 end trigger condition
!

    GUI


    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 conditions.RegexCondition - 
inNetwork='Net-UC520'
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 conditions.RegexCondition - 
IN_NETWORK: Net-UC520
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 conditions.AbstractRegexCondition -
pattern(^\QNet-UC520\E$), toMatch(Net-UC520) returning true
  5. The Routing Trigger configuration is checked in order to find the Route Policy (Policy-UC520) that matches based on the Trigger Condition (TC-PSTN-to-UC520).

    CLI
    trigger routing sequence 3 policy Policy-UC520 condition TC-PSTN-to-UC520
    GUI


    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<Policy-UC520> actionParameter<>
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
  6. The Route Policy (Policy-UC520) configuration is checked in order to find the Route Table (RT-UC520) that matches.

    CLI
    !
policy lookup Policy-UC520
 sequence 100 RT-UC520 request-uri uri-component user
  modify-key 400[12] 2222
  rule exact
  end sequence
 end policy
!

    GUI




    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.XCLPrefix - 
Entering getKeyValue()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
getUriPart: URI - sip:4002@14.128.100.169:5062 part 6
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
Requested field 45
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
Returning key 4002
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
Retrieved Modifier  RegexModifier: match= 400[12], replace= 2222, 
ignore case= false
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
Input field: 4002
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.FieldSelector - 
Modified field: 2222
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 nrs.XCLPrefix - 
Leaving getKeyValue()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:363 modules.XCLLookup - 
table=RT-UC520, key=2222
[REQUESTI.10] INFO  2013.02.28 05:28:57:364 modules.XCLLookup - 
table is RT-UC520
  7. The Route Table (RT-UC520) configuration is checked in order to find the Target Destination (RG-UC520).

    CLI
    !
route table RT-UC520 
 key 2222 group RG-UC520
 end route table
!
    GUI




    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 routingtables.RoutingTable - 
Entering lookup()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 routingtables.RoutingTable - 
Looking up 2222 in table RT-UC520 with rule exact and modifiers=none
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 routingtables.RoutingTable - 
Entering applyModifiers()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 routingtables.RoutingTable - 
Leaving applyModifiers(), returning 2222
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 routingtables.RoutingTable - 
Leaving lookup()
[REQUESTI.10] INFO  2013.02.28 05:28:57:364 nrs.XCLPrefix - 
NRS Routing decision is: RouteTable:RT-UC520, RouteKey:2222, RouteGroup:RG-UC520
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.10] INFO  2013.02.28 05:28:57:364 loadbalancer.LBFactory - 
lbtype is 3(call-id)
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 nrs.XCLPrefix - 
Stored NRSAlgResult=isFound=true, isFailure=false, Response=-1, 
Routes=[Ruri: SG-UC520, Route: null, Network: Net-UC520, q-value=1.
0radvance=[502, 503]], PolicyAdvance=null
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 nrs.NRSAlgResult - 
set policyAdvance as specified in route=RouteTable:RT-UC520, RouteKey:2222, 
RouteGroup:RG-UC520
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 nrs.NRSAlgResult - 
no policyAdvance specified in route
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 nrs.NRSAlgResult - 
set policyAdvance as specified in algorithm={lookupkeymodifier=
[ RegexModifier: match= 400[12], replace= 2222, ignore case= false], 
lookuprule=0, lookupfield=45, lookuplenght=-1, lookuptable=RT-UC520, 
sequence=100, algorithm=1}
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:364 nrs.NRSAlgResult - 
no policyAdvance specified in algorithm
  8. The Post-Normalization Sequence is executed.

    CLI
    trigger post-normalization sequence 1 policy UC520-Four-to-Full 
condition TC-UC520-to-PSTN
    GUI


    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 util.Normalization - 
Entering Normalization(moduleRequest:post-normalize)
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 conditions.RegexCondition - 
inNetwork='Net-UC520'
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 conditions.RegexCondition - 
IN_NETWORK: Net-UC520
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 conditions.AbstractRegexCondition - 
pattern(^\QNet-From-UC520\E$), toMatch(Net-UC520) returning false
[REQUESTI.10] INFO  2013.02.28 05:28:57:365 util.Normalization - 
skipping post-normalize, due to either no trigger is configured or 
triggers did not evaluate to true or is configured to by-pass
  9. The Route Group configuration is checked in order to find the element IP address, and the call is routed to the best route possible based on the Q-value and Weight setting.

    CLI
    !
route group RG-UC520 
 element target-destination SG-UC520 Net-UC520 q-value 1.0 
  failover-codes 502 - 503 
  weight 0 
  end element
 end route
!

    !
server-group sip group SG-UC520 Net-UC520 
 element ip-address 14.128.100.161 5060 udp q-value 1.0 weight 0 
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

    GUI






    DEBUG
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.10] INFO  2013.02.28 05:28:57:365 loadbalancer.LBFactory - 
lbtype is 0(global)
[REQUESTI.10] INFO  2013.02.28 05:28:57:365 loadbalancer.LBFactory - 
Default lbtype is 3(call-id)
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 loadbalancer.LBBase - 
Entering getServer()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 loadbalancer.LBBase - 
Entering initializeDomains()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:365 servergroups.
ServerGlobalStateWrapper - Net-UC520:14.128.100.161:5060:1 numTries=
2--->isServerAvailable(): true
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:366 loadbalancer.LBBase - 
Leaving initializeDomains()
[REQUESTI.10] INFO  2013.02.28 05:28:57:366 loadbalancer.LBHashBased - 
list of elements in order on which load balancing is done : 
{reSgElementWeight=0, reSgElementSgName=SG-UC520, reSgElementTransport=UDP, 
reSgElementQValue=1.0, reSgElementPort=5060, reSgElementHost=14.128.100.161},
 [REQUESTI.10] DEBUG 2013.02.28 05:28:57:366 servergroups.AbstractNextHop - 
Entering compareDomainNames()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:366 servergroups.AbstractNextHop - 
Leaving compareDomainNames()
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:366 loadbalancer.LBBase - 
Server group SG-UC520 selected {reSgElementWeight=0, reSgElementSgName=SG-UC520, 
reSgElementTransport=UDP, reSgElementQValue=1.0, reSgElementPort=5060,
reSgElementHost=14.128.100.161}
[REQUESTI.10] DEBUG 2013.02.28 05:28:57:366 loadbalancer.LBBase - 
Leaving getServer()
  10. The SIP INVITE is sent to the selected element.
    [REQUESTI.10] DEBUG 2013.02.28 05:28:57:367 DsSipLlApi.Wire - 
Sending UDP packet on 14.128.100.169:32773, destination 14.128.100.161:5060
INVITE sip:4002@SG-UC520 SIP/2.0
Via: SIP/2.0/UDP 
14.128.100.169:5062;branch=z9hG4bK.ToYJFeKMyfZGySv.gcLjg~~237
Via: SIP/2.0/UDP 14.128.100.150:5060;branch=z9hG4bK2292567
Max-Forwards: 69
To: <sip:4002@14.128.100.169>
From: <sip:85224044444@14.128.100.150>;tag=84086F7C-10B8
Contact: <sip:85224044444@14.128.100.150:5060>
Expires: 180
Remote-Party-ID: <sip:85224044444@14.128.100.150>
;party=calling;screen=no;privacy=off
Call-ID: 9559E957-809E11E2-9856EC62-1B7185EE@14.128.100.150
CSeq: 101 INVITE
Content-Length: 276
Date: Thu, 28 Feb 2013 05:28:57 GMT
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2446255913-2157842914-2555505762-0460424686
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
 SUBSCRIBE, NOTIFY, INFO, REGISTER
Timestamp: 1362029337
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 3653 4016 IN IP4 14.128.100.150
s=SIP Call
c=IN IP4 14.128.100.150
t=0 0
m=audio 19202 RTP/AVP 18 101
c=IN IP4 14.128.100.150
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Scenario 4

Call Flow:IP Phone 1 -- CME 1 -- SIP -- CUSP -- SIP -- CME 2 -- IP Phone 2
Dial 4444 from IP Phone 2 which is changed to 415 240 4444 with Post-Normalization in order to reach IP Phone 1.
CME 2 is UC520 in this scenario and CME 1 acts as PSTN.
  1. The SIP INVITE comes to CUSP from CME 2 (UC520).
    [DsTransportListener-1] DEBUG 2013.02.28 07:06:57:220 DsSipLlApi.Wire - 
Received UDP packet on 14.128.100.169:5063 ,source 14.128.100.161:59404
INVITE sip:4444@14.128.100.169:5063 SIP/2.0
Date: Thu, 28 Feb 2013 07:09:20 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, 
SUBSCRIBE, NOTIFY, INFO, REGISTER
From: <sip:4001@14.128.100.161>;tag=256D566C-22AC
Allow-Events: telephone-event
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Remote-Party-ID: <sip:4001@14.128.100.161>
;party=calling;screen=no;privacy=off
Cisco-Guid: 2598740490-2158760418-2150671243-2598404062
Timestamp: 1362035360
Content-Length: 543
User-Agent: Cisco-SIPGateway/IOS-12.x
To: <sip:4444@14.128.100.169>
Contact: <sip:4001@14.128.100.161:5060>
Expires: 180
Content-Type: multipart/mixed;boundary=uniqueBoundary
Call-ID: 9B62C157-80AC11E2-8035A38B-9AE07FDE@14.128.100.161
Via: SIP/2.0/UDP 14.128.100.161:5060;branch=z9hG4bK21E82
CSeq: 101 INVITE
Max-Forwards: 70
Mime-Version: 1.0

--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 3418 2914 IN IP4 14.128.100.161
s=SIP Call
c=IN IP4 14.128.100.161
t=0 0
m=audio 17618 RTP/AVP 18 101
c=IN IP4 14.128.100.161
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional

IAM,
GCI,9ae5a20a80ac11e28030a38b9ae07fde

--- end of packet ---
  2. The call is accepted on the network (Net-From-UC520) configuration that matches.

    CLI
    sip listen Net-From-UC520 udp 14.128.100.169 5063
 !
sip network Net-From-UC520 standard
  no non-invite-provisional
  allow-connections
 retransmit-count invite-client-transaction 3
  retransmit-count invite-server-transaction 5
  retransmit-count non-invite-client-transaction 3
  retransmit-timer T1 500 
 retransmit-timer T2 4000
  retransmit-timer T4 5000
  retransmit-timer TU1 5000
  retransmit-timer TU2 32000
  retransmit-timer clientTn 64000
  retransmit-timer serverTn 64000
  tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
!

    GUI


    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
inNetwork='Net-From-UC520'
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
IN_NETWORK: Net-From-UC520
  3. The Pre-Normalization sequence is executed.

    CLI
    trigger pre-normalization sequence 1 policy CUCM-Prefix-408 condition 
TC-from-CUCM
    GUI


    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 util.Normalization - 
Entering Normalization(moduleRequest:pre-normalize)
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
inNetwork='Net-From-UC520'
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
IN_NETWORK: Net-From-UC520
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.AbstractRegexCondition - 
pattern(^\QNet-CUCM\E$), toMatch(Net-From-UC520) returning false
[REQUESTI.5] INFO  2013.02.28 07:06:57:229 util.Normalization - 
skipping pre-normalize, due to either no trigger is configured or triggers 
did not evaluate to true or is configured to by-pass
  4. The Trigger Condition (TC-UC520-to-PSTN) is matched.

    CLI
    !
trigger condition TC-UC520-to-PSTN
 sequence 1
   in-network ^\QNet-From-UC520\E$
 end sequence
 end trigger condition
!

    GUI


    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
inNetwork='Net-From-UC520'
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:229 conditions.RegexCondition - 
IN_NETWORK: Net-From-UC520
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 conditions.AbstractRegexCondition - 
pattern(^\QNet-From-UC520\E$), toMatch(Net-From-UC520) returning true
  5. The Routing Trigger configuration is checked in order to find the Route Policy (Policy-UC520-to-PSTN) that matches based on the Trigger Condition (TC-UC520-to-PSTN).

    CLI
    trigger routing sequence 4 policy Policy-UC520-to-PSTN condition 
TC-UC520-to-PSTN
    GUI


    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<Policy-UC520-to-PSTN> actionParameter<>
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
  6. The Route Policy (Policy-UC520-to-PSTN) configuration is checked in order to find the Route Table (RT-UC520-PSTN) that matches.

    CLI
    !
policy lookup Policy-UC520-to-PSTN
 sequence 100 RT-UC520-PSTN request-uri uri-component user
  modify-key 4444 3333
  rule exact
  end sequence
 end policy
!

    GUI




    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.XCLPrefix - 
Entering getKeyValue()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
getUriPart: URI - sip:4444@14.128.100.169:5063 part 6
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
Requested field 45
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
Returning key 4444
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
Retrieved Modifier  RegexModifier: match= 4444, replace= 3333, 
ignore case= false
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
Input field: 4444
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.FieldSelector - 
Modified field: 3333
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 nrs.XCLPrefix - 
Leaving getKeyValue()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 modules.XCLLookup - 
table=RT-UC520-PSTN, key=3333
[REQUESTI.5] INFO  2013.02.28 07:06:57:230 modules.XCLLookup - 
table is RT-UC520-PSTN
  7. The Route Table (RT-UC520-PSTN) configuration is checked in order to find the Target Destination (RG-UC520).

    CLI
    !
route table RT-UC520-PSTN
  key 3333 group RG-UC520-to-PSTN
 end route table
!
    GUI




    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:230 routingtables.RoutingTable - 
Entering lookup()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 routingtables.RoutingTable - 
Looking up 3333 in table RT-UC520-PSTN with rule exact and modifiers=none
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 routingtables.RoutingTable - 
Entering applyModifiers()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 routingtables.RoutingTable - 
Leaving applyModifiers(), returning 3333
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 routingtables.RoutingTable - 
Leaving lookup()
[REQUESTI.5] INFO  2013.02.28 07:06:57:231 nrs.XCLPrefix - 
NRS Routing decision is: RouteTable:RT-UC520-PSTN, RouteKey:3333, 
RouteGroup:RG-UC520-to-PSTN
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 loadbalancer.LBFactory - 
Entering createLoadBalancer()
[REQUESTI.5] INFO  2013.02.28 07:06:57:231 loadbalancer.LBFactory - 
lbtype is 3(call-id)
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 loadbalancer.LBFactory - 
Leaving createLoadBalancer()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.XCLPrefix - 
Stored NRSAlgResult=isFound=true, isFailure=false, Response=-1, 
Routes=[Ruri: 14.128.100.150, Route: null, Network: Net-From-UC520, 
q-value=1.0radvance=[502, 503]], PolicyAdvance=null
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSAlgResult - 
set policyAdvance as specified in route=RouteTable:RT-UC520-PSTN, 
RouteKey:3333, RouteGroup:RG-UC520-to-PSTN
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSAlgResult - 
no policyAdvance specified in route
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSAlgResult - 
set policyAdvance as specified in algorithm={lookupkeymodifier=
[ RegexModifier: match= 4444, replace= 3333, ignore case= false], 
lookuprule=0, lookupfield=45, lookuplenght=-1, lookuptable=RT-UC520-PSTN, 
sequence=100, algorithm=1}
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSAlgResult - 
no policyAdvance specified in algorithm
  8. The Post-Normalization sequence is executed.

    CLI
    trigger post-normalization sequence 1 policy UC520-Four-to-Full 
condition TC-UC520-to-PSTN 
    !
policy normalization UC520-Four-to-Full
 uri-component update request-uri user 4444 85224044444
 end policy
!

    GUI




    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 util.Normalization - 
Entering Normalization(moduleRequest:post-normalize)
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 conditions.RegexCondition - 
inNetwork='Net-From-UC520'
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 conditions.RegexCondition - 
IN_NETWORK: Net-From-UC520
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 conditions.AbstractRegexCondition - 
pattern(^\QNet-From-UC520\E$), toMatch(Net-From-UC520) returning true
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 triggers.ModuleTrigger - 
ModuleTrigger.eval() action<UC520-Four-to-Full> actionParameter<>
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 triggers.ModuleTrigger - 
ModuleTrigger.eval() got the policy, executing it ...
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 normalization.URIComponentNormalizationAlgorithm - 
normalizing request-uri
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 normalization.URIComponentNormalizationAlgorithm - 
updating user/phone of the sip:4444@14.128.100.150 to 85224044444
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 util.Normalization - 
Leaving Normalization.normalize()
  9. The Route Group configuration is checked in order to find the element IP address, and the call is routed to the best route possible based on the Q-value and Weight setting.

    CLI
    !
route group RG-UC520-to-PSTN 
 element target-destination 14.128.100.150 Net-From-UC520 q-value 1.0 
  failover-codes 502 - 503
   weight 0 
  end element
 end route
!

    GUI




    DEBUG
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 loadbalancer.LBBase - 
Entering getServer()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 loadbalancer.LBBase - 
Entering initializeDomains()
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSRoutes - 
routes before applying time policies: [Ruri: 14.128.100.150, 
Route: null, Network: Net-From-UC520, q-value=1.0radvance=[502, 503]]
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 nrs.NRSRoutes - 
routes after applying time policies: [Ruri: 14.128.100.150, Route: 
null, Network: Net-From-UC520, q-value=1.0radvance=[502, 503]]
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:231 loadbalancer.LBBase - 
Leaving initializeDomains()
[REQUESTI.5] INFO  2013.02.28 07:06:57:231 loadbalancer.LBHashBased - 
list of elements in order on which load balancing is done : Ruri: 
14.128.100.150, Route: null, Network: Net-From-UC520, q-value=
1.0radvance=[502, 503],
 [REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 loadbalancer.LBBase - 
Server group route-sg selected Ruri: 14.128.100.150, Route: null, 
Network: Net-From-UC520, q-value=1.0radvance=[502, 503]
[REQUESTI.5] DEBUG 2013.02.28 07:06:57:232 loadbalancer.LBBase - 
Leaving getServer()
  10. The SIP INVITE is sent to the selected element.
    [REQUESTI.5] DEBUG 2013.02.28 07:06:57:233 DsSipLlApi.Wire - 
Sending UDP packet on 14.128.100.169:32770, destination 14.128.100.150:5060
INVITE sip:85224044444@14.128.100.150 SIP/2.0
Via: SIP/2.0/UDP 
14.128.100.169:5063;branch=z9hG4bK.ToYJFeKMyfZGySv.gcLjg~~238
Via: SIP/2.0/UDP 14.128.100.161:5060;branch=z9hG4bK21E82
Max-Forwards: 69
To: <sip:4444@14.128.100.169>
From: <sip:4001@14.128.100.161>;tag=256D566C-22AC
Contact: <sip:4001@14.128.100.161:5060>
Expires: 180
Remote-Party-ID: <sip:4001@14.128.100.161>
;party=calling;screen=no;privacy=off
Call-ID: 9B62C157-80AC11E2-8035A38B-9AE07FDE@14.128.100.161
CSeq: 101 INVITE
Content-Length: 543
Date: Thu, 28 Feb 2013 07:09:20 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
 SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2598740490-2158760418-2150671243-2598404062
Timestamp: 1362035360
User-Agent: Cisco-SIPGateway/IOS-12.x
Content-Type: multipart/mixed;boundary=uniqueBoundary
MIME-Version: 1.0

--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 3418 2914 IN IP4 14.128.100.161
s=SIP Call
c=IN IP4 14.128.100.161
t=0 0
m=audio 17618 RTP/AVP 18 101
c=IN IP4 14.128.100.161
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional

IAM,
GCI,9ae5a20a80ac11e28030a38b9ae07fde

Configuration for All Four Scenarios

Here is the complete CUSP configuration for all four call scenarios described in this document:
ajeesing-cusp-8.5.3(cusp)# show configuration active verbose
 Building CUSP configuration...
!
server-group sip global-load-balance call-id
server-group sip retry-after 0
server-group sip element-retries udp 2 
server-group sip element-retries tls 1 
server-group sip element-retries tcp 1
sip dns-srv
 enable 
 no naptr 
 end dns
!
no sip header-compaction 
!
sip logging 
sip max-forwards 70
sip network Net-CUCM standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3
  retransmit-count invite-server-transaction 5 
 retransmit-count non-invite-client-transaction 3 
 retransmit-timer T1 500 
 retransmit-timer T2 4000 
 retransmit-timer T4 5000 
 retransmit-timer TU1 5000 
 retransmit-timer TU2 32000 
 retransmit-timer clientTn 64000 
 retransmit-timer serverTn 64000 
 tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
!
sip network Net-From-UC520 standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3 
 retransmit-count invite-server-transaction 5 
 retransmit-count non-invite-client-transaction 3 
 retransmit-timer T1 500 
 retransmit-timer T2 4000 
 retransmit-timer T4 5000 
 retransmit-timer TU1 5000 
 retransmit-timer TU2 32000 
 retransmit-timer clientTn 64000 
 retransmit-timer serverTn 64000 
 tcp connection-setup-timeout 1000 
 udp max-datagram-size 1500 
 end network
!
sip network Net-PSTN standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3 
 retransmit-count invite-server-transaction 5
  retransmit-count non-invite-client-transaction 3 
 retransmit-timer T1 500 
 retransmit-timer T2 4000 
 retransmit-timer T4 5000 
 retransmit-timer TU1 5000 
 retransmit-timer TU2 32000 
 retransmit-timer clientTn 64000 
 retransmit-timer serverTn 64000 
 tcp connection-setup-timeout 1000 
 udp max-datagram-size 1500 
 end network
!
sip network Net-UC520 standard 
 no non-invite-provisional 
 allow-connections
 retransmit-count invite-client-transaction 3 
 retransmit-count invite-server-transaction 5 
 retransmit-count non-invite-client-transaction 3 
 retransmit-timer T1 500 
 retransmit-timer T2 4000 
 retransmit-timer T4 5000 
 retransmit-timer TU1 5000 
 retransmit-timer TU2 32000 
 retransmit-timer clientTn 64000 
 retransmit-timer serverTn 64000 
 tcp connection-setup-timeout 1000 
 udp max-datagram-size 1500 
 end network
!
sip overload reject retry-after 0 
sip peg-counting 2 86400 
sip privacy service 
sip queue message 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 20 
 end queue
!
sip queue radius 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 20 
 end queue
!
sip queue request 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 20 
 end queue
!
sip queue response 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 20 
 end queue
!
sip queue st-callback 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 10 
 end queue
!
sip queue timer 
 drop-policy none 
 low-threshold 80 
 size 2500 
 thread-count 8 
 end queue
!
sip queue xcl 
 drop-policy head 
 low-threshold 80 
 size 2000 
 thread-count 2 
 end queue
!
route recursion 
!
sip tcp connection-timeout 30 
sip tcp max-connections 256 
!
no sip tls 
!
trigger condition TC-PSTN-to-UC520
 sequence 1 
  in-network ^\QNet-UC520\E$
  end sequence
 sequence 2 
  in-network ^\QNet-CUCM\E$
  end sequence
 end trigger condition
!
trigger condition TC-UC520-to-PSTN
 sequence 1 
  in-network ^\QNet-From-UC520\E$
  end sequence
 end trigger condition
!
trigger condition TC-from-CUCM
 sequence 1 
  in-network ^\QNet-CUCM\E$
  end sequence
 end trigger condition
!
trigger condition TC-from-PSTN
 sequence 1 
  in-network ^\QNet-PSTN\E$
  end sequence
 sequence 2 
  in-network ^\QNet-CUCM\E$
  message request
  end sequence
 end trigger condition
!
trigger condition mid-dialog
 sequence 1 
  mid-dialog 
  end sequence
 end trigger condition
!
accounting
 no enable 
 no client-side 
 no server-side 
 end accounting
!
server-group sip group SG-CUCM.ajeet.com Net-CUCM 
 element ip-address 14.128.64.191 5060 udp q-value 1 weight 50
  element ip-address 14.128.64.192 5060 udp q-value 1.0 weight 100
  failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
server-group sip group SG-PSTN Net-PSTN 
 element ip-address 14.128.100.150 5060 udp q-value 1.0 weight 0
  failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
server-group sip group SG-UC520 Net-UC520 
 element ip-address 14.128.100.161 5060 udp q-value 1.0 weight 0 
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!
route group RG-UC520 
 element target-destination SG-UC520 Net-UC520 q-value 1.0 
  failover-codes 502 - 503 
  weight 0 
  end element
 end route
!
route group RG-UC520-to-PSTN 
 element target-destination 14.128.100.150 Net-From-UC520 q-value 1.0 
  failover-codes 502 - 503 
  weight 0 
  end element
 end route
!
route table RT-CUCM 
 key 1111 target-destination SG-CUCM.ajeet.com Net-CUCM
 end route table
!
route table RT-PSTN 
 key 4082022222 target-destination SG-PSTN Net-PSTN
 end route table
!
route table RT-UC520 
 key 2222 group RG-UC520
 end route table
!
route table RT-UC520-PSTN 
 key 3333 group RG-UC520-to-PSTN
 end route table
!
policy normalization CUCM-Prefix-408
 uri-component update request-uri user 2022222 4082022222
 end policy
!
policy normalization UC520-Four-to-Full
 uri-component update request-uri user 4444 85224044444
 end policy
!
policy lookup Policy-UC520
 sequence 100 RT-UC520 request-uri uri-component user
  modify-key 400[12] 2222
  rule exact
  end sequence
 end policy
!
policy lookup Policy-UC520-to-PSTN
 sequence 100 RT-UC520-PSTN request-uri uri-component user
  modify-key 4444 3333
  rule exact
  end sequence
 end policy
!
policy lookup Policy-to-CUCM
 sequence 100 RT-CUCM request-uri uri-component user
  modify-key 4082022102 1111
  rule exact
  end sequence
 end policy
!
policy lookup Policy-to-PSTN
 sequence 100 RT-PSTN request-uri uri-component user
  rule exact
  end sequence
 end policy
!
trigger routing sequence 1 policy Policy-to-CUCM condition 
TC-from-PSTN 
trigger routing sequence 2 policy Policy-to-PSTN condition 
TC-from-CUCM 
trigger routing sequence 3 policy Policy-UC520 condition 
TC-PSTN-to-UC520 
trigger routing sequence 4 policy Policy-UC520-to-PSTN condition 
TC-UC520-to-PSTN 
trigger pre-normalization sequence 1 policy CUCM-Prefix-408 
condition TC-from-CUCM 
trigger post-normalization sequence 1 policy UC520-Four-to-Full
condition TC-UC520-to-PSTN 
!
server-group sip ping-options Net-CUCM 14.128.100.169 4001 
 method OPTIONS
 ping-type proactive 2500
 timeout 2000
 end ping
!
server-group sip global-ping 
sip cac session-timeout 720 
sip cac Net-CUCM 14.128.64.191 5060 udp limit -1 
sip cac Net-CUCM 14.128.64.192 5060 udp limit -1 
sip cac Net-PSTN 14.128.100.150 5060 udp limit -1 
sip cac Net-UC520 14.128.100.161 5060 udp limit -1 
!
no sip cac 
!
sip listen Net-CUCM udp 14.128.100.169 5061 
sip listen Net-From-UC520 udp 14.128.100.169 5063 
sip listen Net-PSTN udp 14.128.100.169 5060 
sip listen Net-UC520 udp 14.128.100.169 5062 
!
call-rate-limit 200
!
end
ajeesing-cusp-8.5.3(cusp)#
at No comments:
Subscribe to: Posts (Atom)

My CCIE#53599

My journey started in 2013 when I decided for a CCIE in voice. One never really knows what they are in for when starting down this r...