Subject: RE: comments on SIP INFO last call

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 26 Jan 2000 17:53:30 +0000

Tim,

Thanks for the thorough review of the draft.  Please see my comments below
preceded by SRD>.

Regards,

Steve

> -----Original Message-----
> From: Schroeder, Tim [mailto:[email-masked]]
> Sent: Tuesday, January 25, 2000 4:50 PM
> To: [email-masked]
> Subject: comments on SIP INFO last call
> 
> 
> A few comments on the draft-ietf-sip-info-method-01.txt:
> 
> [1. Introduction]  The introduction says the INFO method merely sends
> "optional application layer information".  But some of the 
> uses of the INFO
> method (carrying PSTN signaling messages, e.g.) are not 
> really optional.
> Maybe optional in the sense of the session state, but not 
> optional in the
> sense of getting things to work.

SRD> It is true that INFO is required for SIP to PSTN interworking.
However, the definition of this interworking is outside the scope of the
INFO specification.  There will need be a separate draft that defines the
required behavior of entities impacted by interworking with the PSTN.  Just
as there will need to be a separate specification that documents any other
use of the INFO method.

> 
> [2.2 Responses to the INFO Request Method]  A 200 OK message 
> must be sent
> for an INFO request with no body.  A 200 OK message must be 
> sent if the body
> is understood, but there are no rules for processing it.  I 
> guess if the
> body is not understood at all (I'm not sure how that differs from the
> previous case), the action falls "outside the scope of this 
> document".  (1)
> I would like clarified what an "understood" body is, as opposed to a
> non-understood body, and how the presence/absence of rules 
> for handling the
> body affects this.  Wouldn't a body with no rules defined be "not
> understood"?  (2) Would it be correct to at least demand that 
> the server
> return some sort of final response on receipt of an INFO 
> message, even if
> the determination of the particular response sent is outside 
> the scope of
> the document?  The sender ought, I think, to be entitled to 
> receive a final
> response of some sort on any INFO method.  (3) Section 2 says the
> mid-session information can be sent either as a message body 
> or as message
> headers.  If so, why does the response handling vary 
> depending on which of
> these ways is chosen?  (So, if the mid-session information is 
> carried in
> headers, the draft mandates a 200 OK response, but if the 
> same information
> is carried in a body, the response is "outside the scope of 
> this document".)

SRD> This section was attempting to define the default behavior of 
a UAS upon receipt of the INFO message.  I agree that it is a little 
unclear in the case that a message body is received that it does not
recognize.  As you correctly state, this is the similar to receiving an
INFO message with no message body, although I don't think it is 
quite the same.  It seems that the UAC should be able to known that 
the UAS does not understand the message body sent.  

SRD> Clearly a final response is needed in all cases.  The default 
behavour is to send a 200 OK if the INFO cooresponds to an existing
session at the UAS and there is no message body or the message body
can be processed by the UAS.  In the presence of an message body 
that is not understood the default behavour should be for the UAS to
send a 415 Unsupported Media Type, which is realy saying Unsupported
Message Body.  Otherwise a 481 response is sent.  Any other 
rules as to handling of the INFO message are going to be application
specific.

SRD> I propose changing the first part of section 2.2 to the folloiwng:

"If a server receives an INFO request it MUST send a final
response.  

A 200 OK response MUST be sent by a UAS for an INFO request with
no message body if the INFO request was successfully received for
an existing call.  Beyond that, no additional operations are
required.

Handling of INFO messages that contain message bodies is outside
the scope of this document.  The documents defining the message
bodies will also need to define the SIP protocol rules associated
with those message bodies.

A 481 Call Leg/Transaction Does Not Exist message MUST be sent by 
a UAS if the INFO request does not match any existing call leg.

If a server receives an INFO request with a body it understands,
but it has no knowledge of INFO associated processing rules for
the body, the body MAY be rendered and displayed to the user. The
INFO is responded to with a 200 OK.

If the INFO request contains a body that the server does understand 
then, in the absense of INFO associated processing rules for the 
body, the server MUST respond with a 415 Unsupported Media Type
message."

> 
> 
> [X. Reliability]  I think a short reliability section should be added,
> similar to that in RFC2543.  Should 200 OK or other final responses be
> retransmitted (I think not).  Should a client retransmit an 
> INFO method if a
> final response is not received (I think yes).

SRD> This is addressed in the following from section 2.4:

"Unless stated otherwise, the protocol rules for the INFO
request governing the usage of tags, Route and Record-Route,
retransmission and reliability, CSeq incrementing and message
formatting follow those in [1] as defined for the BYE request."

> 
> [2.2 Responses to the INFO Request Method]  (Not really a 
> "comment", but a
> "nit".)  The two "tables" are labeled "figures", though they 
> are referred to
> as "tables" in the text.  They are consistently called and 
> labeled "tables"
> in RFC2543.

SRD> Oops.  

> Tim Schroeder

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jan 2000 02:36:02 -0500

> SRD> It is true that INFO is required for SIP to PSTN interworking.

Well, its not REQUIRED. We have SIP to PSTN interworking now and its
doing just fine without INFO. The INFO method is only needed when ISUP
transparency is desired. The point this statement is making is that you
cannot use INFO for features which are mandatory in order for the
session to stay up correctly. This is because INFO is an optional
extension; a UAS may terminate a call, set it up, and then receive INFO,
but not understand it. This cannot be a catastrophic call failure.
Perhaps this should be clarified.

> the UAS does not understand the message body sent.

This particular tidbit was my suggestion, so the fault is mine in its
unclarity. What it means "when an INFO body is understood, but no
specific rules exist for processing", is that the UAS knows how to
process this body when present in other messages, but no specific
behaviors are known for INFO. An example is text/html. When received in
a redirect, a UA knows to display it. What does it mean when its in
INFO? Unless some spec says otherwise, display it also.

> 
> SRD> Clearly a final response is needed in all cases. 

I think the spec already basically says this...

> body, the server MUST respond with a 415 Unsupported Media Type

Looks good to me.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com