Subject: RE: [IPTEL] Definition of "trunk group"/Scope

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Tue, 8 Jan 2002 14:58:25 -0500

Hi, All:

It appears that we have spent a good amount of time on this particular issue what are the items to be included in the trunk group. Thanks to all that we agreeing more and more in this area. Let us now turn our attention to some basic issues as follows:

1. What is the definition of (monolithic or decomposed) GWs? Are these GWs not doing the protocol conversion (e.g., SIP-ISUP, SIP-H.323, etc)? If it is so, it seems to be that the GW registration protocol that we are proposing will be used to facilitate the routing of the calls of SIP to ISUP/H.323 and vice versa.

2. The attributes that a GW will register with the location server must be abstracted in such a way that can be used in the signaling protocols (SIP, ISUP, H.323) in a meaningful way otherwise these [attributes] will be useless. Because the intra-Domain (as well as inter-Domain like TRIP) protocol is used in the "backend" of SIP Proxies to complete the calls (e.g., SIP-ISUP, SIP-H.323) and is NOT an end-to-end protocol.

3. If there is only one location server in an ITAD, we do not need to worry about the communications among the location  servers. In this situation, we can develop the GW registration protocol very easily without worrying too much what needs to be propagated.

4. If we develop the protocol for communications among the location servers, as it appears, that some people are too much concerned what can be propagated or not. The GW attributes that we are considering can be address families, capacity, QOS, and/or others. We need to consider that we are focusing ONLY on the intra-Domain communications where only one IP Telephony administrator is responsible. Since we are NOT considering the inter-Domain communications like TRIP, we may not need to be overly concerned. That is, we can sort out our problems case by case basis because we will, unlike TRIP, be transferring all the attributes among the LSs within an ITAD.

5. If we consider item 4, it appears that we have to develop the complete intra-Domain protocol. Can we include this as a IPTEL WG item? If not, why not?

6. If we do not include item 4, we are left with a situation where we can assume that there is only ONE location server in an ITAD (as I explained in my earlier emails). How does it help to achieve the real objectives of the IPTEL WG (our proposed I-D shows that we only need one [or at best two] messages beyond the GW registration/discovery protocol)?

Let us discuss the above points providing pros and cons from technical point of view.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 11:44 AM
To: Tom-PT Taylor
Cc: 'Peterson, Jon'; [email-masked]'; [email-masked]
Subject: RE: [IPTEL] Definition of "trunk group"

Tom, Jon,

I concur with your line of thought, although I think the terms "direct" and 
"indirect" are more descriptive and useful.  Will these characteristics be 
propagated as attributes when advertising that a TG can reach a specific 
carrier?

Mike

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel