Any shared line appearances must be in the same ERL.

[dmh070853]

I am working on a huge multi cluster CER design. I have one issue that I'm not sure how to handle...

I have multiple users (some in different clusters who share a line. Is there a way to block so that the 911 call from the originator stays in the proper (originating) ERL?

[aamercado]

I've been wondering about this alsoas it is mention in the srnd:

http://www-search.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a0080447507.html#wp1043604

but doesn't give a workaround...hope someone can pipe in cuz I'm curious

[dmh070853]

I know what you mean. I understand the issue but, need to implement a workaround.

Thanks,

Dave

[aamercado]

Actually the thing that is throwing me off is that I am interpreting your phones share lines in diff clusters..is that possible? I can understand if phones share lines in the same cluster but not in diff cluster...

Anyways, assuming phones are in the same cluster, now that I am revisit this again...I believe call to PSAP is based on the calling phone's mac address and not on the DN?? Therefore, CER routes calls to appropriate PSAP despite shared lines and psap as well as onsite should have map the mac to location.

However, PSAP callback is based on the calling DN, and will ring both the shared lines...so if the shared lines phones are within close proximity, this should not be too much a concern but if they are farther apart...well, hmm..

[aamercado]

saw your other question on callback so i'll leave it there and answer it here:

outbound callflow:

phone > 911 > CER

Here CER will take the phone's ani and replace/associate it with CER Ani (aka ELIN) and send it to PSAP. It will keeps this association for 3 hrs in its database. So CER Ani (aka ELIN) represents say a group of phones ani (such as a floor)

inbound call:

PSAP > Cer ani (ELIN) > 913 TP > 913 CTIRP > CER

Since CER still has the association in the DB, it knows to ring the original phone's ani

hth

[dmh070853]

Thanks!