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

From: "Gupta Vineet-A18467" <[email-masked]>
Date: Fri, 16 Nov 2007 15:40:03 +0800

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?
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.). 
 
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.
 
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 13:32:06 +0530

Comments inline...

Regards, 
Nataraju A B 

________________________________

From: Gupta Vineet-A18467 [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 1:10 PM
To: [email-masked]
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."

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 16 Nov 2007 21:04:01 +0800

Hi Vineet
 
It also depends on the purpose of reinvite. like if the re-invite is for
a call hold / resume, then there is no use of a Require:100rel header
there.  

Regards 
Ranjit 

From: Gupta Vineet-A18467 
Sent: Friday, November 16, 2007 1:10 PM
To: [email-masked]
Subject: [Sip] Status of require headers in the re-INVITE request.

Hi,

 
 
Regards,
Vineet.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2007 08:09:42 -0500

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

[email-masked] wrote:
> Comments inline...
> 
> *Regards,*
> *Nataraju A B*
> 
> ------------------------------------------------------------------------
> *From:* Gupta Vineet-A18467 [mailto:[email-masked]]
> *Sent:* Friday, November 16, 2007 1:10 PM
> *To:* [email-masked]
> *Subject:* [Sip] Status of require headers in the re-INVITE request.
> 
>     Hi,
>      
>     *If a Require header was used in the INVITE request establishing the
>     dialog, is it mandatory to include the same Require header in
>     *[ABN] yes, its necessary that re-INVITE carry the same set of
>     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.).
>     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.
>      
>     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.
>      
>     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.
>      
>     /“You're only given a little spark of madness. You mustn't lose it.”/
>      
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Gupta Vineet-A18467" <[email-masked]>
Date: Fri, 16 Nov 2007 21:50:41 +0800

Hi,

Natraju, I will be glad if you can point out sections in RFC/drafts
which suggest the same. Also, I believe if the user intervention is not
required for session modification, the UA	 would use UPDATE rather
than re-INVITE.

I agree with Paul in that there is well defined scope of the
applicability of Supported/Require headers to a dialog.

Logically, I assume an highly interoperable implementation should use
same value of Supported/Require headers of all the requests within the
dialog, but  I want to explore the oppurtunity for an extended
implementation for use-case such as 100rel, where the implementor might
chose to include the same in INVITE request and omit the same in
re-INVITE request. 

This is because, even though re-INVITE requires user intervetion it
might not require the same set of Offer-Answer negotiations and resource
reservation negotiations that was there in session establishement.

Also, would be interopable implementation to use UPDATE method for
session modifications which don't require user intervention, and
re-INVITE for session modifications which require user intervention?

Regards,
Vineet.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 6:40 PM
To: [email-masked]
Cc: Gupta Vineet-A18467; [email-masked]
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

	Thanks,
	Paul

requests.
>     I agree, that such delay in re-INVITE might be acceptable given
that
>     In general, re-INVITE is expected to perform subset of what
happened
>     /"You're only given a little spark of madness. You mustn't lose 
> it."/
>      
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 19:51:32 +0530

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.

To make the implementation simpler UAs might decide to send the same set
of options negotiated during initial INVITE transaction. At least its
not acceptable to add more options in re-INVITE, which were not
negotiated during INTITE transaction. If so it might end up with a an
issue with refresh (if remote guy does not support the new option). As
you said it has interoperability issue, because different people
implement in different manner. 

Regards,
Nataraju A B

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 6:40 PM
To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier
Infrastructure)
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

	Thanks,
	Paul

requests.
that
happened

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 19:58:45 +0530

Inline...

Regards,
Nataraju A B

-----Original Message-----
From: Gupta Vineet-A18467 [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 7:21 PM
To: Paul Kyzivat; Nataraju Alilughatta basavaraju (WT01 - TES-Mobility &
Carrier Infrastructure); Avasarala Ranjit-A20990
Cc: [email-masked]
Subject: RE: [Sip] Status of require headers in the re-INVITE request.

Hi,

[ABN] its based on my insight and understanding. By doing so, you might
avoid some unwanted issues.

[ABN] its my understanding and information about most implementation
only. I have not read any where it has to be same or not. Probably if
you can validate the alternatives for different features you can infer
which is better over others... 

Regards,
Vineet.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, November 16, 2007 6:40 PM
To: [email-masked]
Cc: Gupta Vineet-A18467; [email-masked]
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

Nataraju,

	Thanks,
	Paul

requests.
that
happened

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2007 13:03:44 -0500

> options which INVITE carried. It would vary from application to

And the meaning when it changes may also vary from implementation to 
implementation because it is not standardized.

> of options negotiated during initial INVITE transaction.

That would be a safe thing to do, but may not always be possible.

> At least its
> 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

Yes.

> 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
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Nov 2007 20:45:42 +0100

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.
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Fri 16/11/2007 19:03
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Status of require headers in the re-INVITE request.

        Paul

Yes.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 16:19:22 -0500

> 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…

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

---

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 20 Nov 2007 00:33:54 +0100

Christer,

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.

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.

Regards,
Jeroen

Paul Kyzivat wrote:
>> 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.
>
> dialog until overridden". And overrides are themselves a problem 
> because there is no Unrequired header.
>
> scope that will work for all of them - that there will be examples 
> that assume different scopes.
>
>     Paul
>
>> Regards,
>>  
>> Christer
>>
>>>>         *If a Require header was used in the INVITE request 
>>>> establishing
>>> the
>>> 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
>>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 20:38:06 -0500

>   field in the request listing the option tags (Section 19.2) for those

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?

> interpretation of scope. RFC3329 (sec-agree) came up with a "creative" 

I haven't done a survey, but I think there are probably a lot of 
creative interpretations of the scope.

It seems that some assume that Supported in a non-OPTIONS request or 
response has similar meaning to what it would have in an OPTIONS response.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 12:09:38 +0100

Hi, 

>>   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.
> 
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.

>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?
> >>>  
> >> 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 
> >>>> 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.
> >>>
> >>>> To make the implementation simpler UAs might decide to send the 
> >>>> same set of options negotiated during initial INVITE 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.
> >>>
> >>> 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
> >>> 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.
> >>>
> >>>> 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
> >>>>
> ------------------------------------------------------------------
> >>>>> ----
> >>>>> --
> >>>>>     accordingly. So, it would also imply that re-INVITE 
> also takes
> >>>> same
> >>>>>     then yes, it lead to re-INV , 1xx(100rel), PRACK, 
> 200-PRK, ... 
> >>>>> it
> >>>> is
> >>>>>         I agree, that such delay in re-INVITE might be 
> acceptable 
> >>>>> given
> >>>> that
> >>>>>     the re-INVITE handling as complicated as the INVITE 
> handling.
> >>>> Also,
> >>>>>         [ABN] In most of the cases, re-INVITE is not 
> expected to 
> >>>>> undergo
> >>>>>     in INVITE transaction. it should not create any issues to 
> >>>>> handle
> >>>> 1xx
> >>>>>     responses reliably.
> >>>>>         /"You're only given a little spark of madness. 
> You mustn't 
> >>>>> lose it."/
> >>>>>   
> >>>>> 
> ------------------------------------------------------------------
> >>>>> ----
> >>>>> --
> >>>>>
> >>>> notify the sender immediately and destroy all copies of this 
> >>>> message and any attachments.
> >>>>
> >>>> presence of viruses. The company accepts no liability for any 
> >>>> damage caused by any virus transmitted by this email.
> >>>>
> >>>> www.wipro.com
> >>>>
> >>>
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2007 11:40:09 -0500

> should clearly specify what the "scope" of it is.

Yes, that is probably the only practical way forward. It needs to be 
done for all the existing tags too.

	Paul