Thanks...I wasn't exactly convinced but I finally found the
answer in
Section 9.1 of 3841, which put all my (further)
questions to rest:
The set of request disposition directives is not extensible
on
purpose. This is to avoid a proliferation of new extensions
to SIP
that are "tunneled" through this header field.
-Sumit
"The reasonable man adapts himself to the world; the
unreasonable one
persists in trying to adapt the world to himself. Therefore
all progress
depends on the unreasonable man."
-- George Bernard Shaw
-----Original Message-----
From: Dean Willis [mailto:dean.willis softarmor.com]
Sent: Tuesday, March 18, 2008 1:04 PM
To: Sumit Garg
Cc: sipietf.org
Subject: Re: [Sip] I-D
ACTION:draft-ietf-sip-answermode-06.txt
Sumit Garg wrote:
>
> Why exactly do we require these additional (Answer-Mode
and
> Priv-Answer-Mode) headers? Couldn't this have been done
by extending
> the Request-Disposition header as defined in RFC3841
(which this draft
> references..). Are there any specific advantages of
having new headers
> rather than additional directives for
Request-Disposition?
It seemed to many of us that RFC 3841's Request-Disposition
header was
about request routing in a proxy, not feature-invocation at
a user
agent. This position is supported by the following excerpt
from RFC
3841:
4. Overview of Operation
When a caller sends a request, it can optionally include
new header
fields which request certain handling at a server. These
preferences
fall into two categories. The first category, called
request
handling preferences, is carried in the
Request-Disposition header
field. It describes specific behavior that is desired at
a server.
Request handling preferences include whether the caller
wishes the
server to proxy or redirect, and whether sequential or
parallel
search is desired. These preferences can be applied at
every proxy
or redirect server on the call signaling path.
That said, there are myriad ways that the functionality of
Answer-Mode
could be encoded in a SIP request.
At the heart of the question lies the "What is (or are)
the extension
model(s) of SIP? And if there are more than one, how do we
know which to
use to provide some desired behavior?
The approach taken by Answer-Mode treats SIP as an
application protocol,
where knowlegde of the application's state or function is
encoded
directly into the protocol, and new application function
requires a
protocol extension.
This may or may not be "right", but it is the
oldest of the extension
modalities I have observed being used in SIP.
Request-Disposition is
arguably eitehr another application of this extension model,
or is
perhaps yet another category -- a change to SIP that impacts
the core
operation of the protocol at a level below that of the
application. As
documented, Request-Disposition actually impacts the
request-routing
logic in a matter that seems to be completely independent of
the
application usage.
Another alternative, using the "SIP as transport"
modality, would have
been to put the Answer-Mode function into the SDP.
The third modality, "SIP as a session control
protocol", is ruled out
because in typical use, the alerting phase occurs BEFORE
the
SIP-initiated-session is established. So unless we want to
change the
alerting process to be post session-establishment, we can't
affect
alerting by changing the session protocol.
--
Dena
_______________________________________________
Sip mailing list https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
