Subject: RE: [IPTEL] RE: more on iptel-gwreg-req

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Sat, 8 Dec 2001 07:19:18 -0500

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Saturday, December 08, 2001 3:49 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; Jonathan Rosenberg
Subject: [IPTEL] RE: more on iptel-gwreg-req
Comments are inline [RRR]

> 
> 2. I think in terms of model there is not such a great
> difference in terms of presentation between what a
> pstn-sip, sip-323 or sip-xyz - in all cases some
> basic building blocks must be communicated - and
> they are captured in the requirements
> (e.g. Media/Resource Capabilities, Termination
> Capabilities, and status).

I have no problem if the protocol happens to be flexible enough to support
all sorts of gateways; 

[RRR] Finally, it is a very good news that we have made an agreement that the protocol will be flexible enough to support all sorts of gateways. This must be our main focus of the protocol. Let us work and develop our protocol meeting this primary requirement without excluding any types of GWs.

separating attributes from the protocol that communicates them is generally good design and characteristic of all the
proposals thusfar.

[RRR] I have seen a concrete proposal yet in this direction.

However, to keep the scope reasonably contained, we are focusing on pstn-ish kinds of gateways to help us drive requirements.

[RRR] We have provided the contribution 
(http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-registration-00.txt) that shows other kinds of gateways (e.g., SIP-H.323 IWF) do not need anything extra other than few fields in addresses. So, it proves that it meets scope (by the way, a PSTN-ish kinds of GWs are highly complex so far the capacity attributes are concerned - other Gas have little to do with these kinds of complexities). If anyone has any problems to include other types of gateways, let them put forward technical quantitative arguments without falling back to the subjective explanations.

-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

__

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 10 Dec 2001 09:51:34 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roy, 
> Radhika R, ALCTA
> Sent: Saturday, December 08, 2001 7:19 AM
> To: Jonathan Rosenberg; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [IPTEL] RE: more on iptel-gwreg-req
> 
> 
> 
> 
> difference in 
> > terms of presentation between what a pstn-sip, sip-323 or 
> sip-xyz - in 
> > all cases some basic building blocks must be communicated - and
> I have no problem if the protocol happens to be flexible 
> enough to support all sorts of gateways; 
> 
> [RRR] Finally, it is a very good news that we have made an 
> agreement that the protocol will be flexible enough to 
> support all sorts of gateways. This must be our main focus of 
> the protocol. Let us work and develop our protocol meeting 
> this primary requirement without excluding any types of GWs.
>
Actually, this is *not* how I read what Jonathan wrote. I interpret his
suggestion that we not make flexibility across any kind of gateway a
goal for the protocol (where do you stop?), but rather that he would not
find it objectionable if such flexibility happened to fall out of a
design optimized for straightforward PSTN gateways.

On this point I am inclined to agree with Jonathan. To try to deal with
IP-IP 
Protocol conversions boxes like SIP<->H323 we would be treading into
very dangerous water, IMHO. Not only does this introduce the possibility
of combinatoric explosion of routing information (i.e. the need to
represent routes for each combination of protocol P and protocol Q for
all values of P and Q), but if you actually want to make use of this
information it also leads inexorably to a route computation which is
equivalent to solving boolean satisfiability problems (e.g.find me the
best route by between two gateways which minimizes administrative cost
and number of protocol conversions in between).

Beyond this, there are two further dangers: 

- creeping into representing which PSTN signaling protocols a gateway
supports in order to be sure that you don't lose features when crossing
into the PSTN (e.g. prefer an ISUP speaker to a Q.931 speaker, and I'd
really like Q.Sig while I'm at it).
- creeping into trying to solve most if not all of the middlebox control
problem.

Dave.