Subject: [Ecrit] Reaching consensus on ecall

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 10:31:40 -0400

The discussion on ecall has become quite heated, with people dug in on 
all sides. Can we calm it down a bit?

IMO a couple of different approaches have been described that would work 
and not violate any specs. The differences between these reflect 
differences of philosophy and taste.

Perhaps others don't agree with me on this. But can we separate these 
concerns?

- narrow down the number of alternatives,
- reach agreement that each is workable and standards compliant,
- *then* debate the philosophical and taste issues.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 14:43:07 +0000

Hi Paul,

>differences of philosophy and taste.

I don¹t think we have an agreement on the would-not-violate-any-specs
part. We clearly have different views on what is allowed by RFC 6086.

But, I do agree we need to try to figure out how to move forward.

Regards,

Christer

>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 11:00:06 -0400

> But, I do agree we need to try to figure out how to move forward.

OK. Maybe we should start there.

I guess there is some dispute on whether it is valid for an INFO message 
to contain a multipart body, where one part contains the info package 
(C-D: info-package) and another part (C-D: by-reference) is referenced 
by a cid: uri in some sip header field.

In my mind there is no question that this is valid. Do you disagree, and 
if so, on what basis?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 15:22:16 +0000

Hi,

>In my mind there is no question that this is valid. Do you disagree, and

The dispute is whether a message body must be associated with an Info
Package.

In my view: 

- RFC 6086 allows bodies not associated with an Info Package in INFOs in
order to be backward compatible with existing pre-6086 INFO usages.
- Any NEW usage MUST be associated with an Info Package. Sending of MSD is
a new INFO usage.

Some have said that there might even be new usages where information,
without being associated with an Info Package, is piggybacked in INFOs
sent for some other purpose. It can be discussed whether such usage is
6068 compliant, but never the less: in my opinion MSD is not “piggybacked
information". The reason the INFO is sent to begin with is to transport
the requested MSD (and the ack to the request) - that is not piggybacking
in my opinion.

Now, in the current version of the draft, the MSD was still associated
with an Info Package, and the dispute was mostly regarding usage of
Call-Info. But, based on the suggestion presented a few days ago, the MSD
is no longer even associated with an Info Package, so unfortuantely I
think out views are even more different now than before.

My apologies if that was more text than you hoped for, but I just want to
try to make my view of the situation as clear as possible :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 11:42:12 -0400

Christer,

> - Any NEW usage MUST be associated with an Info Package. Sending of MSD is

I disagree. I find the following in 6086:

       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.

A body part referenced by call-info falls into that category.

> the requested MSD (and the ack to the request) - that is not piggybacking

That may be your concept of how the particular info package is defined. 
I think the people who disagree have a different concept. For purposes 
of evaluation these should be considered alternative proposals.

> think out views are even more different now than before.

Exactly.

> try to make my view of the situation as clear as possible :)

As long as we are making progress towards understanding each other.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Fri, 19 Aug 2016 11:47:22 -0400

Suppose we wanted to create an INFO package that would trigger an update of the caller’s location mid call.

Caller Location is carried in the Geolocation header, and can either be a URI to a location dereferenced using HELD or SIP Presence, or it can be a content indirect with a body.

Would you say we would have to send the location, if sent by reference, in an INFO block?  What if it was sent by value?

Brian
> On Aug 19, 2016, at 11:42 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Christer,
> 
> That may be your concept of how the particular info package is defined. I think the people who disagree have a different concept. For purposes of evaluation these should be considered alternative proposals.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 12:33:29 -0400

On 8/19/16 11:47 AM, Brian Rosen wrote:
> Caller Location is carried in the Geolocation header, and can either be
> a URI to a location dereferenced using HELD or SIP Presence, or it can
> be a content indirect with a body.
>
> Would you say we would have to send the location, if sent by reference,
> in an INFO block?  What if it was sent by value?

Did you intentionally send the same query twice, once to me and once to 
Christer?

IMO, with this approach, clearly geoloc header would be used with a 
location in an external server, and for consistency should also be used 
with a cid uri.

What message that goes in is a question. I assert it can go in any 
convenient message that permits it. The most immediately available one 
that would work is the response to the INFO. I *do* think this is an 
allowable usage, even though an info-package body is not permitted in 
the response to an INFO.

But it could also go in a subsequent INVITE or UPDATE, or INFO. It is a 
little dicey whether it should be kosher to send a "no-op" info package 
as a vehicle to piggyback a geoloc with body.

	Thanks,
	Paul

> Brian
>> On Aug 19, 2016, at 11:42 AM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Christer,
>>
>> That may be your concept of how the particular info package is
>> defined. I think the people who disagree have a different concept. For
>> purposes of evaluation these should be considered alternative proposals.
>>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 19 Aug 2016 11:46:08 -0700

Hi Christer,

At 3:22 PM +0000 8/19/16, Christer Holmberg wrote:

>>>  I don©–t think we have an agreement on the would-not-violate-any-specs

My reading of RFC 6086 does not support your view.  Specifically:

And also:

    A UA MAY include a message body that is not associated with an Info
    Package in an INFO response.

--Randy

>  6068 compliant, but never the less: in my opinion MSD is not "piggybacked

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures.    --'Ceaser Smith' in _Hot_Millions_

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 20:10:18 +0000

Hi,

> Caller Location is carried in the Geolocation header, and can either be a URI to a location dereferenced using 
> HELD or SIP Presence, or it can be a content indirect with a body.
>

I am not sure I understand the question. What do you mean by "INFO block"?

Regards,

Christer

> On Aug 19, 2016, at 11:22 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>>>> The discussion on ecall has become quite heated, with people dug in 
>>>> on all sides. Can we calm it down a bit?
>>>> 
>>>> IMO a couple of different approaches have been described that would 
>>>> work and not violate any specs. The differences between these 
>>>> reflect differences of philosophy and taste.
>>> 
>>> I don¹t think we have an agreement on the 
>>> would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086.
>>> 
>> I guess there is some dispute on whether it is valid for an INFO 
>> message to contain a multipart body, where one part contains the info 
>> package
>> (C-D: info-package) and another part (C-D: by-reference) is 
>> referenced by a cid: uri in some sip header field.
>> 
>> In my mind there is no question that this is valid. Do you disagree, 
>> and if so, on what basis?
> 
> - RFC 6086 allows bodies not associated with an Info Package in INFOs 
> in order to be backward compatible with existing pre-6086 INFO usages.
> - Any NEW usage MUST be associated with an Info Package. Sending of 
> MSD is a new INFO usage.
> 
> 6068 compliant, but never the less: in my opinion MSD is not 
> “piggybacked information". The reason the INFO is sent to begin with 
> is to transport the requested MSD (and the ack to the request) - that 
> is not piggybacking in my opinion.
> 
> Call-Info. But, based on the suggestion presented a few days ago, the 
> MSD is no longer even associated with an Info Package, so 
> unfortuantely I think out views are even more different now than before.
> 
> My apologies if that was more text than you hoped for, but I just want 
> to try to make my view of the situation as clear as possible :)
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>>>> Perhaps others don't agree with me on this. But can we separate 
>>>> these concerns?
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 16:15:51 -0400

> I am not sure I understand the question. What do you mean by "INFO block"?

Sorry. S/INFO block/INFO message/

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 20:55:17 +0000

Hi,

>       not specifically associated with the INFO method and the

So, you are saying that the MSD is not associated with the ecall application???

RFC 6086 also says:

	"Any new usage MUST use the Info Package mechanism defined in this
       	specification, since it does not share the issues associated with
       	legacy INFO usage, and since Info Packages can be registered with
       	IANA."

And, in my opinion, sending of MSD *is* part of the new INFO usage. It's not something else that we add to the INFO.

Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just by saying the content is not associated with the application...

>> "piggybacked information". The reason the INFO is sent to begin with 
> I think the people who disagree have a different concept. For purposes of evaluation these should be considered alternative proposals.

Well, I have always assumed that we agreed that one of the main reason we send the INFO is to transport the MSD...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 21:00:14 +0000

Hi,

...

>       not specifically associated with the INFO method and the

MSD is not associated with the application concerned?

MSD is not associated with the INFO method, even though the main reason we send the INFO in order to deliver the MSD?

And also:

   "A UA MUST NOT include a message body associated with an Info Package
   in an INFO response.  Message bodies associated with Info Packages
   MUST only be sent in INFO requests."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 18:19:02 -0400

> Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just by saying the content is…

We did 6086 so that the usage if INFO to carry associated body parts 
could be negotiated.

IMO if something is in the message, but not in the info-package body 
part, then it isn't specifically part of the INFO usage. For instance, 
any random header field that you happen to include isn't.

> Well, I have always assumed that we agreed that one of the main reason we send the INFO is to transport the MSD...

Remember that *that* was in response to earlier proposals that didn't 
use INFO. And some people are having trouble with the way it ended up. 
So it isn't cast in stone.

Brian's proposal that it be a request/response protocol that can trigger 
what would otherwise be an unsolicited MSD update is a plausible 
alternative.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Aug 2016 22:36:42 +0000

Hi,

>>>>>>> The discussion on ecall has become quite heated, with people dug 
>>>>>>> in on all sides. Can we calm it down a bit?
>>>>>>>
>>>>>>> IMO a couple of different approaches have been described that 
>>>>>>> would work and not violate any specs. The differences between 
>>>>>>> these reflect differences of philosophy and taste.
>>>>>>
>>>>> message to contain a multipart body, where one part contains the 
>>>>> info package
>>>>> In my mind there is no question that this is valid. Do you 
>>>>> disagree, and if so, on what basis?
>>>>
>>>> The dispute is whether a message body must be associated with an 
>>>> Info Package.
>>>>
>>>> In my view:
>>>>
>>>> - RFC 6086 allows bodies not associated with an Info Package in 
>>>> INFOs in order to be backward compatible with existing pre-6086 INFO usages.
>> Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just >> by saying the content is not associated with the application...
>
> We did 6086 so that the usage if INFO to carry associated body parts could be negotiated.

You don't need 6086 to indicate what body parts you support. There is a SIP header field for that.

We defined 6086 so that you could define and indicate the semantics associated with the INFO request (including body parts), and to negotiate support of processing that semantics.

>IMO if something is in the message, but not in the info-package body part, then it isn't specifically part 
>of the INFO usage. For instance, any random header field that you happen to include isn't.

MSD is not "something random that you happen to include" in an INFO associated with the ecall application.

Or, again, are you saying that MSD is not associated with the ecall application?

>>>> Some have said that there might even be new usages where 
>>>> information, without being associated with an Info Package, is 
>>>> piggybacked in INFOs sent for some other purpose. It can be 
>>>> discussed whether such usage is
>>>> is to transport the requested MSD (and the ack to the request) - 
>>>> that is not piggybacking in my opinion.
>>>
> Remember that *that* was in response to earlier proposals that didn't use INFO. And some people are having trouble with the way it ended up. 
> Brian's proposal that it be a request/response protocol that can trigger what would otherwise be an unsolicited MSD update is a plausible alternative.

My proposal is to send the MSD as part of an Info Package.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Aug 2016 18:53:01 -0400

> Or, again, are you saying that MSD is not associated with the ecall application?

I"m saying that I don't know anything about an ecall *application*. I 
agree there might be one, but we aren't defining that. I do know the MSD 
is associated with a call-info header field. I can potentially put that 
call-info in any message I like (that permits call-info).

If there happens to be an ecall application, then the MSD might indeed 
end up at that application. I would expect that the application will be 
*loosely* coupled to the sip session. Lots of other things may happen in 
that session that may or may not be anticipated by the application. 
Those things may be processed by other UA application software. So the 
ecall application is just one *user* of the sip session.

Of course the application environment may constrain the possibilities in 
some way. But I think that is outside of our scope here.

	Thanks,
	Paul

---

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

"if there is an ecall application"

We are defining a mechanism to be used by the ecall service, application or whatever you want to call it. If you indicate support for the ecall info package, it means you support the application logic associated with that. If you want to send MSD outside the ecall application, fine, but we are defining ecall.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎20/‎08/‎2016 01:53
To: Christer Holmberg<mailto:[email-masked]>; ECRIT<mailto:[email-masked]>
Subject: Re: Multipart with INFO

        Thanks,
        Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 22 Aug 2016 22:05:08 +0000

I'm afraid I see somewhat muddled thinking here, and I am sure it is not mine.

We have already agreed for the use case of ecall, that the transfer of data outside of a call control message using INFO requires the creation of an Info package.

Following that use case, and using exactly the same argument, then any other use case requiring to use INFO to transfer data would create another Info package for the transfer of that data.

While theoretically, an argument might apply that it is valid to use additional data in an INFO message, I cannot conceive of a use case where only there in addition to the ecall Info package, and never required at any other time. If it is required at any other time, then the separate Info package must exist, and therefore if it exists, it should be used for all the transfers outside of call control messages. Conversely, if it is only there when ecall transfer exists, and never outside it, I wonder why it is not part of the ecall Info package.

The only exception I can see to this is where some other preexisting linking mechanism exists, such as Geolocation, but even this in my mind causes issues.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 19 August 2016 23:53
To: Christer Holmberg; ECRIT
Subject: Re: [Ecrit] Multipart with INFO

On 8/19/16 6:36 PM, Christer Holmberg wrote:
> Hi,
>
>>>>>>>> The discussion on ecall has become quite heated, with people 
>>>>>>>> dug in on all sides. Can we calm it down a bit?
>>>>>>>>
>>>>> - Any NEW usage MUST be associated with an Info Package. Sending 
>>>>> of MSD is a new INFO usage.
>>>>
>> part, then it isn't specifically part of the INFO usage. For instance, any random header field that you happen to include isn't.
>

I"m saying that I don't know anything about an ecall *application*. I agree there might be one, but we aren't defining that. I do know the MSD is associated with a call-info header field. I can potentially put that call-info in any message I like (that permits call-info).

If there happens to be an ecall application, then the MSD might indeed end up at that application. I would expect that the application will be
*loosely* coupled to the sip session. Lots of other things may happen in that session that may or may not be anticipated by the application. 
Those things may be processed by other UA application software. So the ecall application is just one *user* of the sip session.

Of course the application environment may constrain the possibilities in some way. But I think that is outside of our scope here.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2016 18:27:50 -0400

> We have already agreed for the use case of ecall, that the transfer of data outside of a call control message using INFO requires the creation of an Info package.

Since ecall isn't yet done, presumably anything is potentially subject 
to revision.

But I don't think that is being proposed.

> While theoretically, an argument might apply that it is valid to use additional data in an INFO message, I cannot conceive of a use case where only there in addition to the ecall Info package, and…

I can't parse that statement.

IMO what we have is a suggestion that there be an info package that says 
"I'd like to have you send me a fresh copy of X", where there is already 
an independently defined mechanism for sending X, independent of this 
info package.

For MSD that mechanism is additional-info, and it happens that it is 
valid for the MSD to piggyback on an INFO response.

For something other than MSD it remains to be seen how it might be 
conveyed. We don't yet have any examples. It is *conceivable* that 
something else might be defined to use additional-info. Or it might be 
defined to use another info-package.

> The only exception I can see to this is where some other preexisting linking mechanism exists, such as Geolocation, but even this in my mind causes issues.

I don't think we need to decide this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 06:03:50 +0000

Hi Paul,

>> We have already agreed for the use case of ecall, that the transfer of
>>data outside of a call control message using INFO requires the creation
>>of an Info package.
>

The new suggestion was presented as a ³compromise proposal². As we haven¹t
reached an agreement on that, I think we should step back to where we were
and try to figure out another way of solving the issue.

Š

>valid for the MSD to piggyback on an INFO response.

My opinion is still:

- the INFO is associated with ecall (i.e. the INFO is sent to request,
acknowledge or provide information associated with the ecall)
- the MSD is association with ecall (if we can¹t even agree on that I
think we need to ask for guidance outside IETF).

Therefore the MSD has to be associated with an info package, per 6086.

In my opinion, the MSD is not ³piggybacked random information not related
to ecall², and if we allow it to be sent outside an info package we
basically open the door for people to use INFO for *ANYTHING* without
registering an Info Package. That¹s exactly what we wanted to prevent with
6086, and as far as I remember you were heavily involved in that work, and
in the years of painful to-info-or-not-to-info discussions that took place
prior to that, so I¹m really surprised that you suggest something like
that. But, you are of course entitled to your opinion :)

Regards,

Christer

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 23 Aug 2016 06:47:02 +0000

Hello Paul,

> For MSD that mechanism is additional-info, and it happens that it is valid for the MSD to piggyback on an INFO response.

Stating that MSD is NOT associated with the emergencyCallData.eCall.__MSD__ info package (an info package defined in a draft with sole purpose to get MSD from IVS) is very weird.

Kind regards

Ivo

---

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

Just to be clear, I do not agree with the supposed "compromise proposal either (I just have not got to that thread yet). I do not see any element of compromise at all.

I essentially support Christer in what he is saying below.

I expressed my position, and it is unchanged, in the following text (taken from the previous mail), which I believe Paul also agreed with (and I think aligns with Christer and Ivo):

"I see some sort of supporting ecrit "application" in the PSAP and the calling UA. That supporting application initiates two independent data transport mechanisms within SIP, using RFC 7852 for the initial MSD and the data response to indicate support of MSD reception, and using RFC 6086 for any subsequent MSD. SIP itself knows nothing about the relationship between these two mechanisms, only the ecrit "application". It is the ecrit "application" that performs the combination of the data received using the two data transfer mechanisms as appropriate.

The MSDs transferred using the two mechanisms following identical syntax and coding, but that is merely a matter of convenient definition.

As such, use of Call-Info in INFO would be entirely inappropriate, because INFO does not transfer additional-data according to RFC 7852.

Note that RFC 7842 is only used by ecrit in the initial INVITE transaction, and appearance in subsequent messages of any form would not be expected by the recipient PSAP."

As such, I see no crossover with additional data at the SIP level, and because we have decided to use an Info package to carry data outside circuit switched messages, I believe the decision on any other data would follow the same route. As such I believe the use cases for additional data in INFO are limited, and not something we should be worrying about tat the moment.

Regards

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 23 August 2016 07:04
To: Paul Kyzivat; Drage, Keith (Nokia - GB); ECRIT
Subject: Re: [Ecrit] Multipart with INFO

Hi Paul,

>> We have already agreed for the use case of ecall, that the transfer 
>>of data outside of a call control message using INFO requires the 
>>creation of an Info package.
>

The new suggestion was presented as a ³compromise proposal². As we haven¹t reached an agreement on that, I think we should step back to where we were and try to figure out another way of solving the issue.

Š

>IMO what we have is a suggestion that there be an info package that 
>says "I'd like to have you send me a fresh copy of X", where there is 
>already an independently defined mechanism for sending X, independent 
>of this info package.
>

My opinion is still:

- the INFO is associated with ecall (i.e. the INFO is sent to request, acknowledge or provide information associated with the ecall)
- the MSD is association with ecall (if we can¹t even agree on that I think we need to ask for guidance outside IETF).

In my opinion, the MSD is not ³piggybacked random information not related to ecall², and if we allow it to be sent outside an info package we basically open the door for people to use INFO for *ANYTHING* without registering an Info Package. That¹s exactly what we wanted to prevent with 6086, and as far as I remember you were heavily involved in that work, and in the years of painful to-info-or-not-to-info discussions that took place prior to that, so I¹m really surprised that you suggest something like that. But, you are of course entitled to your opinion :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Aug 2016 11:15:58 -0400

Just to be clear: I don't have an axe to grind here. I see multiple 
possible solutions that seem reasonable to me. I think they have been 
suggested by others along the way. OTOH, I see some proposals that I 
consider *wrong*.

I think there is more disagreement about the rationale for particular 
solutions than for the specific mechanisms.

I think I will just stay quiet for awhile, until you with skin in the 
game have a concrete (-12) revised proposal.

	Thanks,
	Paul

---

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

Hi,

>The notion authors have proposed is that we create a command channel for mid call communications between devices and PSAPs using INFO.  That requires an INFO >package.  We can, however, make one INFO package that defines this protocol and use it for multiple instances of devices communicating with PSAPs, at least those that >have a simple request update command.

Correct.

>We started this entire set of documents to manage sending of data from devices to PSAPs.  eCall is one example, an alarm is another.   In most cases, the initial data >accompanies the INVITE.
>If there is an update, the device can decide to send it.  It is also possible that the PSAP can request it.   Different devices have different data.

Correct.

>No one has argued that the data sent with the INVITE is carried as Additional Data, requiring a schema and a token registered with IANA.

Correct. The agreement has been to use the mechanism defined in Additional Data for transporting the data in INVITE. 

> We’re arguing that the character of the data doesn’t change and the schema of the data doesn’t change when you send
> it mid call, and it doesn’t matter what message you attach it to, it’s Additional Data.  What we need INFO for is the 
> request/response command channel.   You send an INFO with a request using an INFO package conforming to 6086. 
> You may get a response to the request (in another INFO). That’s the INFO transaction and it satisfies all the requirements
> of 6086.  6086 isn’t a straightjacket.  I’m happy to go get sippcore to tell us the obvious: we can send a Call-Info with a 
> CID and a body, no matter what the relationship between the INFO and the Call-Info are.  Do you want me to ask for that?  

First, I'm happy to take this to SIPCORE (I already suggested that earlier).

However, simply asking "Can we send a Call-Info with a CID and a body" isn't very useful.

The question is whether the INFO request itself, and the MSD content transported in the INFO request, are associated with the same "application" (ecall), and whether the MSD therefore must be sent using an Info Package, as stated in 6086. 

> We want the MSD outside the INFO package because it’s Additional Data and should be carried with a Call-Info pointing 
> to the MIME type and schema registered for Additional Data, just like in the INVITE.  
>
> We want the INFO package for its command (send the MSD) and response (ACK).  That can only happen mid-call, so INFO is
> appropriate.  It’s a well defined INFO package, and it satisfies all the requirements of 6068.  The same idea would work with 
> any device that needs some kind of command structure.  The example I gave was “send elevators to ground floor”.  That would 
> need a new INFO package because the command is different.  The elevator status would be Additional Data, and would be sent 
> in a body pointed to by the Call-Info, just like it would in the INVITE: same MIME type, same Content-Disposition.  But if I had a 
> container that sent a leak alarm, and that’s all it can do, using the eCall INFO package to request an update of its data would work fine with no changes.

But INFO is not just like the INVITE. 6086 defines rules for how to transport content using INFO, and Additional Data cannot override those rules.

>Using the INFO for command/control and Additional Data for the data is clean and makes sense.  It allows us to reuse the INFO
>package for other simple devices, and create others for more complex devices.  It makes processing at the PSAP simpler, because
>the data comes the same way whether it’s at the beginning of the call, it comes unsolicited or it comes as a response to a command to send it.

I am not sure I understand. You don't have to support the MSD Info Package in order to use the command/control protocol - it's defined separately, outside the MSD Info Package. You can use the protocol in whatever Info Package you want - and if you don't use INFO you don't even have to define an Info Package in order to use it.

Regards,

Christer

Brian

> On Aug 22, 2016, at 6:05 PM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 24 Aug 2016 05:53:32 +0000

Hi,
Looking on Christer's Comment:

>The question is whether the INFO request itself, and the MSD content transported in the INFO request, are >associated with the same "application" (ecall), and whether the MSD therefore must be sent using an Info >Package, as stated in 6086.

Discussing this all the time I'm wondering if we cannot come up with some text describing the "eCall" use case when using INFO with additional data for the eCall scenario. And make it clear that the application has to correlate the information.
I think all other cases are out of scope. 

Or I'm wrong?

Best regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Dienstag, 23. August 2016 18:28
An: Brian Rosen; Drage, Keith (Nokia - GB)
Cc: ECRIT
Betreff: Re: [Ecrit] Multipart with INFO

Hi,

Correct.

Correct.

> We’re arguing that the character of the data doesn’t change and the 
> schema of the data doesn’t change when you send it mid call, and it doesn’t matter what message you attach it to, it’s Additional Data.  What we need INFO for is the
> You may get a response to the request (in another INFO). That’s the 
> INFO transaction and it satisfies all the requirements of 6086.  6086 
> isn’t a straightjacket.  I’m happy to go get sippcore to tell us the obvious: we can send a Call-Info with a CID and a body, no matter what the relationship between the INFO and the Call-Info are.  Do you want me to ask for that?

> We want the MSD outside the INFO package because it’s Additional Data 
> and should be carried with a Call-Info pointing to the MIME type and schema registered for Additional Data, just like in the INVITE.
>
> We want the INFO package for its command (send the MSD) and response 
> (ACK).  That can only happen mid-call, so INFO is appropriate.  It’s a 
> well defined INFO package, and it satisfies all the requirements of 
> 6068.  The same idea would work with any device that needs some kind 
> of command structure.  The example I gave was “send elevators to 
> ground floor”.  That would need a new INFO package because the command is different.  The elevator status would be Additional Data, and would be sent in a body pointed to by the Call-Info, just like it would in the INVITE: same MIME type, same Content-Disposition.  But if I had a container that sent a leak alarm, and that’s all it can do, using the eCall INFO package to request an update of its data would work fine with no changes.

>Using the INFO for command/control and Additional Data for the data is 
>clean and makes sense.  It allows us to reuse the INFO package for 
>other simple devices, and create others for more complex devices.  It makes processing at the PSAP simpler, because the data comes the same way whether it’s at the beginning of the call, it comes unsolicited or it comes as a response to a command to send it.

Regards,

Christer

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Aug 2016 11:12:42 -0400

The notion authors have proposed is that we create a command channel for mid call communications between devices and PSAPs using INFO.  That requires an INFO package.  We can, however, make one INFO package that defines this protocol and use it for multiple instances of devices communicating with PSAPs, at least those that have a simple request update command.

We started this entire set of documents to manage sending of data from devices to PSAPs.  eCall is one example, an alarm is another.   In most cases, the initial data accompanies the INVITE.
If there is an update, the device can decide to send it.  It is also possible that the PSAP can request it.   Different devices have different data.

We’re arguing that the character of the data doesn’t change and the schema of the data doesn’t change when you send it mid call, and it doesn’t matter what message you attach it to, it’s Additional Data.  What we need INFO for is the request/response command channel.   You send an INFO with a request using an INFO package conforming to 6086.  You may get a response to the request (in another INFO).  That’s the INFO transaction and it satisfies all the requirements of 6086.  6086 isn’t a straightjacket.  I’m happy to go get sippcore to tell us the obvious: we can send a Call-Info with a CID and a body, no matter what the relationship between the INFO and the Call-Info are.  Do you want me to ask for that?  

We want the MSD outside the INFO package because it’s Additional Data and should be carried with a Call-Info pointing to the MIME type and schema registered for Additional Data, just like in the INVITE.  

We want the INFO package for its command (send the MSD) and response (ACK).  That can only happen mid-call, so INFO is appropriate.  It’s a well defined INFO package, and it satisfies all the requirements of 6068.  The same idea would work with any device that needs some kind of command structure.  The example I gave was “send elevators to ground floor”.  That would need a new INFO package because the command is different.  The elevator status would be Additional Data, and would be sent in a body pointed to by the Call-Info, just like it would in the INVITE: same MIME type, same Content-Disposition.  But if I had a container that sent a leak alarm, and that’s all it can do, using the eCall INFO package to request an update of its data would work fine with no changes.

Using the INFO for command/control and Additional Data for the data is clean and makes sense.  It allows us to reuse the INFO package for other simple devices, and create others for more complex devices.  It makes processing at the PSAP simpler, because the data comes the same way whether it’s at the beginning of the call, it comes unsolicited or it comes as a response to a command to send it.

Brian

---

From: Randall Gellens <[email-masked]>
Date: Fri, 26 Aug 2016 15:14:13 -0700

Hi Roland,

At 5:53 AM +0000 8/24/16, <[email-masked]> wrote:

>>The question is whether the INFO request itself, and the MSD 
>> content transported in the INFO request, are >associated with the 
>> same "application" (ecall), and whether the MSD therefore must be 
>> sent using an Info >Package, as stated in 6086.
>
>  Discussing this all the time I'm wondering if we cannot come up 
> with some text describing the "eCall" use case when using INFO with 
> additional data for the eCall scenario. And make it clear that the 
> application has to correlate the information.

The eCall use case when using INFO with additional data for the eCall 
scenario is:

1: IVS sends initial MSD in INVITE using Additional-Data
2: During the call, the PSAP call taker wants to see an updated MSD
2A: PSAP sends an INFO containing a request for the updated MSD 
(using INFO package)
2B: IVS responds with an INFO containing an ACK (using INFO package)
2C: IVS attaches an updated MSD to any convenient message using 
additional-data.  The message might be the INFO with the ACK

Note that the request and the ACK, which use an INFO package, can be 
considered a request/response application, which is a sub-component 
of the overall eCall application.

Does this help clarify?

--Randy

-------------- Randomly selected tag: ---------------
Nothing is so embarrassing as watching someone do something that you
said couldn't be done.                      --Sam Ewing