Subject: Re: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt

From: "Neil Deason" <[email-masked]>
Date: Wed, 02 Aug 2000 23:14:34 GMT

>I don't see this as RPC in the classical sense. There are two aspects:

I think the statement 'SIP is not for RPC' as a guideline
to using/extending SIP is not sufficiently qualified.
SIP is certainly not a high efficiency or general purpose
RPC mechanism but some things which could be interpreted
as RPC-like might still be valid uses for SIP.

>- action (MESSAGE) to affect lightbulb state;'
>
>- events to obtain lightbulb state.
>
>Thus, this is very similar to sending text (chat) messages and
>subscribing to user status changes (events). Particularly in the event
>case, the usual SIP advantages apply, including that the watcher may be
>mobile (Speaking from personal plumbing accident experience, I want to
>be notified when the home temperature drops below threshold regardless
>of my location).
>
>There are some nice secondary benefits to this: existing SIP message and
>notification tools can be trivially extended to handle this. I can put
>my washer in my address book and be notified when the wash is ready.
>
>Also, existing tools such as sip-cgi and CPL are quite useful for this
>space.
>
>Since this doesn't require any SIP extensions, it seems (hopefully)
>harmless.

One thing that is not clear to me is the relationship between
what is referred to as a service provider proxy and home
domain proxy with respect to REGISTERs/message routing. In
the simple access from home to work example the draft refers
to a UA in the home domain registering with the home domain
proxy and this information being propagated to the service
provider's domain. Without that occurring I can't see the message
routing between the two proxies in the subsequent call flow
working. Unfortunately there is no mechanism in SIP for this
propagation. So either the two proxies have another non SIP
based relationship between them or SIP would need extending
to accommodate such a mechanism.

Cheers,
Neil.
--
Ubiquity Software, UK
www.ubiquity.net
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Aug 2000 19:57:45 -0400

> as RPC-like might still be valid uses for SIP.

Since most any protocol, including HTTP and SMTP (or RTP and SNMP), can
be replaced by RPC in some sense (and thus serves as an RPC mechanism),
the statement probably does need to be qualified.

> to accommodate such a mechanism.

That's actually a more general problem, I believe. In some cases
(mobility), it would be nice to proxy a REGISTER to the provider, yet
have the proxy "remember" this registration.

Henning

---

From: Stan Moyer <[email-masked]>
Date: Thu, 03 Aug 2000 10:00:21 -0400

At 11:14 PM 8/2/2000 +0000, Neil Deason wrote:
One thing that is not clear to me is the relationship between
>to accommodate such a mechanism.

The draft is a little hand-wavy on this because we werre not entirely sure 
how to make it happen, but I don't think this case is specific to networked 
appliances.

Our thoughts on how to do this would be for the UA in the home domain to 
REGISTER with it's home domain proxy, then do a DNS look-up and check the 
SRV record to see if there is another SIP Proxy listed for it. If there is 
(e.g., the service provider proxy), then it should also REGISTER with that 
proxy. Is this allowed -- we do not see why not?

-Stan