Subject: RE: Gateways and registration

From: Linden deCarmo <[email-masked]>
Date: Fri, 7 Jan 2000 14:42:08 -0500

>True, it would require some interesting syntax but I believe the
semantics
	>he had in mind are different. The problem he is trying to solve is
not
	>registering a gateway that is capable of answering for a set of
users, but
	>more simply, registering the fact that a given gateway is up and in
service.
	>The set of users that a given gateway can support would then have
to be
	>either statically configured or negotiated through some different
protocol
	>such as TRIP. 

This is EXACTLY what I'm trying to solve Sean. 

I'd prefer to do it in SIP rather than a companion protocol, because we're
trying to interface with 3rd party gateways that may/may not talk TRIP.

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jan 2000 15:33:47 -0500

> trying to interface with 3rd party gateways that may/may not talk TRIP.

I don't see why they would be any more likely to behave properly in a
non-standard usage of REGISTER. TRIP handles keepalives; its keepalive
mechanism is quite flexible (borrows from BGP, actually), and you also
get the routing information you need. IMHO, I'd rather solve the general
problem with a solid solution than make many small extensions to SIP
here and there to solve only a subset of the real problem.

A complete VoIP solution requires many components. The general approach
we have taken into IETF is to break the various components into
independent, manageable pieces, and then define protocols for solving
each of those pieces. By keeping these pieces standalone and
independent, we can swap in different versions or alternatives down the
road without affecting other components. This helps tremendously in
extensibility and growth; we have seen this in routing protocols, for
example (separation of intra and inter domain protocols, even though
both run on a router). It also means we can optimize the solution for
the problem at hand. 

For many different reasons, some of which have already been outlined
here, the SIP REGISTER method is not a good tool for gateways to use. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Jan 2000 11:30:24 -0600

All

Parallel question on the reliance of TRIP -- isn't it based on using BGP? If
that is strickly true, what happens to the SIP Device if BGP isn't deployed
within a VoIP network domain that still wants to locate the Gateway?

>here, the SIP REGISTER method is not a good tool for gateways to use. 

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jan 2000 13:56:18 -0500

"James M. Polk" wrote:
> 
> All
> 
> Parallel question on the reliance of TRIP -- isn't it based on using
> BGP? If that is strickly true, what happens to the SIP Device if BGP
> isn't deployed within a VoIP network domain that still wants to locate
> the Gateway?

TRIP borrows many ideas from BGP, but it in no way whatsoever requires
BGP to actually be running on routers in the network. TRIP runs at the
application layer, between location servers. It doesn't matter one drop
what the underlying layer 3 routing protocols are.

-Jonathan R.

---

From: "Matt Squire" <[email-masked]>
Date: Tue, 18 Jan 2000 14:11:13 -0500

> isn't deployed within a VoIP network domain that still wants to locate

The TRIP protocol is based on BGP, meaning it looks alot like BGP.  But
it isn't BGP - ie its not compatible with routers running BGP, you don't
have to have be an AS to run it, etc.  Its deployment is indepent of any
IP routing protocol.  

- Matt