Subject: Re: [SIP] Session header

From: Rohan Mahy <[email-masked]>
Date: Wed, 02 Aug 2000 08:11:13 +0200

Hi,

Just wanted to clarify this, since you didn't include syntax, that the
original contents of the Session header (qos, security, media) would become
parameters to the session disposition?  and you could add one or more of
these session "purposes"?

Example using manyfolks qos and security:

	180 Ringing
	...
	Content-type: application/sdp
	Content-disposition: session;qos;security;handling=required
	Content-Length: ...
	...
	a=qos: mandatory sendrecv confirm
	a=security: optional sendrecv confirm

Old Syntax:

Content-Disposition = "Content-Disposition" ":" disposition-type *(";"
disposition-parm)
disposition-type = "render" | "session" | extension-token
disposition-parm = handling-parm | parameter
handling-parm = "handling" "=" ( "optional" | "required" | other-handling )
other-handling = token

New Sytax:

Content-Disposition = "Content-Disposition" ":" disposition-type *(";"
disposition-parm)
disposition-type = "render" | "session" | extension-token
disposition-parm = handling-parm | session-parm | parameter
handling-parm = "handling" "=" ( "optional" | "required" | other-handling )
other-handling = token
session-parm = "qos" | "security" | "media" | token

session-parm is only valid with the "session" disposition-type.

Is this the idea?

thanks,
-rohan

At 08:07 AM 7/28/00 , Jonathan Rosenberg wrote:
>The authors of the 183 draft discussed this and we came to the following
>conclusion:
>
>1. The Session header would be eliminated, rather its values would be
>folded in as a parameter of the Content-Disposition header.
>2. These parameters would be defined in the rfc2543bis draft.
>
>Since the header is optional, and since it is such a small thing and
>related to Content-Disposition anyway, folding it into the bis draft
>seemed best.
>
>Comments?
>
>-Jonathan R.
>
>Rohan Mahy wrote:
>> 
>> Hi,
>> 
>> The Session header was defined originally in the 183 draft.  Now that the
>> 183 has expired (?), the 183 response has moved into the bis draft, but the
>> Session header has not. Can we still move the Session header into the bis
>> draft?
>> 
>> thanks,
>> -rohan
>> 
>> _______________________________________________
>> SIP mailing list
>> [email-masked]
>> http://lists.bell-labs.com/mailman/listinfo/sip
>
>-- 
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip
>

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

---

From: "Steve Donovan" <[email-masked]>
Date: Wed, 2 Aug 2000 11:34:54 -0500

> these session "purposes"?

I'm not sure it is necessary to specify QoS and Security.  The real need for
the additional parameter in the content-disposition header (the old session
header) is to indicate that the message body contains preconditions.  The
indication of preconditions tells the SIP state machine to delay alerting
the user until the preconditions have been met.

Specifying QoS and Security as reasons for the preconditions means that the
protocol will need to be changed with other precondition reasons need to be
added.

In addition, QoS and Security would only need to be included in the header
when the SDP strength-tag is mandatory.  There is no value to the SIP state
machine to know that there are QoS attributes in the SDP when the
strength-tag is set to optional.

> session-parm is only valid with the "session" disposition-type.

I would suggest a parameter that is something like:

Content-Disposition = "Content-Disposition" ":" disposition-type *(";"
  disposition-parm)
disposition-type = "render" | "session" | extension-token
disposition-parm = handling-parm | session-parm | parameter
handling-parm = "handling" "=" ( "optional" | "required" |
other-handling )
other-handling = token
session-parm = "preconditions" | "media" | token

Where presence of the preconditions session-parm indicates that
preconditions exist.

Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Aug 2000 13:00:56 -0400

> the user until the preconditions have been met.

Agreed. The purpose of the tag in the content-disposition header is to
indicate when 
some aspect of the session described by the content impacts the
operation of sip. As
the operation does not depend on whether the precondition itself is qos
or security,
a single tag should suffice. In fact, perhaps we should call it
"precondition"?

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 02 Aug 2000 10:36:07 +0200

>the user until the preconditions have been met.

The old Session header could indicate if the session description was to be
used for media, or for setting up qos or security.  Perhaps we could have:

disposition-type = "render" | "media" | "session-info" | extension-type

media would correspond to ordinary or early media, and session-info or
"precondition" would be a session used for setting up qos, security, nat
traversal, punching holes in firewalls, etc...

the only problem is that there a few valid scenarios where you might want
to use a session description for both early media and qos.

>protocol will need to be changed with other precondition reasons need to be

that's the way manyfolks is defined now.

>strength-tag is set to optional.

agreed.

thanks,
-rohan

---

From: "Steve Donovan" <[email-masked]>
Date: Wed, 2 Aug 2000 13:58:36 -0500

> to use a session description for both early media and qos.

I was trying to avoid coping the contents of the SDP body into the SIP
headers.  Why does the SIP UA need to know that there are QoS, security or
other precondition information in the header?

> that's the way manyfolks is defined now.

The manyfolks draft defines it in the SDP, which is appropriate.  I don't
think it talks about the SIP Session header.  I'm arguing that the SIP layer
does not need to know about QoS or Security, only that preconditions exist.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 11:01:24 +0200

>other precondition information in the header?

The UA needs to know the purpose/semantics of the SDP.

For an SDP, the UA could either setup that session for immediate media (as
in Session: media), or it might need the session description to setup
QoS/Security/Firewall holes/Whatever, where it DOES NOT setup media.

When a UA gets SDP, it needs to know if immediate media is needed, or not.

If this is not clear, please see the section on the Session header in the
expired 183 draft.  It articulates the need much better than I could typing
in the back of a session.

>does not need to know about QoS or Security, only that preconditions exist.

The SDP for manyfolks will have the a=qos: attributes whether the SDP is
needed for media or not.  See my example below (only relevant headers/SDP
info shown).  B supports manyfolks, but A does not.

INVITE ->
From: A
To: B 

<- 180
Content-Disposition: preconditions;handling=optional
a=qos:optional sendrecv confirm

<- 200
Content-Disposition: session;handling=required
a=qos:failure sendrecv

ACK ->

So with Content-Disposition, a bis-capable UA, should know what a body is
for, and if the body is optional or required, without having to know the
semantics of the body first.

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Aug 2000 21:44:47 -0400

> a single tag should suffice. In fact, perhaps we should call it

I assume this should be in the manyfolks draft, presumably as a separate
parameter, as in

Content-Disposition: session ;handling=required ;precondition

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 00:00:46 -0400

Sounds reasonable. 

-Jonathan R.