cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
614
Views
25
Helpful
4
Replies

CSS conceptual questions

Hi people

My doubt is silly but I need do.


A conceptual question

On CUCM 7.x

1st afirmation.

Phone A = 1600 in PRT_SITEA

Phone B = 1601 in PRT_SITEA

Both without CSS, Phone A calls Phone B because are on same partition. Correct?!

2st question

Phone A = 1600 in PRT_SITEA with CSS_SITEB

Phone B = 1601 in PRT_SITEA with CSS_SITEB

Phone C = 1600 in PRT_SITEB with CSS_SITEB

CSS_SITE B contains ONLY PRT_SITEA

So, when the Phone B calls 1600, what extension will ring, Phone A or Phone C? On my customers, 7.0.2 Phone C is called. My question is... all patterns on same partition of calling has priority over partition of CSS at line? The conceptual of css/prt change from CUCM 4x to CUCM 7x?

Thanks

Peterson

4 Replies 4

techguy73
Level 1
Level 1

Lets go over it.

1st afirmation.

Phone A = 1600 in PRT_SITEA

Phone B = 1601 in PRT_SITEA

Both without CSS, Phone A calls Phone B because are on same partition. Correct?!

Actually not, once you put the phones in partition, the CSS becomes necessary to call each other. CSS determines the calling capability for a particular phone/dn.

-----

2st question

Phone A = 1600 in PRT_SITEA with CSS_SITEB

Phone B = 1601 in PRT_SITEA with CSS_SITEB

Phone C = 1600 in PRT_SITEB with CSS_SITEB

CSS_SITE B contains ONLY PRT_SITEA

So, when the Phone B calls 1600, what extension will ring, Phone A or Phone C? On my customers, 7.0.2 Phone C is called. My question is... all patterns on same partition of calling has priority over partition of CSS at line? The conceptual of css/prt change from CUCM 4x to CUCM 7x?

Here when PhoneB calls 1600, CSS_SITEB will get engaged, which contains PRT_SITEA which is the Partition of PhoneA with 1600, will ring.

To further explain this, if you replace the partition in CSS_SITEB from PRT_SITEA to PRT_SITEB, and dial the same 1600 from PhoneA, your PhoneC will ring.

Line or DN is more granular and will have priority over the Phone/Device.

hope this helps

Techguy

Note: If you found this reply helpful, please rate accordingly.

William Bell
VIP Alumni
VIP Alumni

pgcristovam wrote:

On CUCM 7.x

1st afirmation.

Phone A = 1600 in PRT_SITEA

Phone B = 1601 in PRT_SITEA

Both without CSS, Phone A calls Phone B because are on same partition. Correct?!

Actually, Phone A will not be able to call Phone B (and vice versa).  Keep in mind that because you placed them in a partition they will need to have that partition in either the device level Calling Search Space (CSS) or the line level CSS.  Also note that the "" partition is an actual partition that is reachable from all CSS (including "none").

pgcristovam wrote:

2st question

Phone A = 1600 in PRT_SITEA with CSS_SITEB

Phone B = 1601 in PRT_SITEA with CSS_SITEB

Phone C = 1600 in PRT_SITEB with CSS_SITEB

CSS_SITE B contains ONLY PRT_SITEA

So, when the Phone B calls 1600, what extension will ring, Phone A or Phone C? On my customers, 7.0.2 Phone C is called. My question is... all patterns on same partition of calling has priority over partition of CSS at line? The conceptual of css/prt change from CUCM 4x to CUCM 7x?


If phone B calls 1600, Phone A should ring given the information you provied.  You would not be able to place two patterns in the same partition if they are identical patterns.  However, you can "share" a line appearance but that is still one DN in one partition.  When a phone makes a call the CUCM digit analysis is using an "effective CSS" which is comprised of the line level CSS and the device level CSS.  This is a join where the partitions in the line level CSS take priority over the device level CSS.  With in a partition, you cannot have two "separate" patterns that are identical. We already covered that part.

In regards to changes between 4x and 7x.  The fundumental architecture of CSS and partitions has not changed.  Features have been added.  Such as time of day routing and intercom partitions/CSS and transformations.  But, the essence of partitions and CSS arrangement in Cisco-land is the same and has been for quite some time.

HTH.


Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Hi guys

First a correction.

When I wrote CSS_SITE B contains ONLY PRT_SITEA, the correct is CSS_SITE B contains ONLY PRT_SITEB.

Example case:

On IPCC 4.0 with CCM 4.2.3:

One CTI ROUTE POINT 8200 in PRT_CTIPORT

On the script, the CTI ROUTE POINT (without CSS in line) redirect to Hunt Pilot 8696 in PRT_EXTENSION

There is a extension 8696 in PRT_CTIPORT with forward to 8900

And all works fine.

After upgrade, without any change on environment

One CTI ROUTE POINT 8200 in PRT_CTIPORT

On the script, the CTI ROUTE POINT (without CSS in line) redirect to Hunt Pilot 8696 in PRT_EXTENSION

There is a extension 8696 in PRT_CTIPORT with forward to 8900

The call is not send to Hunt Pilot and yes to 8696 in PRT_CTIPORT (same partition)

So, we put on line of CTI ROUTE POINT a CSS with only PRT_EXTENSION. Same thing. The call is redirected to 8696 in PRT_CTIPORT (same partition) The CSS is not respect.

Workaround, change the Hunt Pilot 8696 to 48696 in PRT_EXTENSION and change the script to it. And with it all works fine.

Thanks

Peterson

pgcristovam wrote:

Hi guys

First a correction.

When I wrote CSS_SITE B contains ONLY PRT_SITEA, the correct is CSS_SITE B contains ONLY PRT_SITEB.

OK. Then when a device with this CSS calls 1600 they will ring the 1600 in PRT_SITEB.

pgcristovam wrote:

Example case:

On IPCC 4.0 with CCM 4.2.3:

One CTI ROUTE POINT 8200 in PRT_CTIPORT

On the script, the CTI ROUTE POINT (without CSS in line) redirect to Hunt Pilot 8696 in PRT_EXTENSION

There is a extension 8696 in PRT_CTIPORT with forward to 8900

And all works fine.

After upgrade, without any change on environment

One CTI ROUTE POINT 8200 in PRT_CTIPORT

On the script, the CTI ROUTE POINT (without CSS in line) redirect to Hunt Pilot 8696 in PRT_EXTENSION

There is a extension 8696 in PRT_CTIPORT with forward to 8900

The call is not send to Hunt Pilot and yes to 8696 in PRT_CTIPORT (same partition)

So, we put on line of CTI ROUTE POINT a CSS with only PRT_EXTENSION. Same thing. The call is redirected to 8696 in PRT_CTIPORT (same partition) The CSS is not respect.

Workaround, change the Hunt Pilot 8696 to 48696 in PRT_EXTENSION and change the script to it. And with it all works fine.

Thanks

Peterson

I am not folliwng this 100%.  The CTI Route Point CSS doesn't come into play.  If I follow, the script is sending the caller to a Hunt Pilot based on an IVR entry/action.  In this case, the transfer should be based on the CSS of the CTI Port that handled the audio stream.

The fact that you made a modification like 48696 to fix the issue means that both the PRT_Extension and PRT_ctiport are visible from the transfering station.  Since they are identical patterns, the partition in the highest priority position will be preferred.  This behavior has not changed in 7x.  That being said, I believe that there was a change to how the device and line level CSS was dealt with on CTI devices specifically.  Unfortunately, I don't recall the details.

HTH.


Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: