H.323 Annex M.1

Mon Jul 10 21:38:21 EDT 2000

Hi, Jakko and all:

Please see my response provided below [RRR].

In Osaka, it was told that the multicast of MGA is a problem because of
bandwidth consumption. However, using of MGA in a unicast mode does not pose
any problems with respect to the bandwidth consumption.

That is why, the post-Osaka emails were sent by to clarify the meeting

Therefore, MGA can be implemented using multicast or unicast method as
desired by implementation. In this respect, I have also mentioned the work
that is being done in 3GPP. They also embraced the mobile IP concept where
both agent solicitation (similar to our GRQ) and agent advertisement
(similar to our proposed MGA) are used. 3GPP has also proposed to use the
agent advertisement message (similar to our proposed MGA) as "unicast"
method as a mechanism to reduce the bandwidth consumption.

In this respect, as I was told in the Osaka meeting, I have clarified why
MGA is an excellent proposal to interwork with mobile IP and 3GPP system if
one wants to use mobile H.323 in the upper layer.

Furthermore, MGA is not a mandatory, but is an OPTIONAL message. If one does
not like to use, they may not use it.

The conclusion is that both GRQ and MGA message will complement each other
as the agent solicitation and agent advertisement message complement each
other in mobile IP (as well as 3GPP), and thereby opens the way for
interworking between mobile H.323 and mobile IP (when H.323 is implemented
over the IP layer).

Without any mechanisms like MGA in H.323, mobility in H.323 will be highly
"INCOMPLETE" and the mobile H.323 standard will almost be "meaningless" when
the interworking with lower "mobile IP" layer is concerned. I do believe
that we should NOT let it happen to the mobile H.323 standard.

I like to see that people should provide any "technical" reasons in this
"public" email reflector (that is received by the SG16 people worldwide) why
MGA is not acceptable. I will provide justification for each email and we
will go from there.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist at nokia.com]
Sent: Monday, July 10, 2000 3:16 AM
Subject: Re: [H.323 Mobility:] A new H.323 Annex H Draft

Hi Radhika et al,

Let's try to start a bit of discussion...

> It is nice to see that you and Mr. Kumar had a communication
> related to GRQ
> and you have included in the contribution.

Yes, actually Mr. Kumar raised this point already in Osaka, but it seems to
have been kind of lost in the conversations. At least I did not quite grasp
this issue at that time. It does seem a perfectly valid point though (if
someone has a counter-argument, please inform us).

[RRR] I also think that it is a reasonable idea. If other members have any
counter arguments, please let us know.

> I wonder what happened to the emails that I sent to the SG16
> email "public"
> reflector related to MGA message! I have not seen any counter
> arguments
> related to this in the email reflector. I like to see that
> MGA message is
> also included (with both unicast and multicast option as suit the
> implementation).

Your emails did arrive, or at least I saw them. The reflector seems to have
been quite quiet recently, perhaps some people are having their holidays (I
did, before I had time to comment on your emails).
As for the MGA issue. I think we had a quite good discussion on that in
Osaka and it seemed to me that really no one  else was in favor of the idea.
Most people, including myself, came to the conclusion that the MGA scheme
would be less efficient instead of being more efficient than multicasting
GRQs. Thus far I haven't seen anything that would convince me otherwise (I
don't remember exactly, what you said in your last email about the MGA, but
I did read it and did not find any new arguments in favor of the MGA).
Furthermore, I think that having two alternate multicasting schemes for
gatekeeper discovery would only lead to difficulties both in making an
explicit and robust annex as well as in implementation of the mobile H.323
system described in the annex.

[RRR] Please see my reply provided above. Please provide your or other
members' "TECHNICAL" arguments against my explanations provided above
instead of "simply" saying that you are not "convinced" or something like
that. This is a qualitative statement and does not provide any technical

> I would also appreciate that you should start discussing in the email
> reflector before any further update is made in the document
> so that we can
> participate in the process for updating the document. The
> discussion can be
> formulated as follows:
> 1. What you want to propose and why
> 2. Pros and cons of the proposals
> 3. Invite comments from the members
> 4. Update the document based on item 3

As you mentioned, I have tried to do steps 1 and 2 in the emails I have sent
to the reflector. The idea behind this approach of me sending a draft (or
editor's draft, if you will) every once in a while is step 3. By sending a
whole new draft, I'm trying to force people to react to the changes. Step 4
will naturally be done after the discussions about the changes.
You said that you will produce your comments on the new draft soon, good,
that is precisely want I wanted (step 3). I hope others will do the same.

[RRR] I already provided my initial comments before going to the Osaka
meeting with respect to your initial draft that was produced by you. Your
original draft has not been changed much since then what has been in
pre-Osaka meeting. If you look into those comments sent by me via emails and
during the conference calls before the Osaka meeting, you may have a feel
what I have to say. However, it is a valid point that I have to make my time
to provide comments on your latest draft.


For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list