The “Accept Replaces Header” and Rerouting CSS” For Call Bridge Group Cisco Meeting Server In-depth Lecture

The Call Bridge Group on Cisco Meeting Server feature is to make sure that all participants within a Call Bridge Group accessing a particular Space will all be connected to the same server, thereby eliminating excessive distribution of calls between Call Bridge nodes. To make this happen, when a call is extended to a CMS to join a Space, the server will communicate with the other Call Bridge servers to determine which server is currently hosting the meeting. If it determines that a Space is being hosted by another server within the Group, then the destination serer will send a SIP INVITE with a Replaces header, essentially telling the Unified CM to transfer the call to it.

At the same time, if a meeting is hosted by a Call Bridge in one Call Bridge Group and someone wants to join from a different region and therefore dials in via a second Call Bridge Group, those calls will always be distributed between the servers in the different regions. The goal is to aggregate the calls for a Space on a single server within a given Call Bridge Group.

This feature imposes requirements on the call control. For a CMS integration to Unified CM, this means Accept replaces header must be enabled in the SIP Trunk Security Profiles and each SIP trunk to CMS must have a Rerouting Calling Search Space configured to allow the call be be transferred between CMS SIP trunks.

To group Call Bridges in one Group. Enables Load Balancing of Calls on CallBridge within same CallBridge Groups.

Within each Call Bridge group, the aim is to have calls for the same conference placed on the same server whenever possible.

To do that Call Bridge Groups require Cisco Call Manager SIP Trunk Security Profie Requires “ACCEPT with Replaces” to accept “INVITE with Replaces” header and the Rerouting Calling Search Space.

  1. pperez Dials ccnp@collab.lab.local
  2. CUCM checks SIP Route Pattern
  3. CUCM checks Route List RL-CMS
  4. CUCM checks Route Group RG-CMS
  5. Route Group RG-CMS is configured with 2 SIP Trunks to the 2 CMS CMS-A and CMS-B in Circular Distribution Algorithm
  6. CUCM Routes call to CMS-A
  • jsmith Dials ccnp@collab.lab.local
  • CUCM Routes call to CMS-B
  • CMS-A sends a SIP INVITE with replaces to CUCM to re-route the call to CMS-A
  • CUCM routes call to CMS-A

What kind of SIP messages are blocked if one of these options are not configured? How SIP intelligently modifies the SDP informations in the fly to provide intelligent load balancing.

To understand how the Accept Replaces Header and the Rerouting CSS works and how the call is rerouted and provides efficient and intelligent load balancing, let’s do a deeper analysis and see in the background what happen.

From client Jabber pperez@lab.local,dialccnp@collab.lab.local. The user pperez is connected to a Space hosted on the call bridges.

From the wireshark capture we can see that the Media is between CMS-A 10.1.5.50 and pperez 10.1.5.100. The Conference named Demystify From Scratch Meeting with a space ccnp is active on CMS-A.

From client Jabber jsmith@lab.local,dial ccnp@collab.lab.local.

We can see the replace query lines for each of the Call Bridges in the Call Bridge Group, the following order determines which callbridge will host the conference.

  1. priority – the Call Bridge preference of that space
  2. load level – the load level of that Call Bridge at that moment in time
  3. conference is running – boolean whether the space is active on that Call Bridge

The event log on CMS-B shows that the space ccnp is active on Call Bridge with name CMS-A. As the space is active on CMS-A as shown by the line “The conference is running 1” and the load on that server is lower than the existing threshold (load level: 0), the call is replaced. CMS-B solicits CMS-A to replace the call coming from the call control 10.1.5.16 with Call ID 65c73500-10001-3a2-93f492a@10.1.5.16.

CMS-A sends a SIP INVITE with Replaces Header in the Message Header, this SIP INVITE is coming From “Demystify From Scratch Meeting” ccnp@collab.lab.local, TO jsmith@lab.local.

What’s inside the Replaces header? Obviously, it must be something that can uniquely identify the call received by CMS-B. This identification is based on the the Call-ID of the existing SIP dialog (between CMS-B and CUCM), the “To Tag” and “From Tag”, the To TAG identified the jabber client jsmith@lab.local who initiated the call while the From TAG identifies the space with its own URI (for example ccnp@collab.lab.local).

The “Call ID”,  “To Tag” and “From Tag” of the SIP dialog between CMS-B and BR-CUCM,  The “Call ID”,  “To Tag” and “From Tag” in the SIP INVITE sent by CMS-A to BR-CUCM are the same.

The Replaces Header in the SIP INVITE sent by CMS-A has the following Call ID, To Tag and From Tag.

65c73500-10001-3a2-93f492a@10.1.5.16;to-tag=1298~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851046;from-tag=529a83981e4deb40

As shown below:

The SIP Dialog between BR-CUCM and CMS-B has the following Call ID, To Tag and From Tag.

CMS-A is trying to spoof the SIP conversation and the call between CMS-B and BR-CUCM. The ultimate goal is to establish the media between CMS-A and the jabber client jsmith@lab.local in order to avoid a disributed call and the media connection between CMS-B and CMS-A.

This Option of Replaces Header will instruct the Call Control to reroute the call’s jsmith to CMS-A where an existing space (ccnp in this case) is already there.

If we look inside the SDP of the SIP INVITE sent by CMS-A to BR-CUCM, it includes the IP Address 10.1.5.50 and Audio RTP port 37608 the CMS-A offers to jsmith@lab.local to establish the media.

The BR-CUCM receives the SIP INVITE with Replaces Header, the SIP Trace on the event logs of CMS-A shown that the BR-CUCM sent back SIP message with 404 Not Found.

The wireshark capture confirms the issue.

The reason is that the call control needs a Rerouting CSS in order to inform the jabber client about the change made in its SIP Dialog, this is done by the SIP Update message, this SIP Update message must be rerouted, not routed, therefore when BR-CUCM needs to send a SIP Update to jsmith, it needs a Rerouting CSS that include the Directory URI partition of the jabber client on the SIP Trunk where the SIP INVITE was received from CMS-A.

Because there is no Rerouting CSS defined and the URI jsmith@lab.local is in the Directory URI partition. The BR-CUCM sent back 404 Not Found message to CMS-A.

Let’s configure a CSS br-css with Directory URI partition and assign this CSS to the SIP Trunk toward CMS-A (and CMS-B) under the Rerouting Calling Search Space field.

From the jabber client jsmith, let’s try to call the space named Demystify From Scratch Meeting using the URI ccnp@collab.lab.local.

The event log on CMS-B shows that the space ccnp is active on Call Bridge with name CMS-A. As the space is active on CMS-A as shown by the line “The conference is running 1” and the load on that server is lower than the existing threshold (load level: 0), the call is replaced. CMS-B solicits CMS-A to replace the call coming from the call control 10.1.5.16.

In the Wireshark capture, CMS-A sent a SIP INVITE with the Replaces Header to BR-CUCM and the Call Control responds back with 403 Forbiden message.

Let’s analyze the SIP Trace in the Event Log of CMS-A, we can see that the BR-CUCM sent back an Incoming SIP with 403 Forbiden message.

The reason of this issue is that without the Option Accept Replaces Header in the SIP Trunk Security Profile, BR-CUCM will drop the SIP invite with the Replaces Header set. This Option of Replaces Header will instruct the Call Control to accept a SIP INVITE with the Replaces Header. This option will allow the BR-CUCM to transfer the call initiated by jsmith@lab.local and routed out toward CMS-B to CMS-A.

Edit the the SIP Trunk Security Profile already applied on the SIP Trunk to CMS-A and CMS-B, and check the Accept Replaces Header option.

Reset the SIP Trunk.

Let’s try another call from jsmith@lab.local to the space ccnp@collab.lab.local.

Now the jabber client jsmith is connect successfully to the space ccnp.

Step 1:

The jabber client jsmith@lab.local sent a SIP INVITE with SDP to BR-CUCM, the Call ID is 000c2972-b1cc00ae-00006003-000060e0@10.1.5.114.

Inside the SDP, it includes its IP address 10.1.5.114 and Audio RTP port 23086/VideoRTPPort 29970 that will be used later for media.

Step 2:

BR-CUCM replies with SIP 100 Trying.

Step 3:

BR-CUCM according the Route Group algorithm with Circular, send a SIP INVITE without SDP to CMS-B.

Step 4:

CMS-B replies with SIP 100 Trying, this call is identified with the Call ID 8b097280-10001-44d-93f492a@10.1.5.16, From TAG = 1623~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851074 and To TAG = 0bb81861725b6a46.

Step 5:

CMS-B sent SIP 180 Ringing to BR-CUCM.

Step 6:

BR-CUCM sent SIP 180 Ringing to jsmith@lab.local.

Step 7:

The event log on CMS-B shows that the space ccnp is active on Call Bridge with name CMS-A. As the space is active on CMS-A as shown by the line “The conference is running 1” and the load on that server is lower than the existing threshold (load level: 0), the call is replaced. CMS-B sollicits CMS-A to replace the call coming from the call control 10.1.5.16 with Call ID 8b097280-10001-44d-93f492a@10.1.5.16.

CMS-A sends a SIP INVITE with Replaces Header in the Message Header, this SIP INVITE is coming FromDemystify From Scratch Meetingccnp@collab.lab.local, TO jsmith@lab.local.

Inside the Message Header, the Replaces Header is equal to Call ID = 8b097280-10001-44d-93f492a@10.1.5.16;to-tag=1623~74e80987-2d30-48f7-a1e5-50a557f5e04e-18851074;from-tag=0bb81861725b6a46. The same values of Call ID, To Tag and From Tag in Step 4.

This SIP INVITE is coming From “Demystify From Scratch Meeting” ccnp@collab.lab.local, TO jsmith@lab.local.

CMS-A is spoofing the SIP Dialog between BR-CUCM and CMS-B and it requests the BR-CUCM to transfer the call to it.

Step 8:

This SIP INVITE includes the SDP payload, inside the SDP, CMS-A offers the IP Address 10.1.5.50 and Audio RTP port 37700/Video RTP port 37702 to establish media with jsmith@lab.local.

Since the BR-CUCM is configured with Accept Replaces Header in the SIP Trunk Security Profile, it sends a SIP Cancel message to terminate the SIP Dialog to CMS-B. The CMS-B sends back a 487 Request Terminated. BR-CUCM sends back an ACK to acknowledge receipt of 487 message.

Now CMS-A replaces the CMS-B in the SIP conversation.

BR-CUCM needs to inform the jabber client about the change of its early SIP Dialog, the SIP Update is the same Call ID 000c2972-b1cc00ae-00006003-000060e0@10.1.5.114 as with the Call ID of the SIP INVITE sent by jsmith@lab.local in Step 1.

SIP UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. This makes it very useful for updating session parameters within early dialogs.

Then the jabber client sends a 200 OK message.

Finally, the BR-CUCM sends 200 OK message with SDP to jsmith@lab.local including inside the SDP Body, the CMS-A’s IP address 10.1.5.50 and Audio RTP port 37700/Video RTP port 37702 of CMS-A offered in step 8.

BR-CUCM also sends 200 OK message with SDP to CMS-A, inside the SDP Body, the jsmith’s IP address 10.1.5.14 and Audio RTP port 23086/Video RTP port 29970 of jsmith offered in step 1.

CMS-B sends back an ACK to acknowledge receipt of 200 OK message.

Jsmith sends back an ACK to acknowledge receipt of 200 OK message.

Finally the media is established between jsmith@lab.local with IP Address 10.1.5.114 and UDP port 23086 and CMS-A with IP Address 10.1.5.50 and UDP port 37700 directly achieving the Call Bridge Group Load Balancing with the goal avoid the distributed calls between Call Bridges.

Below the first user pperez@lab.local 10.1.5.100 who create the conference ccnp with media flow established with CMS-A 10.1.5.50.

On CMS-A, navigate to Status > Call, verify that there are two active calls from pperez@lab.local and jsmith@lab.local. There is no distributed call.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s