Annex G Conference Call

Roy, Radhika R, ALTEC rrroy at ATT.COM
Thu Jul 9 15:22:43 EDT 1998


Hi Everyone,

I have to get any clear ideas for many issues especially when we talk about
the things like "DIAMETER", clearing house, mobility, and other things not
to speak about scalability of proposed solutions in the context large-scale
networks (also be applicable for all packet networks conectionless and/or
connection oriented in any combination).

So, any pre-conceived solutions based on some high-level statements are not
good enough to build confidence that those solutions will provide the right
solutions.

As a first step, my proposal is as follows:

1. Define the requirements for the clearing house function in the context of
our overall solutions
2. What mobility problems we are going to address? There are many aspects of
mobility problems: some of them may be related to the network, and may be
independent of H.323, while others might have impact on H.323 especially for
the GK when addressing, BW/QOS, and other functions are concerned.
3. What is "DIAMETER" ? I have seen few  sentences in the last Cannes conf
in the context of the H.323. It does not tell me anything. I scanned the
IETF's contributions, and I am yet to understand how this is applicable in
the context of inter-GK communications. A full contribution is supposed to
be made before we understand what is the impact of this solution in the
context of H.323. (My understandin is that it has taken a significant amount
of time to go from "RADIUS" to "DIAMETER" by the IETF. Do we want to draw a
conclusion by seeing a  2-page contribution and few minutes of conf call?)
4. The kind of architectural solutions that we might have to consider for
inter-GK communications (it is not a trivial task).

I hope that we can minimize our confusions during the conference call if we
can clarify the above things over emails or writing contributions between
now and the next conf call so that all of us understand what we talking
about.

Let us remember: if we create a standard, we have to do it RIGHT.

Thanks,
Radhika R. Roy
AT&T, USA
(732) 949 8657
rrroy at att.com


> ----------
> From:         Jim Toga[SMTP:jim.toga at INTEL.COM]
> Sent:         Thursday, July 09, 1998 12:22 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: Annex G Conference Call
>
> Orit (and others),
>
> If you've been around Intel much you know that when a meeting ends a
> certain time - it ends at exactly that time.  |:-o     Sorry about the
> abrupt cutoff, they gave us the 5min warning and then started the
> stop-watch.....
>
> I agree entirely with the sentiments below.  The only problem  being
> solved at this point is the address resolution (broken record here...).
>
> We should definitely move forward on a more general purpose solution to
> solve accounting/billing, resource usage etc... (which may someday be
> better than the simple message extentions that we're developing here).
>
> At first blush, Diameter looks like it might have promise but it needs a
> number of things all of which will require more time than is reasonable to
> wait for inter-domain 323 address resolution.
>
> 1) It needs a IETF WG home (currently an 'individual' contribution?)
> 2) It needs further development for application extentions to enable all
> of the services we described (and will come up with)
> 3) It needs to get on the standards track and move through it to RFC
> status.
>
>
> I think we would all look forward to some concrete remarks on making the
> current syntax less vague.
>
> With respect to NAI, that works well for DN related naming but what do we
> do about PSTN resolves?....(e.g calling to PSTN from IP)
>
>
>
> At 11:34 AM 7/9/98 -0400, you wrote:
> >>>>
>
>       Hello again!
>
>
>       What happened to the Conference Call?
>       Was it my fault? Did I talk too much (sorry about that)?
>
>
>       My last words were (I am not sure you could hear) there are two
> things to do:
>       1. Intel's proposal can be adopted (as "an interim" solution for
> specific "address resolution" problem) , but in order to be interoperable
> and useful
>       it should be, in my opinion, more tide:
>       - less flexible syntax
>       - defined push mechanism
>       Jim, do you mind send to you some concrete remarks? What do you
> think about using NAI instead?
>       2. In parallel, I believe, we have start working towards the more
> complete solution, starting from the "architectural" definition and things
> that we want to accomplish "as far as we can see now".
>
>
>       Orit Levin
>       RADVision Inc.,
>       575 Corporate Drive - Suite 420
>       Mahwah, NJ 07430
>       Tel:    201-529-4300 (230)
>       Fax:   201-529-3516
>
>
> <<<<
>
>
>
>
>
> *****************************************************
> ***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
> ***
> ***  mailto:jim.toga at intel.com         mailto:james.toga at ties.itu.int ***
> ***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
> *****************************************************
>



More information about the sg16-avd mailing list