Subject: RE: [Sipping] GRUU in KPML

From: "Eric Burger" <[email-masked]>
Date: Fri, 26 Mar 2004 07:59:43 -0500

Agreed.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, March 25, 2004 4:26 AM
> To: Adam Roach
> Cc: Ben Campbell; Eric Burger; Sipping (E-mail)
> Subject: Re: [Sipping] GRUU in KPML
> 
> 
> 
> 
> Adam Roach wrote:
> 
> > Ben Campbell [mailto:[email-masked]] wrote:
> > 
> >  > I can imagine a use case where my call is signaled by a 
> device with a
> >  > minimal user interface, but KPML interaction is handled 
> by a separate
> >  > device with a richer interface, such as my PDA or PC. This
> >  > would be much  more simple to accomplish if I could 
> specify a KPML
> >  > target that was distinct from my dialog contact.
> > 
> > If you want to do something like this, then sending a 302 response
> > to an incoming SUBSCRIBE for kpml events could be used to 
> achieve the
> > effect you describe above.
> > 
> > This is probably a rather rare use case, so I imagine that slightly
> > suboptimal signaling is okay.
> 
> I don't think a redirect is enough. The device with the UI 
> needs a way 
> to authorize the subscription. Authorization is done by 
> making sure that 
> the subscriber knows the dialog identifiers. However, the 
> dialog doesnt 
> exist at this UI device, so it would have no way to do authorization. 
> Also, when the dialog ends, the subscription needs to be 
> terminated, and 
> this device has know way to know that either.
> 
> So, making this work would require a bunch of additional signaling 
> between components that we dont do now. I think that this kind of 
> decomposed system is the subject of protocols like mbus, and 
> we should 
> consider the whole nine yards just plain out of scope here.
> 
> Thanks,
> 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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 Mar 2004 09:13:45 -0600

I will reiterate that I accept it if consensus says not to worry about 
this. However, I do have to point out that there is a big difference 
between specifying everything necessary to make such a decomposition 
work, and making choices that prevent it from working.

Now I will shut up about it :-)