Subject: Re: [Fwd: RE: [Sipping] I-D ACTION:draft-ietf-sipping-kpml-02.txt]

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Feb 2004 02:06:52 -0500

Eric Burger wrote:
> Not registering does not stand in the way of using gruu:
> draft-ietf-sip-gruu-01 offers that gruu generation is pure magic.  It
> is *suggested* to be done at a registrar to ensure routability,
> uniqueness, etc.  However, "other means" work just as well (just not
> as likely to work globally).  The gateway can generate its own gruu
> without registering.

Local GRUU generation is really a dangerous thing. The GRUU MUST be 
obtained from the owner of the domain, and furthermore, it must be 
obtained from a domain that hads out AORs. A gateway generally is not 
the element with authoritative ownership of the domain in which it 
resides. It is the authoritative owner of the domain corresponding to 
its local IP address, but this domain does not hand out AORs and won't 
itself generally be reachable.

> 
> That said, a typical deployment scenario for KPML is signaled digit
> transport between media gateways/controllers and proxies in private
> networks and IP Phones and IP PBXen in private networks.  In these
> scenarios, gruu doesn't buy you anything.  Moreover, it would clearly
> be "easier" to just make the request on the INVITE dialog, as that is
> supposed to go to the right place by definition.

No, please no.

Using SUBSCRIBE on the same dialog leads us down the road of dialog 
reuse. THis is something that many discussions over the years have 
covered, and its clear by now that they are a bad idea. Here's an 
example for your specific case - if I send a SUBSCRIBE that times out 
for some reason, does this terminate the dialog (normally yes), but what 
about the call? Does a BYE terminate the subscription and the call? If 
the subscription ends does the call end?

Using a separate dialog for the subscription, even to the same endpoint, 
eliminates these problems. While I agree that we can't eliminate dialog 
reuse for usages that are already defined, this is a new one, and we are 
in a position to not go down the road of dialog reuse.

> 
> So...
> 
> What direction should we go with KPML?
> 
> Option 1: "You MUST use gruu 

Yes.

>(even if you fake gruu generation)

No. Bad thing.

> and
> you MUST create independent SUBSCRIBE dialogs for the subscription."

Yes.

> If your UA doesn't support gruu, you can't use KPML.  If you are in
> the gateway or IP PBX scenario, feel free to cheat at your own risk.
> My guess is IP PBX guys will make this optimization as a proprietary
> (not necessarily interoperable) extension.

What is being optimized? There are many known issues with dialog reuse.

> 
> Option 2: "You SHOULD use gruu and SHOULD create independent
> SUBSCRIBE dialogs for the subscription."  KPML keeps the
> documentation for how to do the subscription on the INVITE dialog.
> KPML documents the evils and dangers of issuing subscriptions on
> INVITE dialogs.  The problem here is there is no protocol way of
> knowing for certain that reusing the INVITE dialog will work.  You
> only know from your network topology whether it is a good idea or
> not.  The good news is for the scenarios described above, it will
> work.

I don't like this option.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP