Subject: [Sip] SIP INFO method - Any reason it MUST BE stateless.

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 04 Oct 2001 18:35:17 -0700

Today according to the INFO RFC, the SIP INFO method is stateless,
i.e if server A issues an INFO method on an existing SIP session with
another server B, and the method body contains some data(lets say a
proprietary command, like READFILE abcd.jpg). Server B has to either
    1. come back with all the data read in the body of the 200 OK
response for the INFO method(it may be large or time consuming)
    2. do a 200 OK reponse for the INFO method with an acknowldgement
for the READ command and may be an initial chunk. The server B may have
to send each subsequent chunk of data on a separate INFO method to A,
for which server A has to respond with a 200 OK. This could be highly
inefficient.

I would have prefered to be able to send one INFO method and get back
multiple 18x OK methods carrying the intermediate chunks of data and
have the final chunk carry the 200 OK.

Is there a specific reason why the the INFO method MUST BE stateless.

Because, it looks like the INFO method could be used to get information
that may have to come as multiple chunks.

thanks,
Sarvi

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 04 Oct 2001 21:04:05 -0700

Brett Tate wrote:

> Should work if using 100rel extention, however I'm
> sure some people might be opposed to using the INFO
> for this or for anything.

This is good news.
We would like to use the INFO method for peer to peer communication of
applications on either end of the SIP session.

> It isn't stateless.  The specification mentions
> that it MUST NOT effect call state or the state
> of related sessions.
>

Agreed.
Our requirement is to conduct a request/response conversation between two
application level entities sitting above the SIP stack on either side.
We do not expect any change in call or session state.

Thanks,
Sarvi

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

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 4 Oct 2001 23:43:19 -0400

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 08:04:07 +0300

Hi Sarvi,

In general, I think the issue is related to a similar one we had for
Megaco, where it was discussed how a response could be split into
multiple "provisional" responses if it couldn't fit into a single UDP
package.

Like Brett said, using INFO like this may not be correct, but I guess
that depends on exactly what you want to do. Another way would be for
the UAS to simply return 200 to the INFO, and then send an INFO itself
with the required data. Then, if you can't fit all data into a single
INFO I guess you could split the data into multiple INFOs, using some
attribute to indicate to the receiver when all data has been sent.

No, I am NOT talking about any "INFO overlapping", but completely
separate INFO transactions :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Sarvi Shanmugham <[email-masked]>
Date: Thu, 04 Oct 2001 23:32:48 -0700

Hi Christer,

> Like Brett said, using INFO like this may not be correct, but I guess

Like you have pointed out below using a separate INFO methods for the each
chunk of response data is definitley a possibility.
But, as you might already notice, it is not a very efficient mechanism,
compared to doing it with provisional responses. it uses way more messages
between the two endpoints to accomplish this.

So what I am trying to understand is, if there is some sort pitfall or problem
that people see in, either now or in the future permitting provisional
responses in the INFO method as part of SIP.

Regards,
Sarvi.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 10:09:43 +0300

Hi,

>responses in the INFO method as part of SIP.

Well, there is a thread about the possibility to CANCEL non-INVITE
requests, where it has been discussed if provisional responses should be
allowed for non-INVITE requests in the first place.

When you design your use-case, you have to ask yourself: When the UAC
sends the INFO, and start receiving multiple provisional responses,
should it be allowed to - for whatever reason - CANCEL to INFO at some
stage, before the final response has arrived?

I think the issue here is about splitting message contents betweeen
multiple SIP messages, no matter if they are requests or responses. For
example, it has been agreed that there MUST NOT be any application level
fragmentation of the SIP message. The question you now bring up is:
should we be allowed to do application level fragmentation of message
bodies. It is NOT possible for the SDP, becuase that information is
needed on a SIP stack level. 

Also, if you send application data in the message body, and the
defragmentation is done on an application level, the stack probably
wouldn't even know - and probably wouldn't even care - if the message
bodies in the different messages belong together or not.

However, if you want the defragmentation to be done on the stack level I
guess we have an issue, and if you want to do this you definately need a
Require option-tag, to make sure both endpoints support it.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 5 Oct 2001 10:54:20 -0400

Hi,

As Christer points out, there has been some debate as to whether provisional
responses should be allowed for non-INVITE transactions (with the exception
of 100-Trying). This is related to "Open Issue #7: CANCEL for non-INVITE".
Although consensus has not been declared, it appears to me that the SIP WG
is leaning toward not allowing provisional responses to non-INVITE requests
and not allowing CANCEL for non-INVITE transactions. Therefore, it may turn
out that you will be required to answer an INFO request with a more-or-less
immediate 2xx response.

But I think there is another way. Maybe you could borrow the "206 Partial
Content" response code from HTTP. You could use that in your INFO response
to indicate that there is more data that the client needs to request. You
may need to include some information in the body of the response for the
client to include in the body of subsequent requests so the server could
correlate the requests and know which chunks had been sent. In other words,
the state would be in the body and the defragmentation would have to be done
by a user agent that understands the body. To any proxies along the way,
each INFO would look like an ordinary non-INVITE request.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 15 Oct 2001 23:02:15 -0400

My biggest question is, are you thinking of transporting signaling
information in the INFO body?

If not, why use SIP at all?  Are there magic proxies that need to see these
messages (i.e., justify on routing)?

I would offer that there are other protocols one could use.  One choice
would be http if your problem is large messages.  Another would be to use
the NOTIFY message, if what you are trying to accomplish is notification of
status changes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sarvi
Shanmugham
Sent: Thursday, October 04, 2001 9:35 PM
To: [email-masked]
Subject: [Sip] SIP INFO method - Any reason it MUST BE stateless.

thanks,
Sarvi

---

From: Sarvi Shanmugham <[email-masked]>
Date: Mon, 15 Oct 2001 23:12:44 -0700

Hi Eric,
    This is not to carry signalling information. The scenario that we are
looking at is to setup a SIP session to a media server with a 2-way RTP stream
to it.
    SIP is used for setting up this session.
    The INFO method would be used to carry commands/information/responses
between the applications sitting at either end of the SIP session.

Sarvi