Subject: [IPTEL] Requirements for Gateway Registration I-D

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 26 Nov 2001 09:06:32 -0500

Hi, Jonathan:

I have the following comments for the I-D
<draft-rosenberg-iptel-gwreq-req-00.txt>:

1. The title should rather be " Requirements for intra-ITAD communications
protocol," because the protocol needs to do discovery, registration, and
communications among the gateways (GWs) and location servers (LSs).
2. Figure 1 should be modified to show that a GW can be Telephony gateway
(IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).
3. The requirements should reflect that a GW can have the addresses of email
IDs and URL IDs and others in addition to Telephone addresses.
4. One additional requirement needs to be added: Synchronization of
information among the location servers.

In addition, we may also say that preferences will be given for selection of
the protocol in its "simplicity" and "efficiency" that can be used as an
"extension" or "subset" of TRIP protocol in satisfying the requirements.

Best regards,

Radhika R. Roy
[email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 13:12:07 -0500

> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 9:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Requirements for Gateway Registration I-D
> 
> 
> Hi, Jonathan:
> 

No. I have posted a note today on this; general intra-domain operation is
OUT OF SCOPE.

> (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).

It is not clear to me that this is a requirement. Work so far has focused on
telephony gateways. Certainly the attributes will be significantly
different. Its not clear to me that the framework of this problem is
generally the same either. If you include SIP-H.323 gateways, would you
include SIP proxies? Both are signaling intermediaries that may server a
subset of addresses. However, I do not think those are in scope. As neither
SIP-H.323 gateways or proxies handle media, their notions of capacities and
load are much different. If the framework we build would support such things
by defining a different attribute set, great, but we are not designing
towards that in my opinion.

> IDs and URL IDs and others in addition to Telephone addresses.

See above.

> information among the location servers.

No. See my response to (1).

> "extension" or "subset" of TRIP protocol in satisfying the 

Choosing a protocol that is simple and efficient is a goal for all protocol
design work. I see no need to restate that. Whether to use an extension or
subset of TRIP is not a requirement, its a design choice. This document is
not about protocol design, its about high level reuqirements.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 16:18:20 -0500

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 1:12 PM
To: Roy, Radhika R, ALCTA; Jonathan Rosenberg

[RRR] If there is more than one LS in an ITAD, a proprietary protocol will
be used. Or, are you suggesting I-TRIP need to be used?

telephony gateways. 

[RRR] Can you define what the telephony GW is? 

[RRR] Is it the MGC of MEGACO (or MGCP)? If it is, MGC is a signaling entity
and the media GW (MGW) will handle the media/circuits and, they are separate
entities. However, a MGC provides all the information related to the MGW
(its capacity, and other attributes). A LS will communicate with the MGC
(not with the MGW).

Certainly the attributes will be significantly
different. Its not clear to me that the framework of this problem is
generally the same either. 

[RRR] Whatever attributes are needed, these attributes are passed by the
signaling entity (e.g., MGC), not the media entity (e.g., MGW).

If you include SIP-H.323 gateways, would you
include SIP proxies? 

[RRR] Why do I want to include SIP Proxy? SIP Proxy is handling the SIP
protocol only, it is not doing any protocol conversion. However, a SIP proxy
can talk to a SIP-H.323 IWF or MGC using SIP protocol (by the way, if the
SIP protocol would allow the registration of the GW, like H.323, we would
not go through unnecessary difficulties for registration). Similarly, a
location server (LS) will also talk to the SIP-H.323 IWF or MGC to get the
necessary information. Am I missing anything?

Both are signaling intermediaries that may server a
subset of addresses. However, I do not think those are in scope. 

[RRR] I am completely lost here. Can you be more specific?

As neither
load are much different. 

[RRR] A SIP-H.323 IWF or MGC will have the necessary information to pass to
the location servers.

If the framework we build would support such things
by defining a different attribute set, great, but we are not designing
towards that in my opinion.

[RRR] Could please clarify this?

See above.

[RRR] Like any other attributes, email IDs, URL IDs, etc. can also be
passed.

[RRR] It is not a big deal. We are defining communications between the GW
and the LS. In the same token, the LS to LS communication can also be done
using the same sets of messages that are being used between the GW and the
LS (e.g., TRIP is doing. All we need to do here is to use the same or
similar messages, but do not do any route propagation). All LSs remain
within an ITAD. An ITAD has already been defined in the TRIP framework
document.

[RRR] It is a fair statement. That does not mean we SHOULD only define one
message like "REGISTRATION/OPEN." (We will not use LS to LS communications,
we will not use auto-DISCOVERY, what else is left to define.)

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 16:32:54 -0500

> Sent: Tuesday, November 27, 2001 4:18 PM
> To: Jonathan Rosenberg
> Subject: RE: Requirements for Gateway Registration I-D
> 

I am suggesting exactly what I posted. THis work is OUT OF SCOPE for this
working group. That means we are not addressing it. 

> (its capacity, and other attributes). A LS will communicate 

Its something for which attributes like total capacity, current capacity,
PDD and ASR are sane attributes to describe. Whether that element is
decomposed or not is irrelevant.

> necessary information. Am I missing anything?

Yes. I am trying to determine where you draw the line of the type of server
elements supported by the gateway registration protocol. I would argue that
it is very hard to differentiate a SIP proxy from a SIP-H.323 IWF through
external behaviors, metrics that define capacity, etc.

> [RRR] A SIP-H.323 IWF or MGC will have the necessary 

Your response is nonsensical. A SIP-H.323 IWF doesn't handle media. In that
regards, its like a proxy. Thus, metrics for measuring its capacity (in
terms of DS0, for example) are not the same as the ways you'd measure the
capacity of a PSTN gateway.

> [RRR] Could please clarify this?

We are not designing a general purpose protocol for discovery of, and load
balancing across, servers. We are focusing on one type of server, PSTN
gateways. If the solution happens to be sturecutre in such a way that it can
work for other servers, great. But, that is not a goal we are working
towards.

> [RRR] Like any other attributes, email IDs, URL IDs, etc. can also be

Not if its just a PSTN gateway.

> LS (e.g., TRIP is doing. 

That is an assumption of monstrous proportions.

You have a totally different view of what an intra-domain protocol is than I
do. In my view, it is more like the inter-domain problem. I suspect both of
our views are different from others in the group. This problem is not yet
sufficiently defined to start work on protocol specifications. Furthermore,
we are not chartered to do it. So, it is out of scope. Period. It is also
therefore out of scope to argue about what the intra-domain problem is.

> we will not use auto-DISCOVERY, what else is left to define.)

Your response makes no sense to me. The charter defines a problem. We will
first determine requirements for the solution, and then define the protocol.
I don't know how to explain that more clearly.

-Jonathan R.

---

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 17:27:20 -0500

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 4:33 PM
To: Roy, Radhika R, ALCTA
Cc: [email-masked]
Subject: RE: Requirements for Gateway Registration I-D

[RRR] Please see my answers provided below.

[RRR] Good. We are in agreement.

[RRR] Please see my answers provided below. (If I recollect your email in
the SIP-H.323-eGroup, you advocated that SIP-H.323 IWF will also be allowed
to register when the GW registration protocol is developed.)

[RRR] No one is saying that the capacity attributes for SIP-H.323 IWF and
the MGC (PSTN GW) should be the same. For SIP-H.323 IWF, it may be limited
to port capacity or like this, if it is (but not sure). Here (SIP-H.323
IWF), we are primarily concerned with the addresses only.

[RRR] If I recollect your email in the SIP-H.323-eGroup, you also mentioned
that we will be working for registration of the GWs including PSTN and
SIP-H.323, because the registration of the GW is a generic problem. Now the
question is: If we can register the PSTN GW, why can we not register the
SIP-H.323 IWF? The only difference is that a SIP-H.323 IWF does not need to
use all capacity attributes that a PSTN GW does. In the same token, a PSTN
GW does not need to use the email IDs, or URL IDs.

[RRR] But we are defining a " GW registration" protocol for broader use. We
are not defining "PSTN GW REGISTRATION" protocol, I believe. There is a
fundamental difference in your understanding how to define the registration
protocol. One MUST not mandate to develop a protocol for such a narrow use.
It will be unacceptable from standardization point of view.

You have a totally different view of what an intra-domain protocol is than I
do. In my view, it is more like the inter-domain problem. I suspect both of
our views are different from others in the group. This problem is not yet
sufficiently defined to start work on protocol specifications.

[RRR] Again, I am saying that there are more than one LS in an ITAD. How do
you say that it is an inter-domain protocol? Does not the TRIP framework
document define that there can be multiple LSs in a given ITAD?

Furthermore,

[RRR] I can rather accept this argument: Whether this is charter item or
not. It appears that the communication protocol between the GWs and the LSs
within an ITAD is a chartered item. However, the communication protocol
among the LSs is NOT a chartered item. (What I am arguing is that the
communications protocol among the LSs will not be a different one once we
complete the communication protocol between the GWs and LSs. I will wait to
see the development of the communication protocol between GWs and the LSs.)

[RRR] Let us define the charter.

-Jonathan R.

---

---

From: "Agboh, Charles" <[email-masked]>
Date: Wed, 28 Nov 2001 19:23:25 +0100

> Sent: Tuesday, November 27, 2001 10:33 PM
> To: 'Roy, Radhika R, ALCTA'
> Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
> 
> 
> 
> 
>  
> 
> Your response is nonsensical. A SIP-H.323 IWF doesn't handle 
> media.   

The SIP-H.323 IWF might be co-located with a Media Switching Fabric for
transcoding or sitting between multicast and unicast domains.  The
Requirements should catter for this type of IWF.    Customer security
requirements might also dictate that we use an IWF with an MSF.  Seems like
SIPPING should give this group input on requirements..

>In that
The capacity of a proxy can be calculated as a function of the media
gateway.   I aggree they are not the same but they are related.  For exmaple
when I want to calculate investments for a call control layer for an IP
Telephony VPN, I might make the following assumptions

-80% of calls are intra-VPN in an Enterprise environment.
- assume a 60% usage rate on each CPE channel
 and
make a plan calculating CCL investment as a function of CPE channels (CPE
channels * 60% * (0.2+1/2*0.8)) (the 1/2 accounts for the fact that for
intra VPN calls (80% here, there is only 1 call in the softswitch for 2 CPE
active channels).....
> gateways. If the solution happens to be sturecutre in such a 

I don't believe that the solution should be focus on CO gateways.   PBX
switches generate very high call volumes between different branch
offices..Scalability and load balancing important requirements for this
environment.  Imagine I have 10 branch offices per customer and my forcasts
is 200 customers by end 2002....
> way that it can