URQ ambiguity

Paul E. Jones paulej at PACKETIZER.COM
Wed Dec 6 17:40:49 EST 2000


Folks,

In reviewing some H.323v4 text, I noticed some ambiguity.  Refer to section 7.2.2, it says:
  A Gatekeeper may cancel the registration of an endpoint by sending an Unregister Request (URQ) message to the endpoint. The endpoint shall respond with an Unregister Confirmation (UCF) message. The endpoint shall attempt to re-register with a Gatekeeper prior to initiating any calls. This may require the endpoint to register with a new Gatekeeper.

  If the Gatekeeper sends a URQ message containing a list of alias addresses, the endpoint shall assume that only those alias addresses are unregistered if it chooses to accept the request. If the Gatekeeper sends a URQ message that does not contain any alias addresses, the endpoint shall assume that all alias addresses, if any, are unregistered if it chooses to accept the request.

I see two troublesome parts to this text.  The text that says "if it chooses to accept the request" is one.  I don't believe that an endpoint has a choice-- it shall always reply with UCF as stated in the first paragraph.  The last sentence of the second paragraph makes no sense at all.  If a Gatekeeper sends a URQ with no aliases, that is already understood by all endpoints that the endpoint is no longer registered-- it cannot simply imply that all aliases are unregistered, but not the endpoint itself.

I would like to propose that we delete all of this text from H.323:
  if it chooses to accept the request. If the Gatekeeper sends a URQ message that does not contain any alias addresses, the endpoint shall assume that all alias addresses, if any, are unregistered if it chooses to accept the request
Any opinions?  If we get agreement, I'll bring such a proposal to the next meeting.

Paul
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001206/aff41068/attachment-0003.html>


More information about the sg16-avd mailing list