Hi,
>>RFC3261 is pretty clear on the intended scope:
>>
>>8.1.1.9 Supported and Require
>>
>> If the UAC supports extensions to SIP that can be
applied by the
>> server *_to the response_*, the UAC SHOULD
include a
>> Supported header field in the request listing the
option tags
(Section
>> 19.2) for those extensions.
>
>That seems to imply that you can change the Supported
options from
request to request.
>But how do you reconcile that with the use of Supported
in OPTIONS? For
the response to OPTIONS
>to mean anything at all it must imply that you will
respond
affirmatively to a Require for the listed options at some
>time in the future. But when does that time end?
I think OPTIONS is a way to indicate what you are able to
support - but
that doesn't mean you are going to accept it every time. You
may not
support everything at once, but only certain combinations of
features,
extensions, codecs etc.
>>Still, some drafts / RFC may have sneaked through
that use a different
>>interpretation of scope. RFC3329 (sec-agree) came up
with a "creative"
>>use, for example.
>
>I haven't done a survey, but I think there are probably
a lot
>of creative interpretations of the scope.
Yes, and that is what causes interop problems 
One alternative would be that when you define a new
option-tag, you
should clearly specify what the "scope" of it is.
Regards,
Christer
> > Regards,
> > Jeroen
> >
> > Paul Kyzivat wrote:
> >>
> >>
> >> Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>> I think this discussion touches on an
issue, which I know
> has caused
> >>> some interop concerns:
> >>>
> >>> Is the Supported/Require header only
transaction
> specific, or is it
> >>> dialog specific?
> >>>
> >>> If it is dialog specific, I would say that
you don't need
> to include
> >>> anything in the re-INVITE, if it was
already included in
> the INVITE.
> >>> But, then it would also mean that whatever
you indicated in the
> >>> INVITE (e.g. 100rel) is also valid for the
re-INVITE.
> >>
> >> For many usages it must have a scope longer
than a single
> transaction.
> >> And dialog scope isn't always right either.
(Some apply to
> non-dialog
> >> usages.) In practice, anything that seems to
have dialog
> scope will
> >> be broken by 3pcc and so will at best have to
be "from
> henceforth in
> >> the dialog until overridden". And
overrides are themselves
> a problem
> >> because there is no Unrequired header.
> >>
> >> I haven't tried to do an exhaustive analysis
of all the different
> >> options, but I have gut feeling that there is
no single
> definition of
> >> scope that will work for all of them - that
there will be examples
> >> that assume different scopes.
> >>
> >> Paul
> >>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>> ________________________________
> >>>
> >>> From: Paul Kyzivat [mailto:pkyzivat cisco.com]
> >>> Sent: Fri 16/11/2007 19:03
> >>> To: nataraju.basavarajuwipro.com
> >>> Cc: sipietf.org
> >>> Subject: Re: [Sip] Status of require
headers in the
> re-INVITE request.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> nataraju.basavarajuwipro.com wrote:
> >>>> Paul,
> >>>>
> >>>> You are right, its not a mandatory
that re-INVITE carry the same
> >>>> set of options which INVITE carried.
It would vary from
> application
> >>>> to application.
> >>>
> >>> And the meaning when it changes may also
vary from
> implementation to
> >>> implementation because it is not
standardized.
> >>>
> >>>> To make the implementation simpler UAs
might decide to send the
> >>>> same set of options negotiated during
initial INVITE transaction.
> >>>
> >>> That would be a safe thing to do, but may
not always be possible.
> >>>
> >>>> At least its
> >>>> not acceptable to add more options in
re-INVITE, which were not
> >>>> negotiated during INTITE transaction.
> >>>
> >>> I would say that it might not be wise, or
might be asking for
> >>> trouble, but its not banned by the specs.
Whether it is
> acceptable
> >>> or not is something that will be judged by
the recipient.
> >>>
> >>>> If so it might end up with a an
> >>>> issue with refresh (if remote guy does
not support the
> new option).
> >>>
> >>> Yes you might. So if you do it you had
better be prepared
> to get a
> >>> 420 error and recover.
> >>>
> >>> More difficult that adding options is
taking them away, which is
> >>> what the original poster wanted to do.
There is no
> Unrequire header,
> >>> and while there is an Unsupported header
it may only be used in a
> >>> 420 response.
> >>>
> >>> Suppose Alice originally called Bob,
specifying Supported:100rel,
> >>> and Bob answered with Require:100rel and
used reliable
> provisionals.
> >>> Then Alice wants to send a reinvite but
doesn't want to
> use 100rel
> >>> any longer. She can omit Supported:100rel
from the reinvite, but
> >>> there is no guarantee that Bob won't
remember it and again put
> >>> Require:100rel in the response and use
reliable provisionals. (If
> >>> any provisionals are used at
> >>> all.) The best Alice can do is hope. If
she gets a 1xx with
> >>> Require:100rel she has no real option
except to send a PRACK.
> >>>
> >>> Note that Supported and Require are among
the things that are
> >>> supposed to be included in an OPTIONS
response. OPTIONS
> is typically
> >>> used outside a dialog. For the Supported
and Require
> values in the
> >>> OPTIONS response to have any utility they
must remain
> valid beyond
> >>> the transaction. One would expect that
they are valid
> until further notice I suppose.
> >>>
> >>> Basically this is a mess.
> >>>
> >>> Paul
> >>>
> >>>> As
> >>>> you said it has interoperability
issue, because different people
> >>>> implement in different manner.
> >>>
> >>> Yes.
> >>>
> >>>> Regards,
> >>>> Nataraju A B
> >>>>
> >>>> -----Original Message-----
> >>>> From: Paul Kyzivat
[mailto:pkyzivatcisco.com]
> >>>> Sent: Friday, November 16, 2007 6:40
PM
> >>>> To: Nataraju Alilughatta basavaraju
(WT01 - TES-Mobility
> & Carrier
> >>>> Infrastructure)
> >>>> Cc: vineet.guptamotorola.com; sipietf.org
> >>>> Subject: Re: [Sip] Status of require
headers in the
> re-INVITE request.
> >>>>
> >>>> Nataraju,
> >>>>
> >>>> Why do you think this behavior is
required?
> >>>>
> >>>> The scope of applicability of
Supported, Require, etc.
> is not well
> >>>> defined. If you want to be certain,
then you should
> repeat these in
> >>>> every request. But if you *don't*
include them in every
> request it
> >>>> is still likely that some peers will
remember a value you sent
> >>>> earlier and assume it still applies.
> >>>>
> >>>> This is a potential interoperability
issue and should be
> fixed, but
> >>>> I think it will be difficult. To be
useful these options
> generally
> >>>> need to have a scope longer than a
single transaction,
> yet if you
> >>>> assume they should have longer scope
then it becomes
> difficult to
> >>>> define when that scope ends.
> >>>>
> >>>> In your particular case, if you want
to use PRACK for
> the initial
> >>>> INVITE but you don't want to use it
for reINVITE, I
> guess you can
> >>>> try omitting the Require:100rel in the
reINVITE and hope for the
> >>>> best. But don't get upset if somebody
still sends you PRACKs.
> >>>>
> >>>> Thanks,
> >>>> Paul
> >>>>
> >>>> nataraju.basavarajuwipro.com
wrote:
> >>>>> Comments inline...
> >>>>>
> >>>>> *Regards,*
> >>>>> *Nataraju A B*
> >>>>>
> >>>>>
>
------------------------------------------------------------
------
> >>>>> ----
> >>>>> --
> >>>>> *From Gupta
Vineet-A18467 [mailto:vineet.guptamotorola.com]
> >>>>> *Sent Friday,
November 16, 2007 1:10 PM
> >>>>> *To sipietf.org
> >>>>> *Subject [Sip]
Status of require headers in the
> re-INVITE request.
> >>>>>
> >>>>> Hi,
> >>>>> I have a doubt related to
using Require:100rel in
> >>>>> re-INVITE
> >>>> requests.
> >>>>> *If a Require header was
used in the INVITE request
> >>>>> establishing
> >>>> the
> >>>>> dialog, is it mandatory to
include the same Require
> header in
> >>>>> subsequent re-INVITE requests
within the dialog?
> >>>>> *[ABN] yes, its necessary that
re-INVITE carry the
> same set of
> >>>>> Require header values that of
INVITE.
> >>>>> To be specific, if INVITE
request contained
> >>>>> Require:100rel, then
> >>>>> inclusion of Require:100rel in
re-INVITE would require the
> >>>>> originator to handle Reliable
provisional responses
> and respond
> >>>>> accordingly. So, it would also
imply that re-INVITE
> also takes
> >>>> same
> >>>>> call establishment time (owing
to multiple messages like 183
> >>>> session
> >>>>> in Progress, PRACK, 180
ringing, PRACK etc.).
> >>>>> [ABN] Yes, UA's should be
ready to handle PRACK txn
> triggered by
> >>>>> re-INVITE txn. Also sending
100rel in re-INVITE
> does not mean UAS
> >>>>> has to generate 1xx. if UAS
generates 1xx responses
> for re-INVITE,
> >>>>> then yes, it lead to re-INV ,
1xx(100rel), PRACK,
> 200-PRK, ...
> >>>>> it
> >>>> is
> >>>>> not mandatory to send 1xx for
re-INVITE, hence even if
> >>>>> Require:100rel is in
re-INVITE, re-INVITE txn could
> be completed
> >>>>> with out PRACK transaction.
> >>>>> I agree, that such delay
in re-INVITE might be
> acceptable
> >>>>> given
> >>>> that
> >>>>> re-INVITE requires the
user-intervention, but it
> complicates makes
> >>>>> the re-INVITE handling as
complicated as the INVITE
> handling.
> >>>> Also,
> >>>>> if the initial INVITE involved
procedures such as
> QoS negotiation
> >>>>> the re-INVITE state-machine
complicates even further.
> >>>>> [ABN] In most of the
cases, re-INVITE is not
> expected to
> >>>>> undergo
> >>>>> user-intervention. hence in
most of the cases it
> would end up with
> >>>>> re-INV, 200, ACK only...
> >>>>> In general, re-INVITE is
expected to perform subset of
> >>>>> what
> >>>> happened
> >>>>> in INVITE transaction. it
should not create any issues to
> >>>>> handle
> >>>> 1xx
> >>>>> responses reliably.
> >>>>> Hope this answers all your
questions...
> >>>>> Regards,
> >>>>> Vineet.
> >>>>> /"You're only given a
little spark of madness.
> You mustn't
> >>>>> lose it."/
> >>>>>
> >>>>>
>
------------------------------------------------------------
------
> >>>>> ----
> >>>>> --
> >>>>>
> >>>>>
_______________________________________________
> >>>>> Sip mailing list https://ww
w1.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
> >>>>
> >>>> The information contained in this
electronic message and any
> >>>> attachments to this message are
intended for the
> exclusive use of
> >>>> the addressee(s) and may contain
proprietary, confidential or
> >>>> privileged information. If you are not
the intended
> recipient, you
> >>>> should not disseminate, distribute or
copy this e-mail. Please
> >>>> notify the sender immediately and
destroy all copies of this
> >>>> message and any attachments.
> >>>>
> >>>> WARNING: Computer viruses can be
transmitted via email. The
> >>>> recipient should check this email and
any attachments for the
> >>>> presence of viruses. The company
accepts no liability for any
> >>>> damage caused by any virus transmitted
by this email.
> >>>>
> >>>> www.wipro.com
> >>>>
> >>>
> >>>
> >>>
_______________________________________________
> >>> Sip mailing list https://ww
w1.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
> >>>
> >>
> >>
> >>
_______________________________________________
> >> Sip mailing list https://ww
w1.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
> >>
> >
>
_______________________________________________
Sip mailing list https://ww
w1.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
|
