Robustness people,

This is something that's been being discussed on the IMTC's implementors reflector (no doubt most of you follow that anyway). I'd suggest that it ought to be within your terms of reference! I attach the earlier mail to which I'm referring.

Raghu, Amit et al,

History regularly comes to bite us here, and I probably didn't help by not explaining the starting points to my thinking! So here we are:

1. Your reference to 7.2.2 of whichever standard it is. I agree absolutely. Where possible. However... If an endpoint fails to find a gatekeeper during gatekeeper discovery, it is permitted to assume that there is no gatekeeper around, and that it may therefore make calls without using a gatekeeper. It might be considered "polite", however, for an endpoint carrying on this way to periodically check up to see if there ARE any gatekeepers around. At least one well known H.323 stack acts in this way if asked to handle RAS for its application. The question is, what should it do if it should find a gatekeeper at this later stage?

2. The obvious thing to do here is to drop any calls immediately, and remake them when we've registered with a gatekeeper, if and only if registration is successful. However it is surely desirable for the user to know nothing of what's going on (if possible - ie ONLY if registration is successful). Delays of a few seconds mid-call, and ringing phones spoil the user's experience. So either there should be some attempt to carry the call on uninterrupted or the call should just be dropped.

3. With all the moves in the ITU towards robustness, I really think it's up to that group to specify what heppens here. However, given that their terms of reference certainly DO include keeping the call up somehow or other in the event of gatekeeper failure (which, depending on what they specify, may result in a period in which the endpoint is in a call but not registered) calls continue uniterrupted, I'd suggest that this should be the aim here.

4. However a gatekeeper has the right to know about any calls its endpoints are participating in. The only way I could see to achieve this is via ARQ for an existing call, although again the robustness group may have some ideas!

Regards, Chris

Amit sahai wrote:

Hi Raghu, I was also thinking that this is the only viable solution . Ep should close all calls and start again . What do you think Chris ?

regards Amit Sahai Convergence Technology Group, Silicon Automation Systems.

raghu.nambiath@wipro.com wrote:

...

Hi Amit,

I think there are other issues involved if ARQ needs to be sent for an ongoing call by the endpoint after registering with the Gatekeeper. This is the case if the Gatekeeper had decide to route the call. In this case what will happen to the current call status. Only way will be the endpoint close the existing call and restart the same..

Raghu

...

-----Original Message----- From: owner-h323implementors@imtc.org [mailto:owner-h323implementors@imtc.org]On Behalf Of Amit sahai Sent: Thursday, January 06, 2000 1:12 PM To: cwp@isdn-comms.co.uk; raghun@wipinfo.soft.net; h323implementors@imtc.org Subject: Re:Unregistered Calls

Hi Raghu, I think the standard has apparently laid outlines for such a scenario. I think it assumes that when endpoint is registered with a GK , for all calls it will take permission from the GK . The underlying assumption is that no calls were going on beforehand . Ref. 7.2.2 Endpoint Registration " Registration shall ocuur before any calls are attempted ......" What do you think about this line ? So this clearly is a scenario , not covered by the standard. The solution which Chris has offered seems to be a logical thing. But yet it is an improvisation. I found no mention of such a case in the standards. What I find strange is that ep is asking for ARQ for a call which is already going on ! Consider this scenario: Assume a case where a call was going on before registering with the GK.

As soon the endpoint registers with the GK , the ep asks GK for Admission for this calland GK grants it telling to route the Call Signalling through GK ( The GK has no knowledge of the call going on !) Now ep is already engaged in a call and assumes permission has been granted . It does not follow Call Signalling procedures , since it does not need to . The GK does not know the call is going on while the endpoint thinks GK has granted permission .

Don't we foresee problems with this situation ? Any comments ....

regards Amit Sahai Convergence Technology Group, Silicon Automation Systems , Bangalore.

---

---

---

Please send E-mail to contact@imtc.org mailto:contact@imtc.org to subscribe or unsubscribe from this list

---

---

---

-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001