Subject: [Sipping] Request / Response (RPC-like) exchange in SIP?

From: [email-masked]
Date: Mon, 18 Sep 2006 13:54:16 -0400

Hey all,

Is there any interest now or has there been discussion in the past on a
SIP extension that supports a request/response (RPC-like) dialog? If so,
would someone be willing to summarize the outcome of such a discussion.  

What I'm thinking is a SIP method that could be used to construct a simple
Request/Response dialog between two endpoints. In principal, I suppose it
could be designed to support a more extended dialog of request/response
messages, but a single request/response would be the norm. 

The intent would be to provide SIP with a mechanism for doing a kind of
RPC, very much the way Web-services based architectures use HTTP GET/POST
dialogs to implement an RPC mechanism.

I know this may sound like heresy, but my desire for such a mechanism is
based on the utility of RPC within the context of a SIP service control
network. That is, for certain types of services there are times when you
want to do an RPC-like request/response transaction from one endpoint to
the other (e.g., perhaps to perform a commercial service purchase
transaction between two parties). In a converged services framework, say
based on SIP, it'd be convenient to be able to do this with SIP, rather
than via some other (parallel) signaling protocol (e.g. web-services), so
that the service signaling can a) be managed by a single protocol and b)
travel a common signaling path for the purposes of service tracking and
settlement.   ..hence my question.

I can imagine trying to use existing SIP mechanisms for this purpose, such
as Subscribe/notify, info, or message, but none of these seems designed
for this purpose.

So what do people think about an RPC-like request/response mechanism for
SIP?

Oh wait a second.... 

........... ok, I've got my fire retardant suit on.... 

... flame away!

-Steve

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Mon, 18 Sep 2006 14:17:27 -0500

> would someone be willing to summarize the outcome of such a  

How about:

http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-deason- 
sipping-soap-sessions-00.txt

--
Dean

---

From: [email-masked]
Date: Mon, 18 Sep 2006 15:39:15 -0400

From: [email-masked]

Interestingly, we've just been discussing this on the MIG mailing
list.  My position is that there are occasional needs for "RPC-like"
requests, and that all of the existing SIP methods carry implicit
assumptions which are violated by RPC-like requests.  Hence, I am
advocating the creation of a new method.

Dale

---

From: <[email-masked]>
Date: Mon, 18 Sep 2006 22:51:53 +0300

Hi,

I agree that there are several use cases for this type of method. It
seems that there are actually very few solutions that would allow a
client to reach a server that is on a host that does not have a
permanent DNS entry and is behind a NAT. People are already using
MESSAGE and INFO for this, so why not specify something that is really
intended for the purpose.

Markus

>-----Original Message-----
>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 18 September, 2006 22:39
>To: [email-masked]
>Subject: Re: [Sipping] Request / Response (RPC-like) exchange in SIP?
>
>Interestingly, we've just been discussing this on the MIG 
>mailing list.  My position is that there are occasional needs 
>for "RPC-like"
>requests, and that all of the existing SIP methods carry 
>implicit assumptions which are violated by RPC-like requests.  
>Hence, I am advocating the creation of a new method.
>
>Dale
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: Shida Schubert <[email-masked]>
Date: Mon, 18 Sep 2006 17:19:42 -0700

Considering any widely adopted protocol ends up being a transport
protocol and SIP being no exception to this, it might be worth while
to evaluate something explicit for use described below.

Regards
Shida