Subject: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Nov 2009 04:17:55 +0100

Hi,

Based on the 3pcc issue raised by Paul, at the SIPCORE session we
discussed whether we should mandate to include Recv-Info in re-INVITE
responses.

The outcome of the discussion was that EVERY SIP messages where
Recv-Info is allowed MUST contain Recv-Info, NO MATTER if the set of
Info Packages has changed or not. 

Based on the -03pre version of the draft the following messages would be
affected:

INVITE + 18x + 200
Re-INVITE + 18x + 200
ACK
UPDATE + 200
PRACK + 200

That is a change from previous versions of the draft, which says that
the Recv-Info header only needs to be inserted if the set of Info
Packages changes.

So, unless people have issues with that, my intention is to implement
the change in the next version of the draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 08 Nov 2009 23:14:56 -0500

That works for me, and it is sufficiently simple that everybody should 
be able to implement it correctly. :-)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Nov 2009 05:38:37 +0100

This works, but it seems overkill to me.

Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion.

Secondly can I still have more detail (arrow diagram) on the scenario we are trying to solve for 3pcc. I can't see if there is a simple solution if the problem is insufficiently clear.

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, November 09, 2009 4:15 AM
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert 
> Recv-Info header
> 
> That works for me, and it is sufficiently simple that 
> everybody should be able to implement it correctly. :-)
> 
> 	Thanks,
> 	Paul
> 
> Christer Holmberg wrote:
> > 
> > Hi,
> > 
> > Based on the -03pre version of the draft the following 
> messages would 
> > be
> > affected:
> > 
> > INVITE + 18x + 200
> > Re-INVITE + 18x + 200
> > ACK
> > UPDATE + 200
> > PRACK + 200
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 09 Nov 2009 13:51:00 +0900

> Firstly can I ensure that this does not include REGISTER, which could also be understood from the paraphrase of the SIPCORE discussion.

I could be wrong, but I believe this discussion was entirely within the
context of an INVITE-created dialog and its subsequent transactions.
That particular part of the discussion revolved around re-INVITEs and
target refreshes.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 8 Nov 2009 23:26:53 -0600

I will also like to see call flows in next version of the draft for
scenarios this covers.

Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DRAGE, Keith (Keith)
Sent: Monday, November 09, 2009 10:09 AM
To: Paul Kyzivat (pkyzivat); Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header

Firstly can I ensure that this does not include REGISTER, which could
also be understood from the paraphrase of the SIPCORE discussion.

Secondly can I still have more detail (arrow diagram) on the scenario we
are trying to solve for 3pcc. I can't see if there is a simple solution
if the problem is insufficiently clear.

Keith

---

From: Linyi TIAN <[email-masked]>
Date: Mon, 09 Nov 2009 14:22:48 +0800

Does it mean the following case:

1.     Initial set : Info package A and B

2.     During the session we can use Re-invite/Update to change it to
package A only

We can use Update/Re-invite to remove the willingness to receive for a
particular Info Package which was required before, right?

It is not clear to me what "UA wishes to only receive INFO request for one
of the Packages" means. 

----------------------------------------------------------------------------
----------------------------------------

3.2 User Agent Behavior

If a UA indicates multiple Info Packages, which provide similar

   functionality, it is not possible to indicate a priority order of the

   Info Packages, or that that the UA wishes to only receive INFO

   request for one of the Info Packages.  It is up to the application

   logic associated with the Info Packages, and specific Info Package

   descriptions to describe application behavior in such cases.

So the new set does not necessary means addition and it may also means
removal, right?

----------------------------------------------------------------------------
----------------------------------------

Section 1.1 Introduction

A UA uses the Recv-Info header field, on a per-dialog basis, to

   indicate for which Info Packages it is willing to receive INFO

   requests.  A UA can indicate an initial set of Info Packages during

   dialog establishment and can indicate a new set during the lifetime

   of the invite dialog usage.

Can these be clarified in the draft?

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Monday, November 09, 2009 11:18 AM
To: [email-masked]
Subject: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

Hi, 

Based on the 3pcc issue raised by Paul, at the SIPCORE session we discussed
whether we should mandate to include Recv-Info in re-INVITE responses.

The outcome of the discussion was that EVERY SIP messages where Recv-Info is
allowed MUST contain Recv-Info, NO MATTER if the set of Info Packages has
changed or not. 

INVITE + 18x + 200 
Re-INVITE + 18x + 200 
ACK 
UPDATE + 200 
PRACK + 200 

That is a change from previous versions of the draft, which says that the
Recv-Info header only needs to be inserted if the set of Info Packages
changes.

So, unless people have issues with that, my intention is to implement the
change in the next version of the draft. 

Regards, 

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Nov 2009 07:38:24 +0100

Hi, 

package A only

No, you can change it to whatever you want.

The change is that you will have to indicate A and B during the session
even if you don't change it.

>We can use Update/Re-invite to remove the willingness to receive for a
particular Info Package which was required before, 
>right?

Yes. You can still send Recv-Info:nil

>It is not clear to me what "UA wishes to only receive INFO request for
one of the Packages" means. 

It means that the Info Package mechanism does not provide a mechanism
where you can say "Here are two packages, but please use only one of
them".

removal, right?

Yes.

>-----------------------------------------------------------------------
---------------------------------------------
>Can these be clarified in the draft?

So, what is it that you want clarified? That one can remove packages
from the set?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Nov 2009 07:45:42 +0100

Hi,

I guess Paul can provide more details, but I am not sure whether the
proxy doing the 3pcc would always be able to include Recv-Info in the
re-INVITE request.

Regards,

Christer

 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: 9. marraskuuta 2009 7:39
To: Paul Kyzivat; Christer Holmberg
Cc: [email-masked]
Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header

Keith

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 09 Nov 2009 08:37:01 +0100

I also think it's overkill. Furthermore, I don't see a real world use 
case for changing the set of supported INFO packages mid-dialog. Surely 
the UAS can simply reply with a 403 response when it receives an INFO 
request which it doesn't want to process anymore?

To me, INFO packages should be like the Dialog's route set: learn the 
supported set from the initial INVITE and 1xx-2xx responses, after that 
don't change it anymore

Regards,
Jeroen

PS The usage of 'nil' to denote no supported packages is not consistent 
with conventions used today, e.g. for Supported (suggest to simply use 
an empty value instead)

DRAGE, Keith (Keith) wrote:
>>> discussed whether we should mandate to include Recv-Info in 
>>>       
>> re-INVITE 
>>     
>>> responses.
>>>
>>> Recv-Info is allowed MUST contain Recv-Info, NO MATTER if 
>>>       
>> the set of 
>>     
>>> That is a change from previous versions of the draft, which 
>>>       
>> says that 
>>     
>>> So, unless people have issues with that, my intention is to 
>>>       
>> implement 
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Nov 2009 08:55:16 +0100

Hi, 

>I also think it's overkill. Furthermore, I don't see a real world use
case for changing the set of supported INFO 
>packages mid-dialog. Surely the UAS can simply reply with a 403
response when it receives an INFO request which it 
>doesn't want to process anymore?
>
supported set from the initial INVITE and 1xx-2xx 
>responses, after that don't change it anymore

I think Adam made the same comment in the SIPCORE session.

Personally I think there could be cases where one wants to add a package
during a dialog. For example, assume I call you. Then, during the dialog
we decide to start using application X which uses an Info Package, so
our phones send Recv-Info:X to each other. Application X may not even be
running when we initiate the dialog.

However, if we are going to require the header in a lot of messages,
maybe we should remove PRACK from the list of allowed messages. Would
people have problems with that?

But, I would like Paul to comment whether mandating the header in every
message would actually solve his 3pcc use-case.

>PS The usage of 'nil' to denote no supported packages is not consistent
with conventions used today, e.g. for Supported 
>(suggest to simply use an empty value instead)

I think there was some WGLC comment(s) asking about the same thing.
Personally I have no problem to use an empty header instead of 'nil'.
However, I want to ensure that nobody objects to such change before I
implement it.

Regards,

Christer

>
> Secondly can I still have more detail (arrow diagram) on the scenario
we are trying to solve for 3pcc. I can't see if there is a simple
solution if the problem is insufficiently clear.

>> header
>>
>> That works for me, and it is sufficiently simple that everybody 
>> should be able to implement it correctly. :-)
>>
>> 	Thanks,
>> 	Paul
>>
>> Christer Holmberg wrote:
>>     
>>> Hi,
>>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 09 Nov 2009 09:07:44 +0100

Christer,

Given the registration requirement (i.e. there needs to be some sort of 
spec) the set of INFO packages will be limited. UAs can easily list 
those packages they support up front. Therefore the "fully dynamic" case 
you sketch below seems unlikely to me.

The only case I could imagine would be in case of long running dialogs, 
where the software of one of the peers gets upgraded mid-dialog to 
support some new INFO package. However, also that seems highly unlikely 
to me.

To me, we should keep it simple - "learn INFO packages whenever you 
learn the Route set for a Dialog" should be simple enough for developers 
to get right

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 9 Nov 2009 09:24:48 +0100

Hi, 

>spec) the set of INFO packages will be limited. UAs can easily list
those packages they support up front. Therefore the 
>"fully dynamic" case you sketch below seems unlikely to me.

I guess time will show how many packages get registered, but that is not
the main point. I think it is very "un-dynamic" having to list stuff
which you don't know that you are going to use in the first place.

>The only case I could imagine would be in case of long running dialogs,
where the software of one of the peers gets 
>upgraded mid-dialog to support some new INFO package. However, also
that seems highly unlikely to me.

Well, maybe there in the not-so-distant future will be some kind of
integrated web applications where you can "click on a link" to add an
application to an ongoing dialog. I don't think we should prevent such
things.

Likewise, you would not always negotiate video codecs when you establish
a call, even if you support video. You could add them when you actually
decide to use them.

>To me, we should keep it simple - "learn INFO# packages whenever you
learn the Route set for a Dialog" should be simple 
>enough for developers to get right

One step to make it easier would be to further restrict the messages
where it is allowed, for example by removing PRACK.

I don't think that allowing mid-dialog changes makes things complicated.

However, since 3pcc seems to be the only reason we would do the
include-it-everywhere, maybe we should only mandate it re-INVITEs.

Regards,

Christer

Christer Holmberg wrote:
> Personally I think there could be cases where one wants to add a 
> package during a dialog. For example, assume I call you. Then, during 
> the dialog we decide to start using application X which uses an Info 
> Package, so our phones send Recv-Info:X to each other. Application X 
> may not even be running when we initiate the dialog.
>
> But, I would like Paul to comment whether mandating the header in 
> every message would actually solve his 3pcc use-case.
>
>   
>>> Recv-Info

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 09 Nov 2009 17:30:52 +0900

> application to an ongoing dialog. I don't think we should prevent such

I don't think is very far off at all; many hardphones from various
manufacturers are already supporting additional applications, and it's
completely conceivable that a user of the phone might press a button to
activate an application during an existing call. It would have been
inappropriate for the phone to have offered to receive the related INFO
packages during the call setup, but once the application is running they
should be accepted (and in fact the act of starting the application may
directly result in a re-INVITE for no other purpose than to update the
Recv-Info package list the phone will accept).

---

From: Linyi TIAN <[email-masked]>
Date: Mon, 09 Nov 2009 16:42:24 +0800

This looks more reasonable and simple. If we don't see real use cases for
changing set during the dialog we'd better not have a technical solution for
it. Or even there is limited use case, it is no harm to use status code to
ignore the INFO. This will reduce the protocol impact and simply the
implementation.

So for the time being I support Jeroen's approach unless something new is
introduced.

Cheers,
Linyi

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jeroen van Bemmel
> Sent: Monday, November 09, 2009 3:37 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
header
> > Firstly can I ensure that this does not include REGISTER, which could
also be
> understood from the paraphrase of the SIPCORE discussion.
> >
are trying
> to solve for 3pcc. I can't see if there is a simple solution if the
problem is
> insufficiently clear.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 9 Nov 2009 10:17:56 +0100

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 09 November 2009 07:55
> To: Jeroen van Bemmel; DRAGE, Keith (Keith)
> Cc: [email-masked]
[JRE] I made that comment during WGLC, but received no support at the time. I would still prefer to follow normal conventions.

John

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 09 Nov 2009 18:32:44 +0100

Sure, but "application" in the sense of an INFO Package isn't the same 
as "application" in the sense of a program that a user decides to start 
mid-call.

A sample application for INFO Package is the sending of DTMF digits. 
Another might be the sharing of Geo location data mid-call ( "Where are 
you? I'm here!" <clicks some button that sends GPS location info>, a 
mobile phone pops up a map with the designated location highlighted; 
some IVR voicemail application might instead record the location and 
show it on a web page). These are applications in the sense of "ways of 
using INFO packages", not "computer programs"

General (web) programs that send arbitrary data via the SIP signaling 
path is something I thought we were trying to avoid. We need a limited 
set of well defined applications (in the INFO package sense), such that 
different applications (in the program sense) from various vendors can 
use them interoperably. And interoperability is better when things are 
kept simple.

Indicating support for some INFO package does not mean that the receiver 
must automatically accept INFO requests carrying that package. One can 
still implement dynamic policies that e.g. only accept DTMF at the 
beginning of a call, e.g. until the proper authorization code has been 
entered. I just don't see the need to then "disable" DTMF by sending a 
target-refresh request that no longer lists DTMF as supported Info package.

Regards,
Jeroen

---

From: George Foti <[email-masked]>
Date: Mon, 9 Nov 2009 14:11:20 -0500

The ability for a SIP device to remove support for the reception of an info-package mid-dialog is necessary and not an option.
Some applications will not use SIP INFO any more if this feature is taken out

If we take the IPTV application, where we have an info package to allow STBs and TV devices to tell the network the content currently being watched (what the device is tuned to)

The network must be able to stop  TV devices from reporting the programs they are tuned when it so desires.
Given that reporting occurs after end users start and stop zapping, and given that zapping occurs after TV ads start showing up, and that typically all IPTV users start zapping at that time, the network can be crippled with all devices reporting at the same time if it cant stop them at will.

Just ignoring the SIP INFO as suggested by some does not make sense as the congestion that this produces from devices re-attempting to send etc, will cause even more harm.

As such, comparing info-packages negotiated at dialog start-up to dialog route is not appropriate and pre-judges how applications work, which is quite dangerous.

Certainly removing this flexibility will limit the ability to use the SIP INFO and is a step backward and makes the use of legacy SIP INFO more attractive without the overhead as the result of rejection is the same

Thanks
George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linyi TIAN
Sent: Monday, November 09, 2009 3:42 AM
To: 'Jeroen van Bemmel'; 'DRAGE, Keith (Keith)'
Cc: [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

This looks more reasonable and simple. If we don't see real use cases for changing set during the dialog we'd better not have a technical solution for it. Or even there is limited use case, it is no harm to use status code to ignore the INFO. This will reduce the protocol impact and simply the implementation.

So for the time being I support Jeroen's approach unless something new is introduced.

Cheers,
Linyi

> Behalf
Of
header
> case for changing the set of supported INFO packages mid-dialog. 
> Surely the UAS can simply reply with a 403 response when it receives 
> an INFO request which it doesn't want to process anymore?
> 
> supported set from the initial INVITE and 1xx-2xx responses, after 
> that don't change it anymore
> 
> Regards,
> Jeroen
> 
> PS The usage of 'nil' to denote no supported packages is not 
> consistent with conventions used today, e.g. for Supported (suggest to 
> simply use an empty value instead)
> 
also be
are trying
problem is

---

From: George Foti <[email-masked]>
Date: Mon, 9 Nov 2009 14:20:03 -0500

Lets not pre-judge how applications will work.
Changing the list of supported Info-packages mid-dialog is essential.

I don't want neither the links to be congested nor the server to waste load to process things that it does not plan to accept and I want the other end to *COMPLY*  to that by telling it so.

Thanks
George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeroen van Bemmel
Sent: Monday, November 09, 2009 12:33 PM
To: Kevin P. Fleming
Cc: [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

Sure, but "application" in the sense of an INFO Package isn't the same as "application" in the sense of a program that a user decides to start mid-call.

A sample application for INFO Package is the sending of DTMF digits. 
Another might be the sharing of Geo location data mid-call ( "Where are you? I'm here!" <clicks some button that sends GPS location info>, a mobile phone pops up a map with the designated location highlighted; some IVR voicemail application might instead record the location and show it on a web page). These are applications in the sense of "ways of using INFO packages", not "computer programs"

General (web) programs that send arbitrary data via the SIP signaling path is something I thought we were trying to avoid. We need a limited set of well defined applications (in the INFO package sense), such that different applications (in the program sense) from various vendors can use them interoperably. And interoperability is better when things are kept simple.

Indicating support for some INFO package does not mean that the receiver must automatically accept INFO requests carrying that package. One can still implement dynamic policies that e.g. only accept DTMF at the beginning of a call, e.g. until the proper authorization code has been entered. I just don't see the need to then "disable" DTMF by sending a target-refresh request that no longer lists DTMF as supported Info package.

Regards,
Jeroen

Kevin P. Fleming wrote:
>> application to an ongoing dialog. I don't think we should prevent 
>> such things.
>>     
>
> completely conceivable that a user of the phone might press a button 
> to activate an application during an existing call. It would have been 
> inappropriate for the phone to have offered to receive the related 
> INFO packages during the call setup, but once the application is 
> running they should be accepted (and in fact the act of starting the 
> application may directly result in a re-INVITE for no other purpose 
> than to update the Recv-Info package list the phone will accept).
>
>

---

From: "Roy, Radhika R CTR USA USAMC" <[email-masked]>
Date: Mon, 09 Nov 2009 15:03:11 -0500

Hi, George:

We have never talked about the use of SIP-INFO package for IPTV. I appreciate for bringing this topic here (although I might have missed many emails on this - sorry for this as I am nor following the threads so closely these days since joining CERDEC).

Could you please more ideas like this for use of SIP for the IPTV not necessarily limiting to the SIP-INFO package?

Best regards,
Radhika

----- Original Message -----
From: George Foti <[email-masked]>
Date: Monday, November 9, 2009 14:26
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header
To: Jeroen van Bemmel <[email-masked]>, "Kevin P. Fleming" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> I don't want neither the links to be congested nor the server to 
> waste load to process things that it does not plan to accept and I 
> want the other end to *COMPLY* to that by telling it so.
> 
> 
> Thanks
> George
> 
> 
> 
> Sure, but "application" in the sense of an INFO Package isn't the 
> same as "application" in the sense of a program that a user 
> decides to start mid-call.
> 
> Another might be the sharing of Geo location data mid-call ( 
> "Where are you? I'm here!" <, a mobile phone pops up a map with the designated location highlighted; some IVR voicemail application might instead record the location and show it on a web page). These are applications in the sense of "ways of using INFO packages", not "computer programs"
>

---

From: George Foti <[email-masked]>
Date: Mon, 9 Nov 2009 15:19:51 -0500

Hi,

SIP is used by 3GPP, ATIS, and many other SDOs for session control in IPTV.
I was listing this just to highlight that mid-dialog changes for supported Info packages is something that can happen frequently in there.

Reporting by STBs the channel they are tuned to is one case where the network must ensure that it can control those STBs from reporting the TV channel they are tuned to (whenever the channel changes), and must ensure through specifications that the STBs comply to.
 
Thanks
George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roy, Radhika R CTR USA USAMC
Sent: Monday, November 09, 2009 3:03 PM
To: George Foti
Cc: Kevin P. Fleming; [email-masked]; Jeroen van Bemmel
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

Hi, George:

Best regards,
Radhika

----- Original Message -----
From: George Foti <[email-masked]>
Date: Monday, November 9, 2009 14:26
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header
To: Jeroen van Bemmel <[email-masked]>, "Kevin P. Fleming" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> I don't want neither the links to be congested nor the server to waste 
> load to process things that it does not plan to accept and I want the 
> other end to *COMPLY* to that by telling it so.
> 
> 
> Thanks
> George
> 
> 
> 
> Behalf Of Jeroen van Bemmel
> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv- Info 
> header
> 
> as "application" in the sense of a program that a user decides to 
> start mid-call.
> 
> Another might be the sharing of Geo location data mid-call ( "Where 
> are you? I'm here!" <, a mobile phone pops up a map with the designated location highlighted; some IVR voicemail application might instead record the location and show it on a web page). These are applications in the sense of "ways of using INFO packages", not "computer programs"
> 
> >> integrated web applications where you can "click on a link" to add 
> >> an application to an ongoing dialog. I don't think we should 
> >> prevent such things.
> >> 
> >
> > manufacturers are already supporting additional applications, and 
> > it's completely conceivable that a user of the phone might press a 
> > button to activate an application during an existing call. It would 
> > have been inappropriate for the phone to have offered to receive the 
> > related INFO packages during the call setup, but once the 
> > application is running they should be accepted (and in fact the act 
> > of starting the application may directly result in a re-INVITE for 
> > no other purpose than to update the Recv-Info package list the phone will accept).
> >
> >

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 09 Nov 2009 22:03:58 +0100

George,

OK, now we're getting somewhere - my point was to get the requirements 
being designed for explicitly on the table, and to not make things 
harder than they need to be

I don't know if there was ever an explicit list of requirements being 
addressed by Info Event - if people agree that your use case below (i.e. 
mid-dialog changes to the set of INFO packages a UA is willing to accept 
INFO requests for, for congestion avoidance purposes) is valid, in scope 
of this draft and desirable, then I suppose we could add the mechanism. 
I'd suggest that the editor add a separate section discussing such 
mid-dialog changes to the set, its intended purpose, and the required UA 
behavior (under section 4.2 perhaps)

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Nov 2009 00:36:01 +0100

Hi all,

I appretiate the input you have all provided. 

I am also glad that George provided some more details on the IPTV usage,
since I wasn't able to do that myself during the SIPCORE session. But, I
think that shows that there is an interest for this framework.

I still strgonly believe that mid-call changes are needed, and that
forbidding them may prevent future usages  - or usage people are working
on at the moment.

Regards,

Christer

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 10. marraskuuta 2009 0:04
To: George Foti
Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg;
[email-masked]

George,

Regards,
Jeroen

George Foti wrote:
> The ability for a SIP device to remove support for the reception of an
info-package mid-dialog is necessary and not an option.
> If we take the IPTV application, where we have an info package to 
> allow STBs and TV devices to tell the network the content currently 
> being watched (what the device is tuned to)
>
> The network must be able to stop  TV devices from reporting the
programs they are tuned when it so desires.
> Given that reporting occurs after end users start and stop zapping,
and given that zapping occurs after TV ads start showing up, and that
typically all IPTV users start zapping at that time, the network can be
crippled with all devices reporting at the same time if it cant stop
them at will.
>
> Just ignoring the SIP INFO as suggested by some does not make sense as
the congestion that this produces from devices re-attempting to send
etc, will cause even more harm.
>
> As such, comparing info-packages negotiated at dialog start-up to
dialog route is not appropriate and pre-judges how applications work,
which is quite dangerous.
>
> Certainly removing this flexibility will limit the ability to use the 
> SIP INFO and is a step backward and makes the use of legacy SIP INFO 
> more attractive without the overhead as the result of rejection is the

> same
> Behalf Of Linyi TIAN
> This looks more reasonable and simple. If we don't see real use cases
for changing set during the dialog we'd better not have a technical
solution for it. Or even there is limited use case, it is no harm to use
status code to ignore the INFO. This will reduce the protocol impact and
simply the implementation.

>> consistent with conventions used today, e.g. for Supported (suggest 
>> to simply use an empty value instead)
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Nov 2009 00:44:15 +0100

Hi, 

>I don't know if there was ever an explicit list of requirements being
addressed by Info Event - if people agree that your 
>use case below (i.e. mid-dialog changes to the set of INFO packages a
UA is willing to accept INFO requests for, for 
>congestion avoidance purposes) is valid, in scope of this draft and
desirable, then I suppose we could add the mechanism. 

Just to clarify: the possibility to add/remove packages has been in the
draft for a long time. That as such was not the original issue of this
thread :)

>I'd suggest that the editor add a separate section discussing such
mid-dialog changes to the set, its intended purpose, 
>and the required UA behavior (under section 4.2 perhaps)

I can take a look, to see whether it can be further clarified. Did you
look at the -03pre version?

Regards,

Christer

---

From: George Foti <[email-masked]>
Date: Mon, 9 Nov 2009 19:38:36 -0500

I would second Christer on the absolute need to support mid-dialog changes as mandatory and not optional.
The whole idea of Recv-Info is to say what U are *WILLING* to *receive*.
If I cant change that capability mid-dialog to stop reception that I no longer desire, then why bother with the framework.

This in effect would be almost equivalent to legacy SIP INFO and where I have no control, and where I can reject what I don't want to receive.
Recv-Info MUST allow me to get away from that, i.e receive and reject.

Hope that helps.
George

-----Original Message-----
From: Christer Holmberg 
Sent: Monday, November 09, 2009 6:36 PM
To: Jeroen van Bemmel; George Foti
Cc: Linyi TIAN; DRAGE, Keith (Keith); [email-masked]
Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

Hi all,

I am also glad that George provided some more details on the IPTV usage, since I wasn't able to do that myself during the SIPCORE session. But, I think that shows that there is an interest for this framework.

I still strgonly believe that mid-call changes are needed, and that forbidding them may prevent future usages  - or usage people are working on at the moment.

Regards,

Christer

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]]
Sent: 10. marraskuuta 2009 0:04
To: George Foti
Cc: Linyi TIAN; 'DRAGE, Keith (Keith)'; Christer Holmberg; [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

George,

OK, now we're getting somewhere - my point was to get the requirements being designed for explicitly on the table, and to not make things harder than they need to be

I don't know if there was ever an explicit list of requirements being addressed by Info Event - if people agree that your use case below (i.e. 
mid-dialog changes to the set of INFO packages a UA is willing to accept INFO requests for, for congestion avoidance purposes) is valid, in scope of this draft and desirable, then I suppose we could add the mechanism. 
I'd suggest that the editor add a separate section discussing such mid-dialog changes to the set, its intended purpose, and the required UA behavior (under section 4.2 perhaps)

Regards,
Jeroen

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 10 Nov 2009 09:41:50 +0800

Hi, All

The issue is that what use case we need to specify more than 2 Info Packages
and in the middle we want to stop sending one of them. Even the case George
mentioned it only needs one Info Package to be sent. In this case the UAS
can simply use Recv-Info='nil' to stop sending the packages.

We need a use case to justify this. I agree have mid-dialog negotiation is
flexible but if no application requires this why not make it simple? 

Cheers,
Linyi

> From: George Foti [mailto:[email-masked]]
> Sent: Tuesday, November 10, 2009 8:39 AM
> To: Christer Holmberg; Jeroen van Bemmel
header
> 
> I would second Christer on the absolute need to support mid-dialog changes
as
> mandatory and not optional.
> If I cant change that capability mid-dialog to stop reception that I no
longer desire,
> then why bother with the framework.
> 
> This in effect would be almost equivalent to legacy SIP INFO and where I
have no
> control, and where I can reject what I don't want to receive.
header
> I am also glad that George provided some more details on the IPTV usage,
since I
> wasn't able to do that myself during the SIPCORE session. But, I think
that shows
> that there is an interest for this framework.
> 
forbidding them
> may prevent future usages  - or usage people are working on at the moment.
> 
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
[email-masked]
header
> OK, now we're getting somewhere - my point was to get the requirements
being
> designed for explicitly on the table, and to not make things harder than
they need to
> I don't know if there was ever an explicit list of requirements being
addressed by Info
> Event - if people agree that your use case below (i.e.
INFO
> requests for, for congestion avoidance purposes) is valid, in scope of
this draft and
> I'd suggest that the editor add a separate section discussing such
mid-dialog
> changes to the set, its intended purpose, and the required UA behavior
(under
> section 4.2 perhaps)
info-package
> mid-dialog is necessary and not an option.
> > The network must be able to stop  TV devices from reporting the programs
they
> are tuned when it so desires.
> > Given that reporting occurs after end users start and stop zapping, and
given that
> zapping occurs after TV ads start showing up, and that typically all IPTV
users start
> zapping at that time, the network can be crippled with all devices
reporting at the
> same time if it cant stop them at will.
> >
the
> congestion that this produces from devices re-attempting to send etc, will
cause
> even more harm.
> >
> > As such, comparing info-packages negotiated at dialog start-up to dialog
route is
> not appropriate and pre-judges how applications work, which is quite
dangerous.
> > This looks more reasonable and simple. If we don't see real use cases
for changing
> set during the dialog we'd better not have a technical solution for it. Or
even there is
> limited use case, it is no harm to use status code to ignore the INFO.
This will reduce
> the protocol impact and simply the implementation.
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Nov 2009 02:54:27 +0100

Hi, 

>The issue is that what use case we need to specify more than 2 Info
Packages and in the middle we want to stop sending 
>one of them. Even the case George mentioned it only needs one Info
Package to be sent. In this case the UAS can simply 
>use Recv-Info='nil' to stop sending the packages.

Changing from 'Recv-Info:x' to 'Recv-Info:nil' *IS* a mid-call
notification.

>We need a use case to justify this. I agree have mid-dialog negotiation
is flexible but if no application requires this 
>why not make it simple? 

The modfication parts has been in the draft for a long time, and we are
now in WGLC (our 2nd WGLC, actually).

And, we don't know about what applications will come. We should not
again restrict something just because we don't have a use-case at this
moment, if we can make it work. If there are use-cases which need this
it will simply lead to that people continue using legacy INFO.

Regards,

Christer

header
as
longer desire,
> This in effect would be almost equivalent to legacy SIP INFO and where

> I
have no
header
since I
that shows
forbidding them
[email-masked]
header
being
they need to
addressed by Info
INFO
this draft and
mid-dialog
(under
info-package
> > programs
they
> > and
given that
users start
reporting at the
the
cause
> > dialog
route is
dangerous.
> >
> > Certainly removing this flexibility will limit the ability to use 
> > the SIP INFO and is a step backward and makes the use of legacy SIP 
> > INFO more attractive without the overhead as the result of rejection

> > is the same
for changing
even there is
This will reduce
> > So for the time being I support Jeroen's approach unless something 
> > new
is

> >> I also think it's overkill. Furthermore, I don't see a real world 
> >> use case for changing the set of supported INFO packages
mid-dialog.
> >> Surely the UAS can simply reply with a 403 response when it 
> >> receives an INFO request which it doesn't want to process anymore?
> >>
> >> To me, INFO packages should be like the Dialog's route set: learn 
> >> the supported set from the initial INVITE and 1xx-2xx responses, 
> >> after that don't change it anymore
> >>
> >> Regards,
> >> Jeroen
> >>

> >>>>> Based on the 3pcc issue raised by Paul, at the SIPCORE session 
> >>>>> we discussed whether we should mandate to include Recv-Info in
> >>>>>
> >>>>>
> >>>> re-INVITE
> >>>>
> >>>>
> >>>>> responses.
> >>>>>
> >>>>> the Recv-Info header only needs to be inserted if the set of 
> >>>>> Info Packages changes.
> >>>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Nov 2009 04:59:27 +0100

We seem to have drifted off the original issue.

My understanding was that we need to provide for the new endpoints learning the info packages supported after a redirection of transfer.

That means usage within a reINVITE is in some of these cases at least needed.

My concern is that I want to understand still which methods need to exchange this, and to do that I still need to see the flows justifying anything else other than the reINVITE. 

And I am still concerned about having to repeat in all and anything; I still want to see if it is possible to define a scheme where it is included only if it changes.

regards

Keith

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, November 10, 2009 1:54 AM
> To: Linyi TIAN; George Foti; Jeroen van Bemmel
> Cc: DRAGE, Keith (Keith); [email-masked]
> Changing from 'Recv-Info:x' to 'Recv-Info:nil' *IS* a 
> mid-call notification.
> 
> The modfication parts has been in the draft for a long time, 
> and we are now in WGLC (our 2nd WGLC, actually).
> 
> And, we don't know about what applications will come. We 
> should not again restrict something just because we don't 
> have a use-case at this moment, if we can make it work. If 
> there are use-cases which need this it will simply lead to 
> that people continue using legacy INFO.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > If I cant change that capability mid-dialog to stop 
> reception that I 
> > no
> longer desire,
> > > The ability for a SIP device to remove support for the 
> reception of 
> > > an
> info-package
> > > Some applications will not use SIP INFO any more if this 
> feature is 
> > > taken out
> > >
> > zapping occurs after TV ads start showing up, and that 
> typically all 
> > IPTV
> users start
> > > Just ignoring the SIP INFO as suggested by some does not 
> make sense 
> > > as
> the
> > congestion that this produces from devices re-attempting to 
> send etc, 
> > will
> cause
> > even more harm.
> > >
> [mailto:[email-masked]] On 
> > > Behalf Of Linyi TIAN
> [mailto:[email-masked]] On
> 
> > >> Behalf
> > >>
> > > Of
> > >
> > >> Jeroen van Bemmel
> everybody

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Nov 2009 05:26:10 +0100

Hi,

>My concern is that I want to understand still which methods need to exchange this, and to do that I still 
>need to see the flows justifying anything else other than the reINVITE. 

My suggestion is that we, within a dialog, allow Recv-Info in (re-)INVITE and UPDATE. UPDATE is useful if you want to change the set within a "normal" UE-to-UE dialog.

>And I am still concerned about having to repeat in all and anything; I still want to see if it is possible 
>to define a scheme where it is included only if it changes.

I agree.

And, again, I am not even sure that mandating it in every message would actually solve Paul's issue. But, I hope Paul will comment on that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Nov 2009 15:17:47 -0500

The most straightforward 3pcc case to explain is:

	A --------- B ---------- C
	            |
	            |----------- D

Initially, the 3pcc B2BUA B establishes coordinated dialogs A-B and B-C.
Later B decides to transfer the call from C to D. So it establishes a 
new dialog B-D and reinvites A to splice it in. I'm hand waving over the 
details, because there are many options and they don't matter here.

The key point is that A was, for all intents and purposes, initially 
connected to C, and after a reinvite finds itself connected to D.

Now D may not be able to support the same Info Packages that C did.
To make things work, the R-I values from D must be presented to A, and 
it needs to honor them.

Conversely, D needs to be informed of the info packages that A is 
willing to receive. While it is possible that B could have remembered 
them, and could thus insert them in the initial invite to D, its better 
if B doesn't have to get involved in that.

Many new features run into essentially the same problem with 3pcc. You 
just cannot assume state negotiated e2e will survive a reinvite.

And this is quite a bit different than the stability of route sets, 
because the route set distinct in each dialog. It doesn't go e2e through 
the B2BUA.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Nov 2009 00:27:36 +0100

Hi Paul,

Thanks for the description!

Now, assuming that B2BUA B does NOT support I-P (if B does support I-P,
there should be no issue), it would not insert Recv-Info (not even an
empty header) in the initial INVITE requests sent to A and C.

In addition, B would most likely not insert Recv-Info in the re-INVITE
request to D.

So, mandating Recv-Info in every message would not solve the issue.

(Not allowing mid-call changes would not solve the issue either, since C
and D can support a different set of Info Packages)

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 10. marraskuuta 2009 23:18
To: Jeroen van Bemmel
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header

	Thanks,
	Paul

Jeroen van Bemmel wrote:
> those packages they support up front. Therefore the "fully dynamic" 
> case you sketch below seems unlikely to me.
> 
> The only case I could imagine would be in case of long running 
> dialogs, where the software of one of the peers gets upgraded 
> mid-dialog to support some new INFO package. However, also that seems 
> highly unlikely to me.
> 
> learn the Route set for a Dialog" should be simple enough for 
> developers to get right
> 
> Regards,
> Jeroen
> 
> Christer Holmberg wrote:
>> Hi,
>>  
>>> use

>>> consistent

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Nov 2009 21:55:17 -0500

> So, mandating Recv-Info in every message would not solve the issue.

If Recv-Info is mandated in every message, then doesn't the absence of 
Recv-Info mean that it doesn't support Info packages at all, at least 
momentarily? (Until it sends a R-I.)

> and D can support a different set of Info Packages)

Yes, Definitely!

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Nov 2009 00:53:18 -0600

> because the route set distinct in each dialog. It doesn't go e2e through

my read:

B needs to initiate a reINVITE on A-B to inform A of the new info
capability presented on B-D.

--
dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Nov 2009 09:34:35 +0100

Hi, 

>>Now, assuming that B2BUA B does NOT support I-P (if B does support 
>>I-P, there should be no issue), it would not insert Recv-Info (not 
>>even an empty header) in the initial INVITE requests sent to A and C.
>> 

>If Recv-Info is mandated in every message, then doesn't the absence of
Recv-Info mean that it doesn't support Info 
>packages at all, at least momentarily? (Until it sends a R-I.)

Exactly, so if B doesn't support Info Packages then A, C and D will all
think that the other entity won't support Info-Packages, so that doesn't
solve the issue either.

But, one alternative to solve the case when B does support I-P (or, at
least is configured to insert Recv-Info) would be de define a specific
"audit" value for Recv-Info, which means "Please send your list of I-P
packages even if it hasn't changed".

Then, when B sends the re-INVITE to D it would include something like
Recv-Info:* (or whatever value we use for audit).

"*" could also be used with other listed packages, so when B sends D's
list to A it can ensure that A sends its list back so that D will get
it.

In my opinion that is far more nicer than mandating Revc-Info in every
message, and it actually solves some of the 3pcc use-cases :)

Would people be ok with that? 

Regards,

Christer

> new dialog B-D and reinvites A to splice it in. I'm hand waving over 
> the details, because there are many options and they don't matter
here.

> them, and could thus insert them in the initial invite to D, its 
> better if B doesn't have to get involved in that.
> 

> because the route set distinct in each dialog. It doesn't go e2e 
> through the B2BUA.
> 
> 	Thanks,
> 	Paul
> 
> Jeroen van Bemmel wrote:
>> Christer,
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Nov 2009 09:48:57 +0100

Hi, 

here.

D, when it receives the INVITE, will most likely return Recv-Info, since
it hasn't done it yet. 

But, unless B has stored the list of A, we need to make sure that A
returns its list in the re-INVITE response, so that D gets it.

I am not sure whether we should make things more complex just to support
the case when B does not support I-P.

B is a B2BUA, so it could store the Info Package list of the
participants, and then we don't have a problem.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Nov 2009 09:53:03 +0100

Hi,

Please forget the audit proposal until we decide on whether we could
agree on assuming that B supports Info Packages in order to make sure it
works between A and D. That would be even esier - we don't need to
mandate Recv-Info in every message, and we don't need to define the
audit :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: 11. marraskuuta 2009 11:35
To: Paul Kyzivat
Cc: [email-masked]; Jeroen van Bemmel
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header

Hi, 

Regards,

Christer

here.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 08:53:56 -0500

at end...

> capability presented on B-D.

This has come up because of questioning whether mid-call changes need be 
supported at all. What you say of course requires them.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Nov 2009 23:00:24 +0100

I am not sure we need to specify how B (the B2BUA) handles the Recv-Info header field in 3PCC situations. We just need to specify use of the header field in such a way that leaves at least one possible solution for B2BUAs. If this means B2BUAs need to store the latest Recv-Info contents from each UA, so that it can forward them when required, that would be a sufficient solution. The principle of mandating Recv-Info in each (re-)INVITE request and its 2xx response seems to permit a B2BUA to manage things appropriately.

John

> Sent: 11 November 2009 08:53
> To: Christer Holmberg; Paul Kyzivat
> >> Given the registration requirement (i.e. there needs to be 
> some sort 
> >> of
> >>> However, I want to ensure that nobody objects to such 
> change before 
> >>> I
> > 
> >>> implement it.
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>

---

From: Eric Burger <[email-masked]>
Date: Fri, 13 Nov 2009 07:19:28 +0900

Said differently, "live by the B2BUA, die by the B2BUA."  When you  
sign up to build a B2BUA, you are signing up to remember a ton of  
state.  Adding the Info-Package set for each remote UAC is trivial  
compared to the state (and risk you take by putting state in the  
network) you have to keep to keep the SIP session alive.

On Nov 13, 2009, at 7:00 AM, Elwell, John wrote:

> I am not sure we need to specify how B (the B2BUA) handles the Recv- 
> Info header field in 3PCC situations. We just need to specify use of  
> the header field in such a way that leaves at least one possible  
> solution for B2BUAs. If this means B2BUAs need to store the latest  
> Recv-Info contents from each UA, so that it can forward them when  
> required, that would be a sufficient solution. The principle of  
> mandating Recv-Info in each (re-)INVITE request and its 2xx response  
> seems to permit a B2BUA to manage things appropriately.
>
> John
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Nov 2009 19:07:42 -0500

> I am not sure we need to specify how B (the B2BUA) handles the Recv-Info header field in 3PCC situations. We just need to specify use of the header field in such a way that leaves at least one poss…

I think that works for me.
I've lost track - is R-I still ok in UPDATE, ACK, PRACK?

When a 3pcc controlling is initiating a call from the middle, it starts 
out not knowing anything about what either side can do. So it can't 
properly declare R-I in the INVITE. It will learn the capabilities of 
each side in the response to the INVITE. It would then like to reflect 
them to the "other side" asap, which means in one of the above. As long 
as it can do that, I think its ok.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 13 Nov 2009 02:59:42 +0100

Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE, ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a B2BUA to behave appropriately.

John 

> Sent: 13 November 2009 00:08
> To: Elwell, John
> Cc: Christer Holmberg; [email-masked]; Jeroen van Bemmel
> > I am not sure we need to specify how B (the B2BUA) handles 
> the Recv-Info header field in 3PCC situations. We just need 
> to specify use of the header field in such a way that leaves 
> at least one possible solution for B2BUAs. If this means 
> B2BUAs need to store the latest Recv-Info contents from each 
> UA, so that it can forward them when required, that would be 
> a sufficient solution. The principle of mandating Recv-Info 
> in each (re-)INVITE request and its 2xx response seems to 
> permit a B2BUA to manage things appropriately.
> 
> >>> Initially, the 3pcc B2BUA B establishes coordinated 
> dialogs A-B and
> >> B-C.
> "fully dynamic"
> >>>>>> Firstly can I ensure that this does not include 
> REGISTER, which 
> >>>>>> could
> >>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Nov 2009 08:53:22 -0500

> Perhaps what I should have said is that mandating Recv-Info in all request types for which it is defined (e.g., INVITE, ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to permit a…

Mandating is sufficient, but probably more than necessary.
Christer has been complaining about mandating.

Its probably sufficient to say that each *end* MUST *send* it at least 
once in each INVITE "cycle". Here I mean The INVITE request and the 
associated, provisional and final responses, PRACK and responses, UPDATE 
and response within the INVITE, and ACK. And perhaps in each 
"stand-alone" UPDATE transaction (outside of INVITE) as well.

Its an open question in my mind whether its worth the complexity of that 
definition, vs. just mandating it in all places, to avoid sending it so 
often.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Nov 2009 16:42:50 +0100

Hi, 

First, in case you have missed it, I have proposed to remove PRACK from
the list of allowed methods. Please indicate if you have a problem with
that.

Now, to the issue...

>>Perhaps what I should have said is that mandating Recv-Info in all
request types for which it is defined (e.g., INVITE, 
>>ACK, UPDATE, PRACK) and their 2xx responses should be sufficient to
permit a B2BUA to behave appropriately.
>Christer has been complaining about mandating.

I think there were others (Keith, at least) who didn't like it.

>Its probably sufficient to say that each *end* MUST *send* it at least
once in each INVITE "cycle". Here I mean The 
>INVITE request and the associated, provisional and final responses,
PRACK and responses, UPDATE and response within the 
>INVITE, and ACK. And perhaps in each "stand-alone" UPDATE transaction
(outside of INVITE) as well.

Wouldn't it be enough to say once per INVITE/ACK transaction only? I
don't think we would need to mandate it for UPDATE (no matter whether it
is "inside" the re-INVITE or not).

>Its an open question in my mind whether its worth the complexity of
that definition, vs. just mandating it in all places, 
>to avoid sending it so often.

Just because it may be "simple" documentation wise, it does create extra
work for parsers, when they have to compare the list, to see whether
something has changed.

Regards,

Christer

>> the Recv-Info header field in 3PCC situations. We just need to 
>> specify use of the header field in such a way that leaves at least 
>> one possible solution for B2BUAs. If this means B2BUAs need to store 
>> the latest Recv-Info contents from each UA, so that it can forward 
>> them when required, that would be a sufficient solution. The 
>> principle of mandating Recv-Info in each (re-)INVITE request and its 
>> 2xx response seems to permit a B2BUA to manage things appropriately.
>>
>> When a 3pcc controlling is initiating a call from the middle, it 
>> starts out not knowing anything about what either side can do. So it 
>> can't properly declare R-I in the INVITE. It will learn the 
>> capabilities of each side in the response to the INVITE. It would 
>> then like to reflect them to the "other side" asap, which means in 
>> one of the above. As long as it can do that, I think its ok.
>>
>> 	Thanks,
>> 	Paul
>>
>>> John
>>>

---

From: Bob Penfield <[email-masked]>
Date: Fri, 13 Nov 2009 11:15:29 -0500

Maybe I missed something, but why is there an issue with Recv-Info in a PRACK that would lead us to disallow it?

I think it is very useful to be able to update the Recv-Info in a PRACK. We allow INFO to be sent in an early dialog by the called UA after sending the 1xx response. However, if the 1xx is not sent reliable, it is possible that the 1xx would be lost and the called UA could receive an INFO for which it does not have a dialog. Allowing Recv-Info would allow for preventing this case by sending "Recv-Info: nil" in the INVITE and then sending an updated Recv-Info in the PRACK.

It also would allow the UAC to choose Info-Packages based on the content of the 1xx response. The selected I-Ps might be different for each UAS in a forking scenario.

For example, if a UAC included telephone-event (for 2833/4733) in the SDP offer in an INVITE and the SDP answer in the 1xx from the UAS did not include telephone event, but the 1xx included a Recv-Info. The UAC could then include supported DTMF Info-Packages in a Recv-Info in the PRACK.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, November 13, 2009 10:43 AM
To: Paul Kyzivat; Elwell, John
Cc: [email-masked]; Jeroen van Bemmel
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

Hi,

Now, to the issue...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Nov 2009 17:40:00 +0100

Hi, 

>Maybe I missed something, but why is there an issue with Recv-Info in a
PRACK that would lead us to disallow it?

It came from the idea of mandating Recv-Info in EVERY message where it
is allowed. 

However, if we can agree on solution to not mandate R-I in every
message, I am fine by allowing it in PRACK.

Regards,

Christer

-----Original Message-----

Hi,

Now, to the issue...

Regards,

Christer

>>>> agree on assuming that B supports Info Packages in order to make 
>>>> sure it works between A and D. That would be even esier - we don't 
>>>> need to mandate Recv-Info in every message, and we don't need to 
>>>> define the audit :)
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>

>>>> Exactly, so if B doesn't support Info Packages then A, C and D will

>>>> all think that the other entity won't support Info-Packages, so 
>>>> that doesn't solve the issue either.
>>>>
>>>>>>> package during a dialog. For example, assume I call you. Then, 
>>>>>>> during the dialog we decide to start using application X which
>>>> uses an Info
>>>>

---

From: Brett Tate <[email-masked]>
Date: Fri, 13 Nov 2009 08:54:35 -0800

>> Maybe I missed something, but why is there an issue with Recv-Info 
>> in a PRACK that would lead us to disallow it?
> 
> It came from the idea of mandating Recv-Info in EVERY message where 
> it is allowed.
> 

My opinion concerning PRACK is same as earlier this year.  The following is some text from earlier thread.

Because of race conditions, I prefer the header not be allowed.

It has been awhile since I read RFC 3262 in depth.  If UAS sends INVITE 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon receipt of PRACK?  If acceptable to return PRACK 200 during the race condition, should the PRACK's Recv-Info be ignored if received before or after ACK?  If it returns PRACK 200 and UAS receives PRACK 200 after INVITE 200, should the UAC ignore PRACK 200's Recv-Info?

http://www.ietf.org/mail-archive/web/sip/current/msg27037.html

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Nov 2009 17:54:45 -0600

On Nov 11, 2009, at 7:53 AM, Paul Kyzivat wrote:
> This has come up because of questioning whether mid-call changes  
> need be supported at all. What you say of course requires them.
>

But not in "just any" transaction. Info capabilities negotiation is  
much the same as session description -- INVITE and UPDATE transactions.

--
dean

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 15 Nov 2009 00:38:44 -0600

Pl. see inline ..

> Behalf Of Brett Tate
> Sent: Friday, November 13, 2009 10:25 PM
> To: Christer Holmberg; Bob Penfield; [email-masked]
> My opinion concerning PRACK is same as earlier this year.  The
> following is some text from earlier thread.
> 
> It has been awhile since I read RFC 3262 in depth.  If UAS sends
INVITE
> 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon
> receipt of PRACK? 
[Sanjay Sinha (sanjsinh)] Here is text from RFC 3262 about this:

  The UAS MAY send a final response to the initial request before
  having received PRACKs for all unacknowledged reliable provisional
  responses, unless the final response is 2xx and any of the
  unacknowledged reliable provisional responses contained a session
  description.  In that case, it MUST NOT send a final response until
  those provisional responses are acknowledged.  If the UAS does send a
  final response when reliable responses are still unacknowledged, it
  SHOULD NOT continue to retransmit the unacknowledged reliable
  provisional responses, but it MUST be prepared to process PRACK
  requests for those outstanding responses.

So the UAS is not allowed to send 200 to Invite if it is waiting for a
Prack for a reliable response with a sdp. Also the last sentence from
the rfc text above tells me that the response to Prack, if 200 to Invite
has been sent, should be 200 OK and not 481.

> If acceptable to return PRACK 200 during the race
> condition, should the PRACK's Recv-Info be ignored if received before
> or after ACK? 
[Sanjay Sinha (sanjsinh)] It should be ignored if received after ACK,
since ACK completes the Invite transaction.
If it returns PRACK 200 and UAS receives PRACK 200 after
> INVITE 200, should the UAC ignore PRACK 200's Recv-Info?
[Sanjay Sinha (sanjsinh)]  Yes, 200 OK to Invite is final response from
UAS.

Because of these race conditions, I think excluding RI from Prack will
be a good idea.

Sanjay

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Nov 2009 22:54:50 +0100

Hi,

I don't think the idea is that people start to update their I-P sets so
often that these kind of race conditions occur.

Regards,

Christer

-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
Sent: 15. marraskuuta 2009 8:39
To: Brett Tate; Christer Holmberg; Bob Penfield; [email-masked]
Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header

Pl. see inline ..

INVITE

> If acceptable to return PRACK 200 during the race condition, should 
> the PRACK's Recv-Info be ignored if received before or after ACK?

Sanjay

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Nov 2009 09:58:11 +0100

Hi,

Below is a modified version of the User Agent Behavior section.

It does define some simple rules, which do not mandate UAs to insert
Recv-Info "everywhere", and should also address Paul's 3pcc issue:

NOTE 1: You can provide pure editorial comments later - for now I am
only interested in whether people are ok with the concept.

NOTE 2: The secttion below does not specify whether Recv-Info is allowed
in PRACK or not. That is a separate issue.

NOTE 3: There were support, and no objections, to replace 'nil' with
empty R-I header, so I have implemented that also. However, if someone
still has an issue with that, let's deal with it in another thread.

------------

   A UA which supports the Info Package mechanism MUST indicate, using
   the Revc-Info header field, the set of Info Packages for which it is
   willing to receive INFO requests. A UA can list multiple Info
   Packages in a single Recv-Info header field, and the UA can use
   multiple Recv-Info header fields. A UA can an empty Recv-Info header
field, ie 
   a header field without any header field values.

   A UA provides its set of Info Packages for which it is willing to
receive 
   INFO requests during the dialog establishment. A UA can update the
set of 
   Info Packages during the invite dialog usage.

   If a UA is not willing to receive INFO requests for any Info
Packages, during 
   dialog establishment or later during the invite dialog usage, the UA
MUST indicate 
   this by including an empty Recv-Info header field. This informs other
UAs that the 
   UA still supports the Info Package mechanism.

   Example: If a UA has previously indicated Info Packages 'foo' and
   'bar', and the UA during the lifetime of the invite dialog usage
   wants to indicate that it does not want to receive INFO requests for
   any Info Packages anymore, the UA sends a target refresh request with
   an empty Recv-Info header field.

   A UA can provide its set of Info Package by using the SIP methods
(and their responses) 
   listed in Section 4. 

   Once a UA has sent a list of Info Packages, the list is valid until
   the UA sends a new list, or an empty Recv-Info header field.

   Once a UA has indicated that it is willing to receive INFO requests
   for a specific Info Package, and a dialog has been established, the
   UA MUST be prepared to receive INFO request associated with that Info
   Package.

   For a specific dialog, a UA MUST NOT send an INFO request associated
   with an Info Package until it has received an indication that the
   remote UA is willing to receive INFO requests for that Info Package.

   The rules below describe the situations when a UA is required to
include 
   a Recv-Info header field, alternatively when a UA is not allowed to
do it: 

   - The sender of an initial INVITE request MUST include a Recv-Info
header 
   field in the initial INVITE request, even if the sender is not
willing to 
   receive INFO requests asscoiated with any Info Package.

   - The receiver of an initial INVITE request MUST include a Recv-Info
header 
   in a reliable response to the INVITE request, even if the INVITE
request does 
   not contain a Recv-Info header field or the INVITE request contains
an empty 
   Recv-Info header field.

   NOTE: The rule above is specified mainly in order to support
3pcc/transfer 
   use-cases, where one needs to ensure that a UA provides its set of
Info Packages.

   - If a UA receives a request which contains a Recv-Info header field,
the 
   UA MUST include a Recv-Info header in a reliable response to the
request, even 
   if the set of Info Packages has not changed.

   - A UA MUST NOT update its set of Info Packages more than once per
SIP transaction. 
   A UA MAY repeat the Recv-Info header field in multiple responses to a
SIP request
  (for example, in 18x and 200 responses to an INVITE request).
 
   - If a UA includes a Recv-Info header field in an INVITE/re-INVITE
request, the 
   UA MUST NOT include a Recv-Info header field in the associated ACK
request.
 
   NOTE: If a UA receives a request which contains a set of Info
Packages, the UA 
   is not restricted to generate its own set of Info Packages as a
subset of the 
   received Info Package set. 

   specifications, to describe application behavior in such cases.

   For backward compatibility purpose, even if a UA indicates support of
   the Info Package mechanism, it is still allowed to enable legacy INFO
   usages [Section 9].

   This document does not define a SIP option tag [RFC3261] for the Info
   Package mechanism. However, an Info Package specification can define
   an option-tag associated with the specific Info Package, as described
   in [Section 10.5].

   For backward compatibility, if a UA indicates support of the INFO
   method using the Allow header field [RFC3261], it does not implicitly
   indicate support of the Info Package mechanism.  A UA MUST use the
   Recv-Info header field in order to indicate that it supports the Info
   Package mechanism.  Likewise, even if a UA uses the Recv-Info header
   field to indicate that it supports the Info Package mechanism, in
   addition the UA still indicates support of the INFO method using the
   Allow header.

-------------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Nov 2009 09:27:23 -0500

Christer,

I've indicated a few places inline where I think added clarification is 
required. But otherwise this approach works for me.

	Thanks,
	Paul

> still has an issue with that, let's deal with it in another thread.

This may be an editorial comment, or maybe not...

If the above sentence were strictly true then there would be no need for 
the 469 response. As long as there is the possibility of removing 
something from the list of packages one is willing to receive there is 
the possibility of a race condition, where one is no longer willing, but 
the package is still received. I think maybe there should be some words 
to that effect in this section.

>    remote UA is willing to receive INFO requests for that Info Package.

Similarly, a comment here that one must cease sending info requests for 
a package after receiving a new indication revoking willingness to 
receive that package.

>    - A UA MUST NOT update its set of Info Packages more than once per

Is the above really what you mean? Namely that it may update it once - 
i.e. send it twice with two different values?

I think you perhaps mean that a UA must not send two different values in 
the course of a single transaction.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Nov 2009 22:40:58 +0100

Hi,

>If the above sentence were strictly true then there would be no need
for the 469 response. As long as there is the possibility of removing
something from the list of packages one is willing to receive 
>there is the possibility of a race condition, where one is no longer
willing, but the package is still received. I think maybe there should
be some words to that effect in this section.

Maybe we could add:

"...until the UA indicates that it is no longer willing to receive INFO
requests associated with that Info Package."

-------------

I guess here we could also add: "..., and after the UA has received an
indication that the remote UA is no longer willing to receive INFO
requests associated with that Info Package."

-------------

SIP transaction.
>
>I think you perhaps mean that a UA must not send two different values
in the course of a single transaction.

Correct, I noted that myself also. So, maybe the text should say:

- A UA MUST NOT provide more than one set of Info Packages per SIP
transaction.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Nov 2009 17:29:54 -0500

Christer,

I think it is getting there. More inline.

	Thanks,
	Paul

> requests associated with that Info Package."

Works for me

> requests associated with that Info Package."

Just to be sure:

"For a specific dialog, a UA MUST NOT send an INFO request with an Info
Package until it has received an indication that the remote UA is
willing to receive INFO requests for that Info Package,
*or* and after the UA has received an indication that the remote UA is
no longer willing to receive INFO requests associated with that Info
Package."

Note substitution of "or" for "and" because we are discussing when it 
must NOT send.

> - A UA MUST NOT provide more than one set of Info Packages per SIP

I think that can still be construed that you are not allowed to send the 
same set again. How about:

- Once a UA has sent an indication of the Info Packages it is willing
to receive, it MUST NOT send an indication of a different set of 
packages within the same SIP transaction. (It MAY indicate the same set 
of packages again within the transaction.)

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Nov 2009 12:27:14 +0100

Hi, 

>>>Similarly, a comment here that one must cease sending info requests 
>>>for a package after receiving a new indication revoking willingness
to 

>"For a specific dialog, a UA MUST NOT send an INFO request 
>with an Info Package until it has received an indication that 
>the remote UA is willing to receive INFO requests for that 
>Info Package, *or* and after the UA has received an indication that the

>remote UA is no longer willing to receive INFO requests 
>associated with that Info Package."
> 
>Note substitution of "or" for "and" because we are discussing 
>when it must NOT send.

Correct.

---------

>>>>- A UA MUST NOT update its set of Info Packages more than once 
>>>>per SIP transaction.
>>>Is the above really what you mean? Namely that it may update it once 
>>> - i.e. send it twice with two different values?
>I think that can still be construed that you are not allowed 
>to send the same set again. How about:
> 
>- Once a UA has sent an indication of the Info Packages it is 
>willing to receive, it MUST NOT send an indication of a 
>different set of packages within the same SIP transaction. 
>(It MAY indicate the same set of packages again within the 
>transaction.)

Looks ok.

Thanks!

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Nov 2009 12:36:24 +0100

Folks,

We need to come to a conclusion on this topic: do we allow Recv-Info in
PRACK or not?

I hear those people saying that we have enough problems with allowing
SDPs etc in PRACK, and that we shouldn't add more.

I also hear those people saying that we would be able to re-use a PRACK,
instad of sending an UPDATE, if there is a need to provide a Info
Package set "in the middle of" an INVITE/re-INVITE transaction.

Personally, since I've been involved in the problems-with-PRACK
discussions, I would vote for NOT allowing it in PRACK. But, I will
implement whatever the group decides upon :)

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Wed, 18 Nov 2009 04:07:15 -0800

+1 for not allowing in PRACK.

> Sent: Wednesday, November 18, 2009 6:36 AM
> To: [email-masked]
> header - PRACK or no PRACK?
> 
> 
> Folks,
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 18 Nov 2009 06:10:05 -0600

It should not be allowed in Prack.

Thanks

> Sent: Wednesday, November 18, 2009 5:06 PM
> To: [email-masked]
> header- PRACK or no PRACK?
> 
> 
> 
> Folks,
>

---

From: Bob Penfield <[email-masked]>
Date: Wed, 18 Nov 2009 08:34:39 -0500

As I said before, I think allowing Recv-Info in a PRACK can be useful. Recv-Info does not have the problems that SDP has because it is NOT a negotiation, it is an advertisement. Whatever you last got in a Recv-Info is what you can send. I would recommend that Recv-Info be optional in a PRACK, but require that the same Recv-Info be sent in the ACK. I would also make Recv-Info optional in 1xx, but require the same Recv-Info in the 200-OK.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, November 18, 2009 6:36 AM
To: [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK?

Folks,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Nov 2009 20:58:30 -0500

Bob Penfield wrote:
> As I said before, I think allowing Recv-Info in a PRACK can be useful. Recv-Info does not have the problems that SDP has because it is NOT a negotiation, it is an advertisement. Whatever you last got in a Recv-Info is what you can send.

I agree.

> I would recommend that Recv-Info be optional in a PRACK,

Yes.

> but require that the same Recv-Info be sent in the ACK.
> I would also make Recv-Info optional in 1xx, but require the same Recv-Info in the 200-OK.

Why? I don't think this is necessary.

Especially for PRACK, you know if it got there when you get the 
response. No value in sending again later. And then it gets messy if you 
later change with an UPDATE before the ACK.

For 1xx, I would agree that if you send in an *unreliable* 1xx that you 
SHOULD send again in a reliable response or other message. But even 
then, you might change your mind and want to send something else.

How about just a note that if sent in an unreliable 1xx then it may not 
get there, and you should take that into account.

	Thanks,
	Paul

---

From: Bob Penfield <[email-masked]>
Date: Thu, 19 Nov 2009 07:56:44 -0500

I was trying to avoid race conditions where the ACK might arrive before the PRACK, which could occur if the UAS is allowed to send the 200-OK to the INVITE with an un-PRACKed 1xx that did not contain SDP. Maybe we should say that if Recv-Info was in a PRACK or UPDATE for an "early" dialog, that the ACK should not contain Recv-Info.

As far as repeating the Recv-Info in 200-OK, that should only apply for unreliable 1xx response.

cheers,
(-:bob

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, November 18, 2009 8:58 PM
To: Bob Penfield
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK?

I agree.

Yes.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 19 Nov 2009 14:09:50 +0100

Hi Bob,

Please take a look at the proposed rules I sent out some rules ago. In
normal cases you would not send Recv-Info in ACK.

Regards,

Christer 

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]] 
Sent: 19. marraskuuta 2009 14:57
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]
Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info

I was trying to avoid race conditions where the ACK might arrive before
the PRACK, which could occur if the UAS is allowed to send the 200-OK to
the INVITE with an un-PRACKed 1xx that did not contain SDP. Maybe we
should say that if Recv-Info was in a PRACK or UPDATE for an "early"
dialog, that the ACK should not contain Recv-Info.

As far as repeating the Recv-Info in 200-OK, that should only apply for
unreliable 1xx response.

cheers,
(-:bob

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Wednesday, November 18, 2009 8:58 PM
To: Bob Penfield
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info

Bob Penfield wrote:
> As I said before, I think allowing Recv-Info in a PRACK can be useful.
Recv-Info does not have the problems that SDP has because it is NOT a
negotiation, it is an advertisement. Whatever you last got in a
Recv-Info is what you can send.

I agree.

Yes.

	Thanks,
	Paul