Subject: Invite and Option

From: "Shary" <[email-masked]>
Date: Tue, 28 Sep 1999 11:17:39 +0200

Hello everybody,

I have a question and I hope someone can help me. How does a server react
when it receives an option with the same call-leg after an invite? Does it:
 1) manage it in parallel? or
 2) ignore the option and continue managing the invite? or
 3) reply with a response 400 and terminate both (invite and option)?

Thanks in advance
Shary

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 1999 10:24:16 -0400

>  3) reply with a response 400 and terminate both (invite and option)?

Although nothing stops you from sending an OPTIONS with the same Call-ID
as an existing call, there is no strong relationship between the
response to the OPTIONS and the state of the existing call. The spec
says to answer 200 OK if the user can be reached, and since they
obviously can be, a 200 OK response is in order. The UAS should respond
to the OPTIONS as it would if there were no call - return the MIME types
understood in the Accept header, methods in the Allow, and so on. I'm
unsure what the body should be; the spec says to return the capabilities
of the user. There is no specified way to do this in SDP, although its
not too hard to imagine. I would prefer NOT to return the SDP for the
call associated with the Call-ID of the OPTIONS, but rather return the
generic SDP which indicates capabilities. This makes OPTIONS
consistently call-indepenent. So, to answer your specific questions:

1. parallel - yes
2. no, respond to the OPTIONS with a 200 OK
3. no, the OPTIONS has no affect on the in progress call

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 28 Sep 1999 10:01:59 -0500 (CDT)

> 3) reply with a response 400 and terminate both (invite and option)?

It sounds like you intend to ask what to do if you get an OPTIONS on 
the same leg as an INVITE before you send an INVITE final response.
This would be a very strange transaction indeed. Here's how I would
implement it:

For a UAS: I'd choose to either manage it "in parallel" (all you need 
to do is send back a 200 with a capability set) or send back a
"486 Busy Here" (which is what I'd opt for if you don't have a "call 
waiting" type of functionality on the server). 

For a redirect server: Return your normal 300-class response.

For a proxy server: Handle both requests in parallel. You already
have to do this sort of thing for BYE messages, so it shouldn't be
too much trouble.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 03 Oct 1999 13:11:50 -0400

> 3. no, the OPTIONS has no affect on the in progress call

Added/modified the following wording to the OPTIONS section:

A server {\SHOULD} return \header{Allow}, \header{Accept},
\header{Accept-Encoding}, \header{Accept-Language} and
\header{Supported} header fields.  The response {\MAY} contain a message
body indicating the capabilities of the end system (rather than 
properties of any existing call).

The use of the \header{Call-ID} header field is discussed in
Section~\ref{sec:Call-ID}.  An {\OPTIONS} requests for an existing
call-id has no impact on that call.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs