RE: [Sip] Status of require headers in the re-INVITE request.

["Christer Holmberg" <[e-mail]>]

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:[e-mail]]
> >>> Sent: Fri 16/11/2007 19:03
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: Re: [Sip] Status of require headers in the 
> re-INVITE request.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> [e-mail] 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:[e-mail]]
> >>>> Sent: Friday, November 16, 2007 6:40 PM
> >>>> To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility 
> & Carrier
> >>>> Infrastructure)
> >>>> Cc: [e-mail]; [e-mail]
> >>>> 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
> >>>>
> >>>> [e-mail] wrote:
> >>>>> Comments inline...
> >>>>>
> >>>>> *Regards,*
> >>>>> *Nataraju A B*
> >>>>>
> >>>>> 
> ------------------------------------------------------------------
> >>>>> ----
> >>>>> --
> >>>>> *From:* Gupta Vineet-A18467 [mailto:[e-mail]]
> >>>>> *Sent:* Friday, November 16, 2007 1:10 PM
> >>>>> *To:* [e-mail]
> >>>>> *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://www1.ietf.org/mailman/listinfo/sip
> >>>>> This list is for NEW development of the core SIP Protocol Use 
> >>>>> [e-mail] for questions on 
> current sip Use 
> >>>>> [e-mail] 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://www1.ietf.org/mailman/listinfo/sip
> >>> This list is for NEW development of the core SIP Protocol Use 
> >>> [e-mail] for questions on current sip Use 
> >>> [e-mail] for new developments on the application of sip
> >>>
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [e-mail] for questions on current sip Use 
> >> [e-mail] for new developments on the application of sip
> >>
> > 
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip