<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
The IOS folks typically do a much better job with documentation.
Looks like Google has this one:<br>
<a class="moz-txt-link-freetext" href="http://books.google.com/books?id=ynIbCuTYcKIC&pg=PA220&lpg=PA220&dq=registered+unregistered+deceased+ephone&source=bl&ots=sM3d2wQ4tA&sig=s2by07q5KtTrVbgYef2WA9v2lA4&hl=en&ei=WKmdTeHIH4Xj0gHH2ZTFBA&sa=X&oi=book_result&ct=result&resnum=2&ved=0CBsQ6AEwAQ#v=onepage&q=registered%20unregistered%20deceased%20ephone&f=false">http://books.google.com/books?id=ynIbCuTYcKIC&pg=PA220&lpg=PA220&dq=registered+unregistered+deceased+ephone&source=bl&ots=sM3d2wQ4tA&sig=s2by07q5KtTrVbgYef2WA9v2lA4&hl=en&ei=WKmdTeHIH4Xj0gHH2ZTFBA&sa=X&oi=book_result&ct=result&resnum=2&ved=0CBsQ6AEwAQ#v=onepage&q=registered%20unregistered%20deceased%20ephone&f=false</a><br>
<br>
Regards,<br>
Wes<br>
<br>
On 4/7/2011 12:41 AM, Louis Koekemoer (ZA) wrote:
<blockquote cite="mid:PDZJMVMZ12Pv@VMjJkCHD" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<pre style="word-wrap: break-word; font-size: 10pt; font-family: Tahoma; color: black;">Wes, can you maybe give me a similar explanation on register, unregistered and deceased phones in cme?
Kind Regards
Louis Koekemoer
<a class="moz-txt-link-abbreviated" href="mailto:louis.koekemoer@za.didata.com">louis.koekemoer@za.didata.com</a>
+27716808790
-----Original message-----
From: Wes Sisk
Sent: 07/04/2011, 00:06
To: Ovidiu Popa
Cc: cisco-voip
Subject: Re: [cisco-voip] CUCM split brain question
</pre>
<div>For call processing unknown = unregistered.<br>
<br>
Remember those SDL links? They sends signals back and forth
called "DMPropagateRegister" and UnRegister. Instead of querying
RIS CM just checks its internal memory for local or remote
registrations. If ccm does not know about registration state
(either locally or remotely) then CFUR.<br>
<br>
<strictly personal comment><br>
Thanks for the props. I'm just one of a large pool of people
who generate the need, concepts, code, product, knowledge, and
use cases. I've been involved with a few book projects but I'm
much more committed to wikis, web publishing, and mailing
lists. Trees are much more beautiful on a trail than stacked on
a shelf. Technical information changes so quickly that it's
obsolete before the ink dries.<br>
</strictly personal comment><br>
<br>
Regards,<br>
Wes<br>
<br>
On 4/6/2011 5:13 PM, Ovidiu Popa wrote:
<blockquote type="cite">
<p class="MsoNormal">And the gifts keep on coming... the
registered/unknown puzzle unraveled :)<br>
</p>
Now for the final question:<br>
<br>
How does the Call Forward Unregistered handle Unknown states?
In my case if the branch phone never registered to CM1 since
the last CM service restart its state will be unknown. Will an
incoming call to the phone DN follow the CFUR ?
<br>
<p class="MsoNormal">Sorry to pester you with questions and
thank you again.<br>
</p>
<p class="MsoNormal">PS: If you ever decide to write a book on
CUCM please sign me up on the pre-order list.<br>
PPS : somehow I don't think I am the only one.<br>
</p>
<p class="MsoNormal">Best regards,<br>
Ovidiu<br>
</p>
<br>
<br>
On 06/Apr/11 10:49 PM, Wes Sisk wrote:
<blockquote type="cite">If phone is local to CM1 and registers
to CM1 then CM1 sees the phone as registered. Because the
SDL link is down CM2 will see the phone as unregistered.<br>
<br>
If phone is local to CM2 and registers to CM2 then CM2 sees
the phone as registered. Because the SDL links is down CM1
will see the phone as unregistered.<br>
<br>
The appearance of "unregistered" vs "unknown" in the UI is a
bit of a red herring. Registration status is captured in a
shared memory segment by the ccm process. Processes such as
AXL and RIS read that shared memory segment.<br>
<br>
When AXL or web service goes to read that shared memory
segment it reads all nodes in the cluster. With
connectivity to CM2 being down AXL or RIS on CM1 will only
be able to query CM1 shared memory. If the phone in question
has never registered to CM1 then status will be "unknown". <br>
<br>
Similarly if the ccm process on CM2 restarts then the status
will be "unknown" in the CM2 shared memory segment until the
first time the phone registers with CM2.<br>
<br>
So, "unknown" vs "unregistered" has a very subtle, possibly
even nuance, different meaning. "unknown" means the shared
memory segments currently available to query have not been
updated with a known status for that device since the last
ccm process restart. "unregistered" means the phone last
transitioned to "unregistered" signaling status with one of
the nodes that is currently accessible from the AXL or RIS
instance you are querying<br>
<br>
In ASCII:<br>
<tt>browser->Tomcat->RIS1->shared_memory1->CM1<br>
|->RIS2->shared_memory2->CM2<br>
</tt><tt> |->RIS3->shared_memory3->CM2<br>
</tt><br>
All contingent on IP connectivity from Tomcat to the various
RIS processes across the cluster.<br>
<br>
Regards,<br>
Wes<br>
<br>
On 4/6/2011 4:01 PM, Ovidiu Popa wrote:
<blockquote type="cite">Hello Wes<br>
<br>
Excellent information. I always had a difficulty
understanding the insides of the CUCM box. Thank you.
<br>
<br>
One question remains:<br>
Imagine a WAN failure for 30 minutes. CM1 and CM2 are
working without the SDL layer. CM2 (branch) sees the
branch phone as Registered, CM1 (hq) sees the phone as
unregistered or unknown?<br>
<br>
Thanks.<br>
Ovidiu<br>
<br>
<br>
On 06/Apr/11 9:22 PM, Wes Sisk wrote:
<blockquote type="cite">For example sake:<br>
CM1: headquarters<br>
CM2: branch<br>
<br>
When IP connectivity exists between CM1 and CM2 SDL TCP
sessions are established between the 2 ccm processes.
Through SDL each server tells every other server about
registered devices. There is opportunity for duplicate
registration and some propagation time so there is a
window of convergence involved. Once things are in sync
each CM node tells every other node about all
significant local state changes. Make sense? This
usually helps folks understand why QoS is so critical on
SDL links. SDL links are the vehicle for
synchronization for 2 real time processes. This isn't
quite as sensitive as parallel graphics processing but
it's not far off.<br>
<br>
When SDL link goes down each node forgets about all
entities it learned from the remote node. It literally
purges them. Devices have to register to their local
node (even the best network admins miss some especially
when it comes to virtual devices like hunt pilots, route
lists, and software media resources). Again there is
opportunity for some duplicate registration. SDL links
detect outage on the order of 10 seconds or less. SCCP
devices do keepalives on the order of 30 seconds with
allowance for 1-2 missed keepalives. 10seconds vs
60-90seconds creates a window of overlap. If a
duplicate registration is detected then CM resets both
device processes. This extends downtime but there
really is no way of knowing which is the "right"
registration. This is another window of convergence.<br>
<br>
So, after convergence the device appears unregistered on
the remote node. For an interesting dig into this
scenario take a look at<br>
CSCsc62081 CCM SDL Out of Service / In Service causes
Unexpected Unity Failover.<br>
<br>
and similarly related to realtime synchronization of
state machines:<br>
CSCsc62073 Locations Out of Bandwidth causes
unexpected Unity Failover <br>
<br>
It was the same customer who originated both of these.
This customer had truly the worst luck with timing that
I have ever seen.<br>
<br>
Regards,<br>
Wes<br>
<br>
<br>
On 4/6/2011 11:51 AM, Ovidiu Popa wrote:
<blockquote type="cite">Hello everyone
<div><br>
</div>
<div>Here's an unusual scenario that kind of puzzles
me.</div>
<div><br>
</div>
<div>Here are the details:</div>
<div>- 2 CUCM with Clustering over WAN (HQ and Branch)</div>
<div>- Centralized PSTN Access at HQ (DID numbers
routed to HQ)</div>
<div>- 1 phone with the Branch CUCM as primary and the
HW CUCM as secondary</div>
<div><br>
</div>
<div>Disaster strikes, the WAN link goes down and we
have a split brain condition.</div>
<div><br>
</div>
<div>What is the state to the phone on HQ CUCM? Will
the phone be Unregistered or state Unknown?</div>
<div><br>
</div>
<div>And the most important question is will the HQ
CUCM follow the CFUR if the state is Unknown?</div>
<div><br>
</div>
<div>Thanks for your input.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Ovidiu</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<pre><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
cisco-voip mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</div>
<p>This email and all contents are subject to the following
disclaimer:</p>
<p><a class="moz-txt-link-rfc2396E" href="http://www.dimensiondata.com/emaildisclaimer">"http://www.dimensiondata.com/emaildisclaimer"</a></p>
</blockquote>
</body>
</html>