Subject: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Aug 2016 20:22:25 -0400

Over in ecrit we have a disagreement that relates to interpreting RFC6086.

Background:
RFC7852 defines something called "Additional Data", which is carried in emergency call signaling.  It's data related to the call, e.g., the identity and contact data of the service provider handling the call.  Additional Data is signaled with a Call-Info header field, which contains either a URI pointing to a data block fetched with HTTPS, or a Content Indirect referencing a body part of the SIP message.  It's usually used on the INVITE of the emergency call, so it can be displayed to the PSAP (emergency call center) call-taker when the call is assigned.

Sometimes, this data can change during a call.  The example in discussion is telematics data in a vehicle.   The vehicle can report things like the number of occupants and its orientation.  The PSAP can request an update mid call (e.g., if the call taker thinks things might have changed).

INFO is the chosen mechanism to send the request for update.  The device will send a response to the request (an ACK), which is also sent in INFO.  This constitutes a well defined INFO package, and will be registered in the usual way.

The Issue at hand:
So, the dispute is how the updated data is sent mid call.

RFC6086 says

   NOTE: An INFO request can also contain other body parts that are
   meaningful within the context of an invite dialog usage but are
   not specifically associated with the INFO method and the
   application concerned.

The authors of the draft (of which I am one) desire to use the Additional Data mechanism to carry the updated data.  The data could be sent in any convenient message, although since the vehicle is sending an ACK, it's likely going to go on that.  We'd like to always carry the data in the same way.  In an INFO message it would be carried the same as it is in the INVITE, as Additional Data.  Since the INFO carries an ACK, it would specify the appropriate INFO package, and would contain a body part with the ACK.  There would be another body part for the updated data, pointed to by the Call-Info.

Some ecrit participants say that the above language of 6086 would prohibit the INFO from containing a Call-Info header with a CID pointing to a MIME body part, because the data was requested by an INFO, and hence is related to the INFO package.  They say that the data MUST be carried with a body part and Content Disposition that is part of the INFO package definition.

The draft authors claim this 6086 language isn't a straightjacket, and it's perfectly fine to carry the data referenced by a Call-Info with a Content Indirect body part using the same MIME type and Content Disposition as it would in an INVITE.   When the updated data is sent in INFO, it's because the INFO is a convenient message (since it's being sent to carry the ACK).

Mechanically, both mechanisms can be made to work.  The body parts would be labeled appropriately and there would be no confusion about what they mean or how they would be interpreted.  It's really only whether the Call-Info header is present and what the MIME type and Content Disposition the body part containing the data would be.  In the author's preferred way, it would be the MIME type and Content Disposition of the Call-Info and in the other point of view it would be the MIME type and Content Disposition of the INFO package.

Please ignore your personal preference for whether you think it ought to go in the INFO or not, and please help us interpret 6086: does the data HAVE to go in an INFO body part or can it be sent in a Call-Info body part?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 06:00:13 +0000

Hi,

I¹m glad this is brought to SIPCORE. As one of the info package
proponents, please let me clarify my arguments.

The 6086 text that Brian copied says ³but are not specifically associated
with the INFO method and the application concerned².

I claim that the updated data IS associated with the application concerned
(ecall). The updated data is requested by the ecall application, and the
delivered updated data is consumed by the ecall application. The updated
data is NOT some non-ecall-application-related information that is
piggybacked in a "convenient INFO message" that happens to be sent by the
ecall application for some other purpose.

(In addition, the updated data is NOT associated with a legacy (pre-6086)
INFO usage, which could justify not using an Info Package. I do want to
point out that nobody has claimed that the updated data would be
associated with legacy INFO, but just for completeness)

RFC 7852 does define a mechanism for transporting data, using Call-Info
etc. But, 7852 does not update 6086, nor can 7852 override rules and
procedures associated with individual SIP methods (INFO in this case). I
also pointed this out before 7852 was published, but was told that it¹s
too late to change it (granted, the draft was in the RFC editor¹s queue).

Finally, again for completeness, I want to point out that 6086 does not
prevent including Call-Info in INFO as such. The issue is how some want to
use Call-Info instead of an Info Package.

Regards,

Christer

On 25/08/16 03:22, "sipcore on behalf of Brian Rosen"
<[email-masked] on behalf of [email-masked]> wrote:

>RFC7852 defines something called "Additional Data", which is carried in
>emergency call signaling.  It's data related to the call, e.g., the
>identity and contact data of the service provider handling the call.
>Additional Data is signaled with a Call-Info header field, which contains
>either a URI pointing to a data block fetched with HTTPS, or a Content
>Indirect referencing a body part of the SIP message.  It's usually used
>on the INVITE of the emergency call, so it can be displayed to the PSAP
>(emergency call center) call-taker when the call is assigned.
>
>Sometimes, this data can change during a call.  The example in discussion
>is telematics data in a vehicle.   The vehicle can report things like the
>number of occupants and its orientation.  The PSAP can request an update
>mid call (e.g., if the call taker thinks things might have changed).
>
>INFO is the chosen mechanism to send the request for update.  The device
>will send a response to the request (an ACK), which is also sent in INFO.
> This constitutes a well defined INFO package, and will be registered in
>the usual way.
>
>The Issue at hand:
>The authors of the draft (of which I am one) desire to use the Additional
>Data mechanism to carry the updated data.  The data could be sent in any
>convenient message, although since the vehicle is sending an ACK, it's
>likely going to go on that.  We'd like to always carry the data in the
>same way.  In an INFO message it would be carried the same as it is in
>the INVITE, as Additional Data.  Since the INFO carries an ACK, it would
>specify the appropriate INFO package, and would contain a body part with
>the ACK.  There would be another body part for the updated data, pointed
>to by the Call-Info.
>
>Some ecrit participants say that the above language of 6086 would
>prohibit the INFO from containing a Call-Info header with a CID pointing
>to a MIME body part, because the data was requested by an INFO, and hence
>is related to the INFO package.  They say that the data MUST be carried
>with a body part and Content Disposition that is part of the INFO package
>definition.
>
>The draft authors claim this 6086 language isn't a straightjacket, and
>it's perfectly fine to carry the data referenced by a Call-Info with a
>Content Indirect body part using the same MIME type and Content
>Disposition as it would in an INVITE.   When the updated data is sent in
>INFO, it's because the INFO is a convenient message (since it's being
>sent to carry the ACK).
>
>Mechanically, both mechanisms can be made to work.  The body parts would
>be labeled appropriately and there would be no confusion about what they
>mean or how they would be interpreted.  It's really only whether the
>Call-Info header is present and what the MIME type and Content
>Disposition the body part containing the data would be.  In the author's
>preferred way, it would be the MIME type and Content Disposition of the
>Call-Info and in the other point of view it would be the MIME type and
>Content Disposition of the INFO package.
>
>Please ignore your personal preference for whether you think it ought to
>go in the INFO or not, and please help us interpret 6086: does the data
>HAVE to go in an INFO body part or can it be sent in a Call-Info body
>part?
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 08:56:01 -0400

We’re agreeing that there is a relationship between the command and the data.

We’re suggesting that we don’t have to be anal about the language and as long as there is an INFO package, and a body part that has the ACK which is an INFO body part, that the cited language doesn’t compel us to use the INFO body part to transport the data, the Call-Info mechanism is acceptable.

No one is suggesting that we update 6086, and we agree that 7852 did not update 6086.  

It’s just whether that language prohibits use of the Call-Info to carry the data when it was prompted by the INFO package request, and accompanies the INFO package ACK.

Brian

> On Aug 25, 2016, at 2:00 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 13:14:06 +0000

Hi,

>We’re suggesting that we don’t have to be anal about the language and as
>long as there is an INFO package, and a body part that has the ACK which
>is an INFO body part, that the cited language doesn’t compel us to use
>the INFO body part to transport the data, the Call-Info mechanism is
>acceptable.
>
>It’s just whether that language prohibits use of the Call-Info to carry
>the data when it was prompted by the INFO package request, and
>accompanies the INFO package ACK.

You seem to suggest that, just because you use an Info Package for sending
SOME of the ecall related information (the request and ACK), that allows
you to send the rest of the ecall related information (the data content)
without using an Info Package. I really don’t see how you can parse the
cited text in that way. The cited text says that information associated
with the application shall be sent using an Info Package. And, both the
ACK and the requested data content are associated with the ecall
application.

Regards,

Christer

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 09:26:32 -0400

Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and that it’s okay to send the data with Call-Info.

Yes, I’m agreeing that there is a relationship between the INFO package and the data.

Yes, I’m disagreeing with your interpretation of the language.

So, now, what say you sipcore?

Brian

> On Aug 25, 2016, at 9:14 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Aug 2016 09:47:23 -0400

Brian Rosen <[email-masked]> writes:
> INFO is the chosen mechanism to send the request for update.  The
> device will send a response to the request (an ACK), which is also
> sent in INFO.  This constitutes a well defined INFO package, and will
> be registered in the usual way.

Interesting.  I would have expected the update (and effectively the ACK)
to be in the response to the INFO request.  Presumably there's a reason
that doesn't work.

Dale

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 09:56:30 -0400

I believe there can be a time delay between asking for it and getting the data.  For the moment, that’s not germane, although the data could come in the response to the INFO.
The same issues would apply.

Do you think the language in 6086 prohibits the data to come in a Call-Info body part, whether in an INFO or a response to an INFO?

Brian

> On Aug 25, 2016, at 9:47 AM, Dale R. Worley <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2016 10:32:20 -0400

> So, now, what say you sipcore?

I think the main point of bringing this to sipcore is to get some fresh 
input into this discussion. Since I have been party to the discussion 
over in ecrit I don't bring anything fresh here. But for completeness I 
will register my opinion here too.

IMO this is not a question about whether the proposed usage is valid 
according to 6086 and other rfcs. (I think it is quite clear that it 
*is* valid.) Rather this is simply a question of what is the best design 
for the desired functionality. As such I don't think it really needs to 
be settled in sipcore.

But I am happy to check if anybody has a different perspective on this.

	Thanks,
	Paul

>>>>> device

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 14:58:05 +0000

Paul, a generic question, which might help me understand your view on ecall: in your opinion, when (if ever) is usage of an Info Package required?

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25 August 2016 17:32
To: [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

> So, now, what say you sipcore?

I think the main point of bringing this to sipcore is to get some fresh input into this discussion. Since I have been party to the discussion over in ecrit I don't bring anything fresh here. But for completeness I will register my opinion here too.

IMO this is not a question about whether the proposed usage is valid according to 6086 and other rfcs. (I think it is quite clear that it
*is* valid.) Rather this is simply a question of what is the best design for the desired functionality. As such I don't think it really needs to be settled in sipcore.

	Thanks,
	Paul

>>> We’re suggesting that we don’t have to be anal about the language 
>>> and as long as there is an INFO package, and a body part that has 
>>> the ACK which is an INFO body part, that the cited language doesn’t 
>>> compel us to use the INFO body part to transport the data, the 
>>> Call-Info mechanism is acceptable.
>>>
>>> It’s just whether that language prohibits use of the Call-Info to 
>>> carry the data when it was prompted by the INFO package request, and 
>> You seem to suggest that, just because you use an Info Package for 
>> sending SOME of the ecall related information (the request and ACK), 
>> that allows you to send the rest of the ecall related information 
>> (the data content) without using an Info Package. I really don’t see 
>> how you can parse the cited text in that way. The cited text says 
>> that information associated with the application shall be sent using 
>> an Info Package. And, both the ACK and the requested data content are 
>> associated with the ecall application.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>>
>>> Brian
>>>
>>>> The 6086 text that Brian copied says ³but are not specifically 
>>>> associated with the INFO method and the application concerned².
>>>>
>>>> I claim that the updated data IS associated with the application 
>>>> concerned (ecall). The updated data is requested by the ecall 
>>>> application, and the delivered updated data is consumed by the 
>>>> ecall application. The updated data is NOT some 
>>>> non-ecall-application-related information that is piggybacked in a 
>>>> "convenient INFO message" that happens to be sent by the ecall 
>>>> application for some other purpose.
>>>>
>>>> INFO usage, which could justify not using an Info Package. I do 
>>>> want to point out that nobody has claimed that the updated data 
>>>> would be associated with legacy INFO, but just for completeness)
>>>>
>>>> RFC 7852 does define a mechanism for transporting data, using 
>>>> Call-Info etc. But, 7852 does not update 6086, nor can 7852 
>>>> override rules and procedures associated with individual SIP 
>>>> methods (INFO in this case). I also pointed this out before 7852 
>>>> was published, but was told that it¹s too late to change it 
>>>> (granted, the draft was in the RFC editor¹s queue).
>>>>
>>>> Finally, again for completeness, I want to point out that 6086 does 
>>>> not prevent including Call-Info in INFO as such. The issue is how 
>>>> some want to use Call-Info instead of an Info Package.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>> RFC7852 defines something called "Additional Data", which is 
>>>>> carried in emergency call signaling.  It's data related to the 
>>>>> call, e.g., the identity and contact data of the service provider handling the call.
>>>>> Additional Data is signaled with a Call-Info header field, which 
>>>>> contains either a URI pointing to a data block fetched with HTTPS, 
>>>>> or a Content Indirect referencing a body part of the SIP message.  
>>>>> It's usually used on the INVITE of the emergency call, so it can 
>>>>> be displayed to the PSAP (emergency call center) call-taker when 
>>>>> the call is assigned.
>>>>>
>>>>> number of occupants and its orientation.  The PSAP can request an 
>>>>> update mid call (e.g., if the call taker thinks things might have 
>>>>> changed).
>>>>>
>>>>> sent in INFO.
>>>>> This constitutes a well defined INFO package, and will be 
>>>>> registered in the usual way.
>>>>>
>>>>> The Issue at hand:
>>>>> The authors of the draft (of which I am one) desire to use the 
>>>>> Additional Data mechanism to carry the updated data.  The data 
>>>>> could be sent in any convenient message, although since the 
>>>>> vehicle is sending an ACK, it's likely going to go on that.  We'd 
>>>>> like to always carry the data in the same way.  In an INFO message 
>>>>> it would be carried the same as it is in the INVITE, as Additional 
>>>>> Data.  Since the INFO carries an ACK, it would specify the 
>>>>> appropriate INFO package, and would contain a body part with the 
>>>>> ACK.  There would be another body part for the updated data, 
>>>>> pointed to by the Call-Info.
>>>>>
>>>>> prohibit the INFO from containing a Call-Info header with a CID 
>>>>> pointing to a MIME body part, because the data was requested by an 
>>>>> INFO, and hence is related to the INFO package.  They say that the 
>>>>> data MUST be carried with a body part and Content Disposition that 
>>>>> is part of the INFO package definition.
>>>>>
>>>>> The draft authors claim this 6086 language isn't a straightjacket, 
>>>>> and it's perfectly fine to carry the data referenced by a 
>>>>> Call-Info with a Content Indirect body part using the same MIME type and Content
>>>>> INFO, it's because the INFO is a convenient message (since it's 
>>>>> being sent to carry the ACK).
>>>>>
>>>>> Mechanically, both mechanisms can be made to work.  The body parts 
>>>>> would be labeled appropriately and there would be no confusion 
>>>>> about what they mean or how they would be interpreted.  It's 
>>>>> really only whether the Call-Info header is present and what the 
>>>>> MIME type and Content Disposition the body part containing the 
>>>>> data would be.  In the author's preferred way, it would be the 
>>>>> MIME type and Content Disposition of the Call-Info and in the 
>>>>> other point of view it would be the MIME type and Content 
>>>>> Disposition of the INFO package.
>>>>>
>>>>> Please ignore your personal preference for whether you think it 
>>>>> ought to go in the INFO or not, and please help us interpret 6086: 
>>>>> does the data HAVE to go in an INFO body part or can it be sent in 
>>>>> a Call-Info body part?
>>>>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 25 Aug 2016 15:17:29 +0000

Time to express my opinion.

In some circumances, ecall needs to transfer data outside of a normal call control message.

The viewpoint is that an INFO message might do that. To use INFO methods, one MUST define an Info package. There is not other requirement in ecall for an Info package to exist, so the Info package MUST be one specific to transferring the ecall data, not an Info package for something else that just happens to be supporting ecall data transfer because it is already there.

Transferring data in Info packages is well known. It does not require the use of a Call-Info header field to describe the usage. The usage is defined by the Info-package header field. Using the Call-Info header field would provide two means of describing the purpose of the same message body and lead to all sorts of error handling issues when they become in conflict (because someone failed to read the specification or some other reason). This my view is clearly that we should follow the rules of clean design and not do this, particularly as in my view it is totally unneccessary.

The remainder goes more into ecall requirements, and therefore falls more to the scope of ecrit and 3GPP, but indicates why I think it is unnecessary.

Ecall consists of two parts - data transferred in the initial INVITE message. No one has objected to additional data to perform this function. Further in some circumstances, the PSAP can request more data to be sent outside that initial request and outside further call control messages. It is here where the Info package discussion comes in. My view strongly expressed is that these can be treated from the SIP viewpoint as two entirely separate transport mechanisms, completely operating independently at the SIP later. At some point they both transfer an MSD, but that is separately identified by other header fields. It is then up to the application in both the PSAP and the calling user agent to control how these two independent data transfer mechanisms are used. As such there is no need to start defining interactions between Info packages and additional data, and no need for one to update the other.

Regards

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25 August 2016 15:32
To: [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2016 11:34:11 -0400

> Paul, a generic question, which might help me understand your view on ecall: in your opinion, when (if ever) is usage of an Info Package required?

I guess I would phrase it this way:

If you have a need to transmit some information via a sip session, then 
you should consider all the available mechanisms sip has, and decide if 
there is some combination of existing mechanisms that meets your need.

The following are some of the available mechanisms:

- new event packages
- new info packages
- new qualifying options with call-info, alert-info, error-info
- newly defined header field parameters
- new defined header fields

Many of these mechanisms have their own rules for what sorts of new 
usage are appropriate. Others do not, and are probably deficient because 
of that. For those, the bar is generally the need to get a RFC approved.

INFO is notable because the bar is pretty low (Specification Required). 
So some may choose it for its ease.

When choosing among the options, you have to consider what the approval 
processes will be for each, and that the reviewers will probably ask if 
you have considered alternative approaches.

For instance Geolocation was done with a new header field that sometimes 
references a separate body part. That raised a higher hurdle to get over 
than using an info package. But it was deemed worth it since it had 
needs that couldn't be met by info packages.

In general there are likely to be multiple options available for almost 
anything you want to do. And then it will come down to weighing the 
pros/cons.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 15:40:30 +0000

Hi Paul,

I am not talking about the criteria for selecting INFO in the first place (instead of e.g. event packages).

I am asking: assuming you have determined (based on whatever criteria) that the INFO message is the most appropriate mechanism, when are you required to use Info Package?

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 25 August 2016 18:34
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

If you have a need to transmit some information via a sip session, then you should consider all the available mechanisms sip has, and decide if there is some combination of existing mechanisms that meets your need.

- new event packages
- new info packages

Many of these mechanisms have their own rules for what sorts of new usage are appropriate. Others do not, and are probably deficient because of that. For those, the bar is generally the need to get a RFC approved.

When choosing among the options, you have to consider what the approval processes will be for each, and that the reviewers will probably ask if you have considered alternative approaches.

For instance Geolocation was done with a new header field that sometimes references a separate body part. That raised a higher hurdle to get over than using an info package. But it was deemed worth it since it had needs that couldn't be met by info packages.

In general there are likely to be multiple options available for almost anything you want to do. And then it will come down to weighing the pros/cons.

	Thanks,
	Paul

>>>> carry the data when it was prompted by the INFO package request, 
>>>> and accompanies the INFO package ACK.
>>>
>>> an Info Package. And, both the ACK and the requested data content 
>>> are associated with the ecall application.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Brian
>>>>
>>>>> Finally, again for completeness, I want to point out that 6086 
>>>>> does not prevent including Call-Info in INFO as such. The issue is 
>>>>> how some want to use Call-Info instead of an Info Package.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>>> contains either a URI pointing to a data block fetched with 
>>>>>> HTTPS, or a Content Indirect referencing a body part of the SIP message.
>>>>>> device will send a response to the request (an ACK), which is 
>>>>>> also sent in INFO.
>>>>>> like to always carry the data in the same way.  In an INFO 
>>>>>> message it would be carried the same as it is in the INVITE, as 
>>>>>> Additional Data.  Since the INFO carries an ACK, it would specify 
>>>>>> the appropriate INFO package, and would contain a body part with 
>>>>>> the ACK.  There would be another body part for the updated data, 
>>>>>> pointing to a MIME body part, because the data was requested by 
>>>>>> an INFO, and hence is related to the INFO package.  They say that 
>>>>>> the data MUST be carried with a body part and Content Disposition 
>>>>>> that is part of the INFO package definition.
>>>>>>
>>>>>> The draft authors claim this 6086 language isn't a 
>>>>>> straightjacket, and it's perfectly fine to carry the data 
>>>>>> referenced by a Call-Info with a Content Indirect body part using the same MIME type and Content
>>>>>> Mechanically, both mechanisms can be made to work.  The body 
>>>>>> parts would be labeled appropriately and there would be no 
>>>>>> confusion about what they mean or how they would be interpreted.  
>>>>>> It's really only whether the Call-Info header is present and what 
>>>>>> the MIME type and Content Disposition the body part containing 
>>>>>> the data would be.  In the author's preferred way, it would be 
>>>>>> the MIME type and Content Disposition of the Call-Info and in the 
>>>>>> does the data HAVE to go in an INFO body part or can it be sent 
>>>>>> in a Call-Info body part?
>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2016 11:50:31 -0400

> I am asking: assuming you have determined (based on whatever criteria) that the INFO message is the most appropriate mechanism, when are you required to use Info Package?

That is easy. In a call where you have negotiated use of Info Package X, 
you should:

- use info package X for those things it is designed for;
- use other mechanisms for things those are designed for.

If you find something where it is ambiguous whether to use X or some 
other mechanism then I think your definition of package X is inadequate.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 15:56:58 +0000

Hi,

>> I am asking: assuming you have determined (based on whatever criteria) that the INFO message is the
>> most appropriate mechanism, when are you required to use Info Package?
>
> That is easy. In a call where you have negotiated use of Info Package X, you should:
>
> If you find something where it is ambiguous whether to use X or some other mechanism then I think your definition of package X is inadequate.

That's still not what I'm asking. When you define a package, you obviously need to define it correctly, but my question is when you have to define a package to begin with.

Or, to put it in another way: Assuming I want to send content X using INFO. How do I determine whether I need to define an Info Package for that, or whether I can send it in INFO without defining an Info Package?

Regards,

Christer

>>>>> the ACK which is an INFO body part, that the cited language 
>>>>> doesn’t compel us to use the INFO body part to transport the data, 
>>>>> the Call-Info mechanism is acceptable.
>>>>>
>>>> sending SOME of the ecall related information (the request and 
>>>> ACK), that allows you to send the rest of the ecall related 
>>>> information (the data content) without using an Info Package. I 
>>>> really don’t see how you can parse the cited text in that way. The 
>>>> cited text says that information associated with the application 
>>>> shall be sent using an Info Package. And, both the ACK and the 
>>>> requested data content are associated with the ecall application.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Brian
>>>>>
>>>>>> non-ecall-application-related information that is piggybacked in 
>>>>>> a "convenient INFO message" that happens to be sent by the ecall 
>>>>>> does not prevent including Call-Info in INFO as such. The issue 
>>>>>> is how some want to use Call-Info instead of an Info Package.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>>> number of occupants and its orientation.  The PSAP can request 
>>>>>>> an update mid call (e.g., if the call taker thinks things might 
>>>>>>> have changed).
>>>>>>>
>>>>>>> INFO is the chosen mechanism to send the request for update.  
>>>>>>> The device will send a response to the request (an ACK), which 
>>>>>>> is also sent in INFO.
>>>>>>> vehicle is sending an ACK, it's likely going to go on that.  
>>>>>>> We'd like to always carry the data in the same way.  In an INFO 
>>>>>>> Additional Data.  Since the INFO carries an ACK, it would 
>>>>>>> specify the appropriate INFO package, and would contain a body 
>>>>>>> part with the ACK.  There would be another body part for the 
>>>>>>> updated data, pointed to by the Call-Info.
>>>>>>>
>>>>>>> Some ecrit participants say that the above language of 6086 
>>>>>>> would prohibit the INFO from containing a Call-Info header with 
>>>>>>> a CID pointing to a MIME body part, because the data was 
>>>>>>> requested by an INFO, and hence is related to the INFO package.  
>>>>>>> They say that the data MUST be carried with a body part and 
>>>>>>> Content Disposition that is part of the INFO package definition.
>>>>>>>
>>>>>>> It's really only whether the Call-Info header is present and 
>>>>>>> what the MIME type and Content Disposition the body part 
>>>>>>> containing the data would be.  In the author's preferred way, it 
>>>>>>> would be the MIME type and Content Disposition of the Call-Info 
>>>>>>> and in the other point of view it would be the MIME type and

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 Aug 2016 09:58:42 -0700

At 6:00 AM +0000 8/25/16, Christer Holmberg wrote:

>  (ecall).

Since we have a request/response protocol carried in INFO and using a 
well-defined INFO package, we can define "the application concerned" 
as this request/response protocol, which is part of the larger eCall 
application.  (Not just eCall, it will also be a part of other 
emergency call applications.)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If God had really intended men to fly, He'd make it easier to get to the
airport.                          --George Winters

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 13:03:23 -0400

I asked that you not base your response (here in sippcore) on how you PREFER to transport the data.  We have a language interpretation that Christer asked to take to sipcore: does the language in 6086 PROHIBIT the data from being carried in Call-Info?

sipcore should not opine on what ecrit SHOULD do, but only what it COULD do with respect to 6086.

Is it your opinion that 6086 prohibits us from carrying the data in Call-Info?

Brian

> On Aug 25, 2016, at 11:17 AM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 Aug 2016 10:07:50 -0700

We're getting into the ECRIT discussion, which as Paul noted is not 
the intent of bringing this to sipcore.  But I did want to respond to 
two points:

At 3:17 PM +0000 8/25/16, Keith (Nokia - GB) Drage wrote:

>  Transferring data in Info packages is well known. It does not 
> require the use of a Call-Info header field to describe the usage. 
> The usage is defined by the Info-package header field. Using the 
> Call-Info header field would provide two means of describing the 
> purpose of the same message body and lead to all sorts of error 
> handling issues when they become in conflict (because someone 
> failed to read the specification or some other reason). This my 
> view is clearly that we should follow the rules of clean design and 
> not do this, particularly as in my view it is totally unneccessary.

The authors want to have the vehicle telematics data always sent the 
same way, so there is only one way of doing so, not two.

>  Ecall consists of two parts - data transferred in the initial 
> INVITE message. No one has objected to additional data to perform 
> this function. Further in some circumstances, the PSAP can request 
> more data to be sent outside that initial request and outside 
> further call control messages. It is here where the Info package 
> discussion comes in. My view strongly expressed is that these can 
> be treated from the SIP viewpoint as two entirely separate 
> transport mechanisms, completely operating independently at the SIP 
> later. At some point they both transfer an MSD, but that is 
> separately identified by other header fields. It is then up to the 
> application in both the PSAP and the calling user agent to control 
> how these two independent data transfer mechanisms are used. As 
> such there is no need to start defining interactions between Info 
> packages and additional data, and no need for one to update the 
> other.

The authors of the draft want to have one mechanism for transporting 
the vehicle data.  There is another, separate mechanism, that 
requests the vehicle to take an action.  In eCall, this action is 
limited to sending updated data.  In the car-crash draft, the action 
is extended to other things (e.g., flash the lights).  This mechanism 
uses a request/response protocol, which is carried in INFO and uses a 
well-defined INFO package.

-------------- Randomly selected tag: ---------------
We must abandon the prevalent belief in the superior wisdom of the
ignorant.          --Daniel J. Boorstin

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 17:43:46 +0000

Hi,

> I asked that you not base your response (here in sippcore) on how you PREFER to transport the data.  
> We have a language interpretation that Christer asked to take to sipcore: does the language in 6086 PROHIBIT the data from being carried in Call-Info?

As I indicated in ECRIT, I think that is the wrong question to ask SIPCORE.

6086 does not recognize "data being carried in Call-Info". As far as 6086 is concerned, you either use an Info Package, or you don't, and the question is whether you have to use an Info Package.

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 25 Aug 2016 18:10:34 +0000

I agree with Christer. The determining factor is what falls in the scope of SIPCORE to pass judgement on, and not necessarily the question you (Brian) asked.

To respond to that problem, I had to provide more information that you (Brian) cared to do. I think the question failed to be asked adequately in your mail.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 25 August 2016 18:44
To: Brian Rosen; Drage, Keith (Nokia - GB)
Cc: [email-masked]
Subject: RE: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

Hi,

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 25 Aug 2016 18:10:33 +0000

I think it is not a prohibition - it has a semantic after all, but rather a deviation from best practice of keeping things simple. Adding it in respect of the Info-Package has to have zero impact. 

If using INFO, then the Info-Package defines what is carried, using the Info-Package header field. Adding Call-Info is not belt and braces, rather it is nothing to do with the correct operation of the Info-Package and therefore a complexity that will definitely lead to error prone implementations.

Are you going to now start proposing adding the Call-Info header field to all usages of the Geolocation header field that point to a message body, because that is the logical progression of using it in respect of the Info package data contents.

Keith

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 25 August 2016 18:03
To: Drage, Keith (Nokia - GB)
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

Brian

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 25 Aug 2016 18:10:33 +0000

>	The authors want to have the vehicle telematics data always sent the same way, so there is only one way of doing so, not two.

The you cannot use additional-data because that does not allow messages to be sent purely on the need of the data, and you cannot use the Info-Package if you want to send stuff in the INVITE request. 

Therefore your requirement cannot be met.

>	The authors of the draft want to have one mechanism for transporting the vehicle data.  There is another, separate mechanism, that requests the vehicle to take an action.  In eCall, this action is limited to sending updated data.  In the car-crash draft, the action is extended to other things (e.g., flash the lights).  This mechanism uses a request/response protocol, which is carried in INFO and uses a well-defined INFO package.

Car-crash is nothing to do with ecall. Ecall works to a set of requirements defined by 3GPP and takes place in a 3GPP emergency call over IMS. Car-crash is apparently defined as something over the top that does not use IMS within a 3GPP, and IS NOT a 3GPP emergency call.

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 25 August 2016 18:08
To: Drage, Keith (Nokia - GB); Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

We're getting into the ECRIT discussion, which as Paul noted is not the intent of bringing this to sipcore.  But I did want to respond to two points:

At 3:17 PM +0000 8/25/16, Keith (Nokia - GB) Drage wrote:

>  Transferring data in Info packages is well known. It does not require 
> the use of a Call-Info header field to describe the usage.
> handling issues when they become in conflict (because someone failed 
> to read the specification or some other reason). This my view is 
> clearly that we should follow the rules of clean design and not do 
> this, particularly as in my view it is totally unneccessary.

>  Ecall consists of two parts - data transferred in the initial INVITE 
> message. No one has objected to additional data to perform this 
> function. Further in some circumstances, the PSAP can request more 
> data to be sent outside that initial request and outside further call 
> control messages. It is here where the Info package discussion comes 
> in. My view strongly expressed is that these can be treated from the 
> SIP viewpoint as two entirely separate transport mechanisms, 
> completely operating independently at the SIP later. At some point 
> they both transfer an MSD, but that is separately identified by other 
> header fields. It is then up to the application in both the PSAP and 
> the calling user agent to control how these two independent data 
> transfer mechanisms are used. As such there is no need to start 
> defining interactions between Info packages and additional data, and 
> no need for one to update the other.

The authors of the draft want to have one mechanism for transporting the vehicle data.  There is another, separate mechanism, that requests the vehicle to take an action.  In eCall, this action is limited to sending updated data.  In the car-crash draft, the action is extended to other things (e.g., flash the lights).  This mechanism uses a request/response protocol, which is carried in INFO and uses a well-defined INFO package.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- We must abandon the prevalent belief in the superior wisdom of the
ignorant.          --Daniel J. Boorstin

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Aug 2016 15:05:14 -0400

Actually, that’s a very good question.

Suppose I used a variation on the same INFO package that triggered a new location-by-value update.

Does the location have to come in an INFO package block, or can it come in a Geolocation header CID bock?

Brian

> On Aug 25, 2016, at 2:10 PM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2016 16:37:21 -0400

> Or, to put it in another way: Assuming I want to send content X using INFO. How do I determine whether I need to define an Info Package for that, or whether I can send it in INFO without defining a…

Depends on what you mean by "send it in INFO".

I take that to mean: send it in the INFO body/body part.

When you are talking about "legacy" INFO (without info package) then the 
body usage is very ill-defined. You are expected to only be using it for 
legacy usage - stuff that is "grandfathered in". So I don't think that 
even applies to this question.

But this is dancing around stuff that is defined by some means other 
than method. If you say "you want to send it using INFO" then I would 
expect the content to be contained within the info package body. OTOH, 
if you just want to send X in a lot of circumstances, then you might 
choose a different method (such as call-info) that isn't 
method-specific. If you do that, then it can go anywhere a call-info can 
go, which happens to include INFO.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2016 17:01:20 -0400

This is mostly getting outside the scope of sipcore. But maybe this one 
part is in scope...

On 8/25/16 2:10 PM, Drage, Keith (Nokia - GB) wrote:

> The you cannot use additional-data because that does not allow messages to be sent purely on the need of the data,

I disagree.

Consider for a moment session timer. In principle all it needs to do is 
signal *something* from end to end through all the session signaling 
intermediaries. It doesn't really need the function of any particular 
message. But to do so it triggers the sending of INVITE or UPDATE. Note 
in particular that the UPDATE can be effectively a no-op aside from its 
session-timer updating. (It need not carry an offer, though it MAY.) And 
the resulting message does its job without any of the recipients knowing 
if it was sent solely because it was needed for session timer, or if it 
was going anyway but serves also to refresh the session timer.

The same can be true for additional-data (or any usage of call-info). 
The additional-data transport can be piggybacked on a message that is 
already being sent for some other purpose, or some benign message can be 
sent specifically to serve as the vehicle for the additional-data. It 
could be INVITE or UPDATE. Or it could be INFO if you have some info 
package that you want to send at that time, or it could be the response 
to an INFO package if you happen to need to respond to one at the same 
time that you need to send the additional-data.

In the case where you have just received an INFO containing an 
indication that fresh additional-data would be appreciated, it may be 
really convenient to piggyback the additional-data on the response to 
that INFO. I see no problem with that.

Note that some other implementation might not find it convenient to 
piggyback that way. (Maybe it takes awhile to generate the fresh data 
and it doesn't want to delay the response.) Then that implementation may 
need to find some other message to carry the additional-data.

I do not see how that violates the letter or spirit of SIP.

What *would* violate the spirit of sip would be something similar that 
sends high volume and frequent data over the signaling channel.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Aug 2016 17:49:44 -0400

Brian Rosen <[email-masked]> writes:
> I believe there can be a time delay between asking for it and getting
> the data.  For the moment, that's not germane, although the data could
> come in the response to the INFO.

In addition to the fact that the caller may delay sending the data so
long that the INFO transaction should not be delayed for it, RFC 6086
section 4.3.2 forbids message bodies in responses to INFO requests with
an Info Package.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Aug 2016 19:27:51 -0400

BTW, what is the name of the draft in question?  As far as I can tell,
it's draft-ietf-ecrit-ecall-11.  Why do the example INFO requests in
that draft not have Info-Package headers, even though those are central
to the interpretation of an info package INFO request?

As I understand it:

RFC 6086 allows an Info Package INFO request to contain the info package
data as either the entire message body, or as one part of a multipart
body.  Which one applies is determined by the placement of a
"Content-Disposition: Info-Package" header, either in the message
headers or the headers of one part of the multipart body.  The info
package part may itself be a multipart type.

Any additional body parts of the multipart case SHOULD NOT be data that
is intrinsically associated with the data of the info package.  The
words "not specifically associated with the INFO method and the
application concerned" aren't quite what one means, since the data is
*always* associated with "the application concerned" in some way.  The
critical thing is that the data is not specifically associated with the
particular info package of this INFO request.

In ecrit communications, the callee can send an INFO info package
request which requests the caller and the transit networks to resend the
RFC 7852 Additional Data.  That stimulates the caller to send an INFO
request for an info package (seemingly) called "ACK".  The ACK info
package acknowledges that the caller has processed the Additional Data
refresh request.  Also, the caller attaches to the INFO request its
current Additional Data.  And the transit networks attach to the INFO
request their current Additional Data.

The question is, How is the updated Additional Data to be attached to
the INFO request?  One choice is that it is attached as described in RFC
7852, in the same way that it is attached to the INVITE request, as
additional body parts pointed to by Call-Info headers.  The other choice
is that it is incorporated into the ACK info package.

An additional question:  It is clear how the caller detects that it must
resend its Additional Data.  But how do the transit networks detect that
they must resend their Additional Data?  Must they scan all transiting
INFO requests for use of the ACK info package?  I suppose that only
requests to urn:service:sos:* URIs need be scanned.

The advantage of attaching the Additional Data in the RFC 7852 manner is
that the mechanism is already defined, and its implementation is already
required.

The advantage of attaching the Additional Data as part of the ACK info
package is that it conforms to RFC 6086, since the Additional Data is
specifically intended to be attached to that INFO request, not just some
caller's request chosen at random within the dialog.

Note:  Suppose we define the ACK info package to *only* acknowledge
receiving and processing the request for resend, but allow the caller to
attach the Additional Data to any request it chooses.  E.g., the caller
could send an UPDATE carrying the Additional Data followed by an INFO
informing the callee that it had resent the data.  Then the Additional
Data would not be *part of* the ACK info package data and the RFC 7852
method would not contravene RFC 6086 -- even if the caller *just
happened* to always attach the Additional Data to the INFO for the ACK
package.

Or we could do it *both ways* at the *same time*...

Here is an example INFO requesting resending the ecrit data, taken from
draft-ietf-ecrit-ecall-11.  I've added "Info-Package:
emergencyCallData.eCall.MSD".

      INFO sip:[email-masked] SIP/2.0
      To: <sip:[email-masked]>;tag=9fxced76sl
      From: Exemplar PSAP <urn:service:sos.ecall.automatic>
      Call-ID: [email-masked]
      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.control;
      Accept: application/sdp, application/pidf+xml,
              application/emergencyCallData.eCall.control+xml,
              application/emergencyCallData.eCall.MSD+per
      CSeq: 41862 INFO
      Info-Package: emergencyCallData.eCall.MSD
      Recv-Info: emergencyCallData.eCall.MSD
      Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
             SUBSCRIBE, NOTIFY, UPDATE
      Content-Type: application/EmergencyCallData.eCall.control+xml
      Content-ID: [email-masked]
      Content-Disposition: info-package

      <?xml version="1.0" encoding="UTF-8"?>
      <EmergencyCallData.eCall.Control
          xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation=
              "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">

      <request action="send-data" datatype="eCall.MSD"/>

      </EmergencyCallData.eCall.Control>

Here is the response INFO request that I propose, made by inserting the
Additional Data from an example in RFC 7852 to the response INFO request
in the draft:

      INFO urn:service:sos.ecall.automatic SIP/2.0
      To: urn:service:sos.ecall.automatic
      From: <sip:[email-masked]>;tag=9fxced76sl
      Call-ID: [email-masked]
      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.MSD;
      Call-Info: <http://wwww.example.com/hannes/photo.jpg>
                     ;purpose=icon,
        <http://www.example.com/hannes/> ;purpose=info,
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.ProviderInfo,
        <cid:[email-masked]>
            ;purpose=EmergencyCallData.DeviceInfo
      Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
      Geolocation-Routing: yes
      Accept: application/sdp, application/pidf+xml,
              application/emergencyCallData.eCall.control+xml
      CSeq: 51862 INFO
      Info-Package: emergencyCallData.eCall.MSD
      Recv-Info: emergencyCallData.eCall.MSD
      Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
             SUBSCRIBE, NOTIFY, UPDATE
      Content-Disposition: info-package
      Content-Transfer-Encoding: binary
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...

      --boundary1
      Content-Type: application/emergencyCallData.eCall.MSD+per
      Content-ID: [email-masked]

           ...MSD in ASN.1 PER encoding goes here...

      --boundary1
      Content-Type: application/EmergencyCallData.DeviceInfo+xml
      Content-ID: <[email-masked]>
      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>
      <dev:EmergencyCallData.DeviceInfo
           xmlns:dev=
           "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
          ...
      </dev:EmergencyCallData.DeviceInfo>

      --boundary1
      Content-Type: application/EmergencyCallData.ProviderInfo+xml
      Content-ID: <[email-masked]>
      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>
      <pi:EmergencyCallData.ProviderInfo
         xmlns:pi=
            "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
          ...
      </pi:EmergencyCallData.ProviderInfo>
      --boundary1--

The point here is that the emergencyCallData.eCall.MSD info package is
defined to allow a multipart body and the body of this request is one
such.  One part of the body is the
application/emergencyCallData.eCall.MSD+per, which presumably carries
the ACK semantics, and zero or more parts are
application/EmergencyCallData.ProviderInfo+xml, which carry the
Additional Data.  This structure conforms to RFC 6086.  (The Call-Info
headers that point to external resources are OK because they do not
involve additional body parts.)

The application/EmergencyCallData.ProviderInfo+xml parts are pointed to
by Call-Info headers, conforming to RFC 7852.

Note that the logic that inserts a
application/EmergencyCallData.ProviderInfo+xml part into the multipart
body which is the emergencyCallData.eCall.MSD info package is the same
as the logic which inserts such a part into an ecrit INVITE.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Aug 2016 06:56:26 +0000

Hi,

>> Or, to put it in another way: Assuming I want to send content X using
>>INFO. How do I determine whether I need to define an Info Package for
>>that, or whether I can send it in INFO without defining an Info Package?
>

We can assume that.

>even applies to this question.

Good - at least we agree on that :)

>go, which happens to include INFO.

You seem to claim that, since you can carry content X in INVITE using
Call-Info (or whatever mechanism) you can also carry content X in INFO
using the same mechanism.

I think that’s where we have different opinions, because I claim that,
when you carry content X in INFO, you have to use an Info Package - even
if you carry content X in INVITE using Call-Info.

Regards,

Christer

>>>> Paul, a generic question, which might help me understand your view on
>>>>ecall: in your opinion, when (if ever) is usage of an Info Package
>>>>required?
>>>
>>> If you have a need to transmit some information via a sip session,
>>>then you should consider all the available mechanisms sip has, and
>>>decide if there is some combination of existing mechanisms that meets
>>>your need.
>>>
>>>usage are appropriate. Others do not, and are probably deficient
>>>because of that. For those, the bar is generally the need to get a RFC
>>>approved.
>>>
>>> When choosing among the options, you have to consider what the
>>>approval processes will be for each, and that the reviewers will
>>>probably ask if you have considered alternative approaches.
>>>
>>> For instance Geolocation was done with a new header field that
>>>sometimes references a separate body part. That raised a higher hurdle
>>>to get over than using an info package. But it was deemed worth it
>>>since it had needs that couldn't be met by info packages.
>>>
>>> In general there are likely to be multiple options available for
>>>almost anything you want to do. And then it will come down to weighing
>>>the pros/cons.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>> Yes, I’m saying that the ACK satisfies the 6086 use of INFO, and
>>>>>that it’s okay to send the data with Call-Info.
>>>>>
>>>> I think the main point of bringing this to sipcore is to get some
>>>>fresh input into this discussion. Since I have been party to the
>>>>discussion over in ecrit I don't bring anything fresh here. But for
>>>>completeness I will register my opinion here too.
>>>>
>>>> *is* valid.) Rather this is simply a question of what is the best
>>>>design for the desired functionality. As such I don't think it really
>>>>needs to be settled in sipcore.
>>>>
>>>>>>>>> is telematics data in a vehicle.   The vehicle can report things
>>>>>>>>>like
>>>>>>>>> the
>>>>>>>>> Disposition as it would in an INVITE.   When the updated data is
>>>>>>>>>sent
>>>>>>>>> in

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Aug 2016 07:38:28 +0000

Hi,

Š

>happened* to always attach the Additional Data to the INFO for the ACK

UPDATE is meant to update information associated with the SIP session, not
to transport application data.

Nobody in ECRIT has afaik objected to the usage of INFO as such.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2016 12:09:18 -0400

On 8/26/16 2:56 AM, Christer Holmberg wrote:
[snip]
> if you carry content X in INVITE using Call-Info.

Yes, that is the exact question that we have come to sipcore to ask. And 
you have stated my position accurately.

And lets step back a bit from call-info. I assert the same is true for 
something else. E.g., if I for some reason had need to send a 
Geolocation header field with a cid url. IMO it is exactly the same 
situation as call-info.

(This is hypothetical. I don't have a particular case in mind where I 
might want to send a Geolocation and an INFO at the same time.)

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 26 Aug 2016 16:40:45 -0400

Christer Holmberg <[email-masked]> writes:
> I am asking: assuming you have determined (based on whatever criteria)
> that the INFO message is the most appropriate mechanism, when are you
> required to use Info Package?

If you have decided to use an INFO request, then the INFO request uses
an Info Package when (and only when) an Info-Package header is present
in the request.  That's a basic rule of RFC 6086.  There doesn't seem to
be any normative prescription of when you are required to use Info
Package within INFO, but it seems like a good idea to use an Info
Package for any newly designed uses of INFO.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 26 Aug 2016 16:44:10 -0400

RFC 6086 section 4.2.1 says:

   The INFO request MUST NOT contain a Recv-Info header field.  A UA can
   only indicate a set of Info Packages for which it is willing to
   receive INFO requests by using the SIP methods (and their responses)
   listed in Section 5.

But draft-ietf-ecrit-ecall-11 has two places in section 11 where example
INFO requests contain a Recv-Info header:

Dale

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Aug 2016 16:44:37 -0400

Christer seems to think that if we send a body part in an INFO message that isn’t defined in an INFO package, that it constitutes a pre-6086 INFO use, which is not allowed.  Here, we’re using Call-Info to point to, and label the body part, recognizing that there is another body part that IS part of the INFO package in the message.

The fact that the Call-Info body part is in the INFO message doesn’t make it a pre-6086 use of INFO.  It’s just introduced by Call-Info rather than INFO.

Brian

> On Aug 26, 2016, at 4:40 PM, Dale R. Worley <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Aug 2016 21:06:02 +0000

Hi,

>Christer seems to think that if we send a body part in an INFO message that isn’t defined in an INFO package, that it constitutes a pre-6086 INFO use, which is not allowed.  >Here, we’re using Call-Info to point to, and label the body part, recognizing that there is another body part that IS part of the INFO package in the message.
>

I am saying that:

1) the data you send is associated with the ecall application; and
2) that the data is NOT associated with a pre-6086 use of INFO - it is a new INFO usage

...and therefore you have to use an Info Package.

Regards,

Christer

>> I am asking: assuming you have determined (based on whatever 
>> criteria) that the INFO message is the most appropriate mechanism, 
>> when are you required to use Info Package?
> 
> in the request.  That's a basic rule of RFC 6086.  There doesn't seem 
> to be any normative prescription of when you are required to use Info

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2016 17:30:40 -0400

> ...and therefore you have to use an Info Package.

And I"m saying:

- if you have an application that can get information using a variety
   of sip mechanisms (e.g., from call-info in an invite, and from an
   info package body)
- then more than one mechanism is applicable to a single message
   (e.g. a call-info in an INFO) then you can use whatever combination
   makes sense.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Aug 2016 06:28:16 +0000

Hi,

>>>Christer seems to think that if we send a body part in an INFO message
>>>that isn¹t defined in an INFO package, that it constitutes a pre-6086
>>>INFO use, which is not allowed.  >Here, we¹re using Call-Info to point
>>>to, and label the body part, recognizing that there is another body
>>>part that IS part of the INFO package in the message.
>>>
>>> The fact that the Call-Info body part is in the INFO message doesn¹t
>>>make it a pre-6086 use of INFO.  It¹s just introduced by Call-Info
>>>rather than INFO.
>>
>> I am saying that:
>>

So, by claiming that content X can also be sent in a non-INFO request you
don¹t have to define an Info Package?

Which also means that the usage will not be registered in the info package
registry (and probably not in any other registry either), which means that
others can define a slightly different usage of INFO for delivering
exactly the same content, with the same semantics - again, one of the
things we wanted to prevent with RFC 6086 and the info package registryŠ

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 30 Aug 2016 13:27:20 +0000

I think we have had this discussion in the past.

The impact of doing this is that one will perform all the other functions associated with the reINVITE or the UPDATE, including a full SDP renegotiation. That is unnecessary and not the optimum use of resources when one is trying to perform an emergency call. Further, if the SDP renegotiation fails, the reINVITE or UPDATE has to be rejected with a 4xx. In that case, what is the status of the data transfer?

Regards

Keith

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 25 August 2016 22:01
To: Drage, Keith (Nokia - GB); Randall Gellens; [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

This is mostly getting outside the scope of sipcore. But maybe this one part is in scope...

On 8/25/16 2:10 PM, Drage, Keith (Nokia - GB) wrote:

> The you cannot use additional-data because that does not allow 
> messages to be sent purely on the need of the data,

I disagree.

Consider for a moment session timer. In principle all it needs to do is signal *something* from end to end through all the session signaling intermediaries. It doesn't really need the function of any particular message. But to do so it triggers the sending of INVITE or UPDATE. Note in particular that the UPDATE can be effectively a no-op aside from its session-timer updating. (It need not carry an offer, though it MAY.) And the resulting message does its job without any of the recipients knowing if it was sent solely because it was needed for session timer, or if it was going anyway but serves also to refresh the session timer.

The same can be true for additional-data (or any usage of call-info). 
The additional-data transport can be piggybacked on a message that is already being sent for some other purpose, or some benign message can be sent specifically to serve as the vehicle for the additional-data. It could be INVITE or UPDATE. Or it could be INFO if you have some info package that you want to send at that time, or it could be the response to an INFO package if you happen to need to respond to one at the same time that you need to send the additional-data.

In the case where you have just received an INFO containing an indication that fresh additional-data would be appreciated, it may be really convenient to piggyback the additional-data on the response to that INFO. I see no problem with that.

Note that some other implementation might not find it convenient to piggyback that way. (Maybe it takes awhile to generate the fresh data and it doesn't want to delay the response.) Then that implementation may need to find some other message to carry the additional-data.

What *would* violate the spirit of sip would be something similar that sends high volume and frequent data over the signaling channel.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 30 Aug 2016 13:27:21 +0000

I think you are looking at the wrong way round.

You need to look at the requirements of the application.

If it needs to come in a call control message, then it uses the existing location-conveyance RFC.

If you need it outside, and you need it in something outside a call control message, then you need to follow the rules for the selected data transfer mechanisms you have chosen. If you have chosen INFO, and an Info package specifically for this purpose, then the Geolocation header field becomes irrelevant. If I is another Info package for another purpose, then you are effectively piggybacking Geolocation on top of it. In my view you cannot try and combine procedures from two different data transfer mechanisms and end up with a sensible result.

Keith

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 25 August 2016 20:05
To: Drage, Keith (Nokia - GB)
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

Brian

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 30 Aug 2016 13:27:24 +0000

And as I have asserted, as the contents of the Info package data is defined by the Info-Package header, the usage of the Call-Info header field is irrelevant, and potentially misleading.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 26 August 2016 21:45
To: Dale R. Worley
Cc: [email-masked]
Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

Brian

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Aug 2016 09:58:04 -0400

"Drage, Keith (Nokia - GB)" <[email-masked]> writes:
> The impact of doing this is that one will perform all the other
> functions associated with the reINVITE or the UPDATE, including a full
> SDP renegotiation. That is unnecessary and not the optimum use of
> resources when one is trying to perform an emergency call. [...]

You can do an UPDATE without an offer, and in that case, it's nearly a
no-op, it doesn't do an SDP renegotiation.  As Paul said, "Note in
particular that the UPDATE can be effectively a no-op aside from its
session-timer updating. (It need not carry an offer, though it MAY.)"

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Aug 2016 10:06:37 -0400

> session-timer updating. (It need not carry an offer, though it MAY.)"

Also, we are here only discussing the *validity* of doing these things.

Weighing the *merits* of one mechanism vs. another is a separate issue, 
but I prefer to have that debate only consider alternatives that are 
valid. And that debate can happen in ecrit rather than sipcore.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Aug 2016 12:41:00 -0400

> don¹t have to define an Info Package?

I don't need to do so if I don't use INFO.

> things we wanted to prevent with RFC 6086 and the info package registryŠ

I'm not sure I understand what you are saying here.

I *think* you are talking about a case where I'm piggybacking on a 
*legacy* INFO. Is that what you mean?

I thought we agreed to take that off the table.

Legacy INFO can only be used for legacy cases. This clearly isn't a 
legacy case.

I guess, in theory, you might have need to use a legacy INFO for one of 
the legacy purposes for which it is already valid. And you might also 
have a need to send something like a call-info with a body. In that case 
I suppose you *might* consider piggybacking it on that INFO. It is a 
hazy case, because the usage of legacy INFO is so ill-defined. My guess 
is that it wouldn't work. But this is different from using a legacy info 
*solely* as a carrier for a call-info body. That seems to be entirely 
invalid.

	Thanks,
	Paul