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

From: [email-masked]
Date: Thu, 6 Dec 2001 17:52:01 -0500

Friends,

I think some clarification on my position are in order.

1. I think Jonathan has done a great job nailing down
on what the requirements are for GW registrations

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).

3. I claim the presentation of this information
(the schema) and the means by which it is communicated
(the protocol) are two very distinct and separate subjects.

My suggestion therefore is:

A. that we define a schema, based on XML, that can be used
to describe the capabilities/status of a GW, including internal
"bundling" (e.g. these 23 trunks are a T1 group running PRI etc)

  ( I don't differentiate between the GW running out of
  capacity and the administrator deciding to disable G.723 because
  it sounds bad - or allowing +1212* while blocking +1900* -
  all change the presentation of the GW to the network. )

B. that we document how this document is transmitted between
network elements (SIP GWs and elements that need to know, including
other SIP GWs), I see three ways here:

   B1: provide the document as part of REGISTER, re-REGISTER when
       information changes.

   B2: allow the element that would like to know to SUBSCRIBE to the
       document, therefore getting NOTIFYied when the document changes
       (including a first NOTIFY with the document immediately following
        the SUBSCRIBE).

   B3: define protocol TRIP+-XYZ that is used to distribute these
       documents between elements "that need to know".

C. Define the rules by which multiple documents are aggregated
(probably with hints in the schema) so border elements can provide
a "digest" of what multiple elements behind them support.

Lastly - I think the work should be prioritized, giving highest
priority to A, B1 and C - to solve existing deployment issues that
already exist.

- gur

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

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 7 Dec 2001 08:30:37 -0500

Hi, Gur:

I agree with your proposal in articulating how we should develop the protocol. In fact, we have also been talking along the same line. 

"If a SIP call comes to a SIP proxy from a SIP user and the destination address does not reside in the SIP-based VoIP network administered by the same VoIP service provider (e.g., intra-ITAD or intra-domain), the SIP Proxy/Location server needs to find or select a GW to which the SIP call need to be sent."

To solve the above problem, it is seen that a protocol is needed in the intra-ITAD (e.g., people have given a code name "Gateway Registration Protocol" or like this). I agree with you that Jonathan has done a great job in formulating the discussion for the requirements.

Please see my comments provided inline [RRR].

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 06, 2001 5:52 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [IPTEL] more on iptel-gwreg-req

Friends,

[RRR] I agree and, that is why, we are having discussions how the protocol needs to be developed.

[RRR] You are right. That is, the requirements clearly say that the protocol should not be "hard-wired" for any particular type of GWs or addressing schemes or otherwise. It is rather Media/Resource Capabilities, Termination Capabilities, status, etc.

[RRR] In TRIP, the protocol has been defined. However, the presentation of the information (the schema) has not been a part of the specifications. It is a good point and let us discuss this. (BTW, in SIP, we could do this. However, SIP's registration message, as suggested by you, could allow to do this, but it needs changes in SIP.)

[RRR] No existing proposal uses XML-based documents. (This can be used if the protocol structure is modified.)

[RRR] Both ITRP and TRIP-GW proposal allow this. (However, TRIP-GW proposal needs to be extended for other addresses like email IDs, url IDs, etc. as well. That is, it should be generic and extensible.)

[RRR] None of the existing proposals allow this capability unless the protocol structure is changed.

[RRR] One suggestion, as I made before, has been to combine ITRP + TRIP-GW proposal.

[RRR] It is possible to do so with the existing proposals with messages (e.g., REGISTER-like, or re-REGISTER-like messages). However, they do not use XML documents etc.

[RRR] It is a good proposal. Now we have to see how we can achieve these objectives using the proposed protocol. The only thing is that the use of XML-based document may require a new structure of the protocol. We need to discuss this and I am open to suggestions.

- gur

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 8 Dec 2001 03:48:53 -0500

> Subject: more on iptel-gwreg-req
> 
> 
> Friends,
> 

Not really, but thanks.

> Capabilities, and status).

I have no problem if the protocol happens to be flexible enough to support
all sorts of gateways; separating attributes from the protocol that
communicates them is generally good design and characteristic of all the
proposals thusfar. However, to keep the scope reasonably contained, we are
focusing on pstn-ish kinds of gateways to help us drive requirements.

> (the protocol) are two very distinct and separate subjects.

Surely.

> "bundling" (e.g. these 23 trunks are a T1 group running PRI etc)

Ahh, XML. Shall we launch into the endless, non-terminating,
working-group-destructing debate about XML v. binary v. ASCII text now? I
think not.

Contributions on the kinds of data that we need to support various gateway
registration scenarios is most welcome. Comments like, "we need to support
the notion of trunk groups and define capacities measured in units of DS0 on
such groups" are useful. Knowing the type of data you have to represent is
generally the first thing you do before deciding a format, rather than the
other way around. 

>    B1: provide the document as part of REGISTER, re-REGISTER when

Well, if you used REGISTER it would not be the REGISTER I know of. The
semantics that you are discussing here don't match at all. There is no
update of contacts. There is no establishment of bindings. The sip group has
elected to move away from pushing data in REGISTER messages. I see little
reason to go back there.

>        (including a first NOTIFY with the document 

I can think of a million ways to send data between X and Y. A PUB/SUB
mecahnism is useful only when the identify of the set of things that wants
to know is unknown to the thing which is letting people know. Seems like
thats not the case here.

-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: "Agboh, Charles" <[email-masked]>
Date: Sat, 8 Dec 2001 13:55:00 +0100

> From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Sent: Saturday, December 08, 2001 1:19 PM
> To: Jonathan Rosenberg; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [IPTEL] RE: more on iptel-gwreg-req
> 
> 
> 
> 
> 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]
> 
> > 
> 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 
PSTN-ish gatweays would help start requirements.   If the  information about
the capability of other gateway types already exist then why not use those
as drivers as well (at least it would help to cover gatways in that
category; i.e.  SIP-Layer 5 gateways)?  
 
> [RRR] We have provided the contribution 
> (http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-ser
ver-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.
---

__

---

From: [email-masked]
Date: Sat, 8 Dec 2001 14:38:20 EST

Not for sure if this is the place to pose this question or not, but since 
this kinda has to do with gateway regestration, I figure why not...

With the induction of multiple manufacturers Voice GW's into (a) carrier's 
network, is there a linearity somewhere either in a RFC somewhere for VoIP, 
or is there a record formatting contingency in whichever RouteServ a carrier 
uses, or is this yet to be deceided...

AMA Records (and the collection thereof from G/W's, and/or LocServ's), Call 
completion codes (and the completion of G/W's Onnet SIP Vs. Offnet TRIP) or 
in general just anything that would have to do with CDR's??

---

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

OK, I'm now lost. I thought we were designing a registration protocol
that allows the routing system to DO SOMETHING with the data. If not,
then we could use just about any extensible AVP-based description scheme
and not worry about the semantics of the data. Hell, we could even
register the color of the cable sockets so that you could route from
yellow to yellow.

The unstated point behind my note (unstated because I thought it was too
obvious to bother stating) was that anything we registered in the GW
registration protocol had to have a reasonable projection into at least
the intra-ITAD routing scheme.

If I'm wrong here, I apologize.

Dave.

> Sent: Monday, December 10, 2001 10:34 AM
> To: David R. Oran; Jonathan Rosenberg; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 9:52 AM
> To: Roy, Radhika R, ALCTA; 'Jonathan Rosenberg'; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Roy, 
> > Radhika R, ALCTA
> > Sent: Saturday, December 08, 2001 7:19 AM
> > 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; 
> > 
> 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.
> 
> [RRR] We are talking about the registration protocol for GWs 
> and a GW is characterized by some attributes by the keeper of 
> some destiantion addresses, capacities, etc. We are 
> generalizing these features. By the way, in an ITAD, we are 
> NOT talking about rotuing or route propagation etc. like 
> this. We are talking about registration of all attributes 
> that a GW might have. We are NOT for standardizing the 
> SIP-ISUP GW registation protocol per se.
> 
> 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).
> 
> [RRR] By the way, we are not considering anything like 
> protocol conversion or routing or progation of routes or 
> route aggregation in registartion. So, the points that are 
> being raised from the protocol "CONVERSION" point of view are 
> out of question. The characteristics of the SIP-ISUP GW is 
> generalized enough to falsh out the requirements for 
> development of the registration protocol that is good for all 
> types of GWs. The SIP-ISUP GW is highly complex especillay 
> its capacity attributes while the other GWs are very simple. 
> So, the GW registration protocol that we are developing will 
> be good enough for all types of GWs if it can satisfies the 
> requirements for the SIP-ISUP GW - all we need to do is to 
> add additional field in the address space that include email 
> IDs, URL IDs, etc.
>  
> [RRR] Again, please note that we are NOT considering routing, 
> routing propagation or route aggression that are required for 
> inter-ITAD or inter-Domain protocol. That is why, inter-ITAD 
> protocol like TRIP is so complex. We are considering the 
> "registration" of addresses, capacitiy attributes, etc only.
> 
> 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).
> 
> [RRR] We considering registration protocol of the GW, not the 
> inter-doamin protocol TRIP. The registration protocol will be 
> able identify whether it is a SIP-ISUP GW, SIP-H.323 GW, etc. 
> Once it is identified, each will deal with the corresponding 
> GW accordingly. The protocol will have the capability to 
> satisfy the requirements as appropriate.
> 
> [RRR] Again, please note that we are NOT develoiping the 
> "SIP-ISUP GW Registration" protocol. We are rather developing 
> the GW registration protocol where each type of GW will be 
> able to register their attributes as appropriate.
> 
> - creeping into trying to solve most if not all of the 
> middlebox control problem.
> 
> [RRR] It is a separate issue and is the same all types of GWs 
> including the SIP-ISUP GW.
>  
> 
> Dave.
>