Subject: [Ecrit] ecall: Why do we need ACK for successful requests?

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

(NOTE that this e-mail is not related to the Info Package discussion)

Hi,

Assume the PSAP sends a request for MSD to the UA.

The UA sends the MSD back.

Why does the UA needs to send ACK? The MSD will acknowledge the request, won’t it?

I do understand that the UA needs something if it won’t send the MSD (or whatever data was requested), e.g. if there was something wrong with the request). But, if the UA does accept the request, and does send the data, I don’t see why the explicit ACK is needed. It will only add message size (and maybe even additional INFO messages).

Regards,

Christer

---

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

On 8/19/16 3:46 AM, Christer Holmberg wrote:
> I do understand that the UA needs something if it won’t send the MSD (or
> whatever data was requested), e.g. if there was something wrong with the
> request). But, if the UA does accept the request, and does send the
> data, I don’t see why the explicit ACK is needed. It will only add
> message size (and maybe even additional INFO messages).

In one of the long ago original proposals, in response to the request, 
there was either a NAK or the MSD. That would be potentially ambiguous, 
since MSD can also be sent unsolicited: after sending a request, if you 
received an MSD you wouldn't know if it was the one you requested, or if 
it was an unsolicited one and there might yet be a NAK to follow. The 
ACK resolves the ambiguity.

But such issues depend heavily on the details. Minor tweaks might 
resolve the ambiguity other ways.

Since we are discussing various hypotheticals now, there aren't enough 
details to know whether an ACK is needed.

	Thanks,
	Paul

---

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

Hi,

>> Why does the UA needs to send ACK? The MSD will acknowledge the request,
>> won¹t it?
>>
>> I do understand that the UA needs something if it won¹t send the MSD (or
>> data, I don¹t see why the explicit ACK is needed. It will only add

Not sure I understand. There must be some identifier that matches the MSD
with the request - in the same way there must be some identifier that
matches the ACK with the request.

>details to know whether an ACK is needed.

If you refer to the Call-Info discussion, I don¹t think this has anything
to do with that. This is not about how you transport the stuff in SIP.

Regards,

Christer

---

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

> matches the ACK with the request.

Yes. AFAIK there is nothing in the MSD itself that links it to the 
request, so if the MSD is intended to implicitly acknowledge the request 
then there needs to be *something* with it that links it to the request.

> to do with that. This is not about how you transport the stuff in SIP.

You could go with a philosophy where successful requests are never 
acknowledged - only failed ones. I find such protocols to be fragile.

	Thanks,
	Paul

---

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

Hi,

>then there needs to be *something* with it that links it to the request.

Can we use the Content-ID header field value? Would it be allowed to use
the same header field value in the request and the associated MSD? Then
you don’t need to define a separate indicator for each type of data, as
it’s a MIME header field.

>acknowledged - only failed ones. I find such protocols to be fragile.

But the whole idea was that the MSD/data acknowledges the request.

But, IF we want something more explicit, why not e.g. a Info-Package
header field parameter? And, regarding “never acknowledged”, we anyway
need some guidance on for how long the requester should wait for the
acknowledgment (no matter if it’s implicit or explicit).

Regards,

Christer

---

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

Christer,

> it’s a MIME header field.

Use it *how*? I have generally assumed that the scope/lifetime of a 
Content-ID is limited to a single message. (I don't think there is any 
expectation the the Content-ID values are unique beyond the message they 
are contained in.) But I don't know if that is well defined.

In any case, if you wanted to reference it from another message 
containing the MSD you would need some place to put it. *In* the MSD 
would be an obvious place, but is there any way to do that? If not, then 
*with* the MSD.

Alternatively, you can define that the request for a new MSD is just a 
hint to send one "unsolicited".

(E.g., something like the CANCEL message. It gets a response that 
indicates it was received and understood, but that response doesn't 
indicate it was acted upon. It is just a hint that you would be happy to 
have the recipient do something. And it may lead to some other 
subsequent actions, like a 487 indicating that another request was 
terminated. But you never know, or expect to know, for certain whether 
that action was the result of your CANCEL, or happened for some other 
reason.)

> acknowledgment (no matter if it’s implicit or explicit).

It is really hard to discuss this stuff piecemeal. All the moving parts 
need to fit together into a coherent and unambiguous whole.

	Thanks,
	Paul

---

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

Hi Christer,

You are correct: In the compromise proposal, since the 
metadata/control object is associated with the INFO package, while 
the MSD is not, then if the PSAP sends an INFO request to the IVS 
containing a metadata/control object requesting an MSD, the IVS can 
return the MSD in the INFO response.  In this case, there is no need 
for an ACK.

At 7:46 AM +0000 8/19/16, Christer Holmberg wrote:

>  Why does the UA needs to send ACK? The MSD will acknowledge the 
> request, won't it?
>
>  I do understand that the UA needs something if it won't send the 
> MSD (or whatever data was requested), e.g. if there was something 
> wrong with the request). But, if the UA does accept the request, 
> and does send the data, I don't see why the explicit ACK is needed. 
> It will only add message size (and maybe even additional INFO 
> messages).
>
>  Regards,
>
>  Christer
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
...neither the whole of truth nor the whole of good is revealed
to any single observer, although each observer gains a partial
superiority of insight from the peculiar position in which he
stands.'                                      --William James, 1899

---

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

At 10:48 AM -0400 8/19/16, Paul Kyzivat wrote:

>>>>  won1t it?
>>>>  I do understand that the UA needs something if it won1t send the MSD (or
>>>>  data, I don1t see why the explicit ACK is needed. It will only add
> request, so if the MSD is intended to implicitly acknowledge the 
> request then there needs to be *something* with it that links it to 
> the request.

In the compromise proposal that I sent, the MSD was sent in its own 
INFO, along with a metadata/control object acknowledging the request. 
However, since RFC 6086 permits INFO responses to contain data that 
is not associated with the INFO package, and since per the compromise 
proposal the metadata/control object is associated with the INFO 
package but the MSD is not, then the IVS can send a requested MSD in 
the INFO response, which removes any ambiguity (and also saves an 
extra INFO message).  In the car-crash draft, if the PSAP requests 
the vehicle to perform an action (e.g., flash the lights), then the 
IVS would send an INFO request to the PSAP containing a 
metadata/control object acknowledging the request and indicating if 
it was carried out.

--Randy

>>  If you refer to the Call-Info discussion, I don1t think this has anything

-------------- Randomly selected tag: ---------------
You might have mail.

---

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

On 8/19/16 2:42 PM, Randall Gellens wrote:
>>>>> request,
> However, since RFC 6086 permits INFO responses to contain data that is
> not associated with the INFO package, and since per the compromise
> proposal the metadata/control object is associated with the INFO package
> but the MSD is not, then the IVS can send a requested MSD in the INFO
> response, which removes any ambiguity (and also saves an extra INFO
> message).  In the car-crash draft, if the PSAP requests the vehicle to
> perform an action (e.g., flash the lights), then the IVS would send an
> INFO request to the PSAP containing a metadata/control object
> acknowledging the request and indicating if it was carried out.

I am ok with sending the MSD as additional data on the INFO response. 
But I don't think that should be taken as an affirmative statement that 
the MSD is specifically in response to the request. Doing that would 
tightly couple two mechanisms that should only be loosely coupled.

Consider the following following sequence of events:

- caller is in a call with the PSAP
- caller prepares to send a reINVITE (for codec change, or
   session timer, or whatever), but hasn't yet sent it.
   It decides, independently, to include a fresh MSD in it.
- caller receives an INFO from PSAP, requesting an MSD.

Now, what does the caller do? Potentially these are being processed 
concurrently in different threads. Can the MSD in the INVITE satisfy the 
request in the INFO? Does it matter whether it sends the INVITE before 
or after the INFO response?

	Thanks,
	Paul

---

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

Hi,

>>>>>> request, won¹t it?
>>>>>> I do understand that the UA needs something if it won¹t send the 
>>>>>> and does send the data, I don¹t see why the explicit ACK is 
>>>>>> needed. It will only add message size (and maybe even additional 
>>>>>> INFO messages).
>>>>>
>>>>> In one of the long ago original proposals, in response to the 
>>>>> request, there was either a NAK or the MSD. That would be 
>>>>> potentially ambiguous, since MSD can also be sent unsolicited: 
>>>>> after sending a request, if you received an MSD you wouldn't know 
>>>>> if it was the one you requested, or if it was an unsolicited one 
>>>>> and there might yet be a NAK to follow. The ACK resolves the 
>>>>> ambiguity.
>>>>
>>>> Not sure I understand. There must be some identifier that matches 
>>>> the MSD with the request - in the same way there must be some 
>>>> identifier that matches the ACK with the request.
>>>
>>> request then there needs to be *something* with it that links it to the request.
>>
>> Can we use the Content-ID header field value? Would it be allowed to 
>> use the same header field value in the request and the associated MSD? 
>> Then you don't need to define a separate indicator for each type of 
>> data, as it's a MIME header field.
>
> Use it *how*? I have generally assumed that the scope/lifetime of a Content-ID is limited to a single 
> message. (I don't think there is any expectation the the Content-ID values are unique beyond the message they are contained in.) 
> But I don't know if that is well defined.

I wouldn't be surprised if that was the case.

>In any case, if you wanted to reference it from another message containing the MSD you would need some place 
>to put it. *In* the MSD would be an obvious place, but is there any way to do that? If not, then
>*with* the MSD.

If we place in *in* the MSD it would be MSD-specific, and we'd have to define another mechanism once a new type of data comes along. I'd prefer to place it *with* the MSD - either associated with the MSD message body or the INFO request carrying it.

>Alternatively, you can define that the request for a new MSD is just a hint to send one "unsolicited".
>
> (E.g., something like the CANCEL message. It gets a response that indicates it was received and understood, but that response doesn't indicate it was acted upon. It is just a > hint that you would be happy to have the recipient do something. And it may lead to some other subsequent actions, like a 487 indicating that another request was 
> terminated. But you never know, or expect to know, for certain whether that action was the result of your CANCEL, or happened for some other
> reason.)

Since we explicitly request the MSD, I think there should be an explicit reference to the request in/with the MSD.

>>>>> Since we are discussing various hypotheticals now, there aren't 
>>>>> enough details to know whether an ACK is needed.
>>>>
>>>> If you refer to the Call-Info discussion, I don¹t think this has 
>>>> anything to do with that. This is not about how you transport the 
>>>> stuff in SIP.
>>>
>> header field parameter? And, regarding "never acknowledged", we anyway 
>> acknowledgment (no matter if it's implicit or explicit).
>
> It is really hard to discuss this stuff piecemeal. All the moving parts need to fit together into a coherent and unambiguous whole.

I guess the first question is whether we need *A* reference. Or, do we assume that, if an MSD comes along, it is what we requested?

Regards,

Christer

---

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

Hi,

>You are correct: In the compromise proposal, since the metadata/control object is associated with the INFO package, while the MSD is not, then if the PSAP sends an INFO >request to the IVS containing a metadata/control object requesting an MSD, the IVS can return the MSD in the INFO response.  In this case, there is no need for an ACK.

My question was whether the MSD implicitly acknowledges the request, and whether we therefor need the ACK. I REALLY don't see what the Info Package issue has to do with that...

Regards,

Christer

At 7:46 AM +0000 8/19/16, Christer Holmberg wrote:

>  I do understand that the UA needs something if it won't send the MSD 
> (or whatever data was requested), e.g. if there was something wrong 
> with the request). But, if the UA does accept the request, and does 
> send the data, I don't see why the explicit ACK is needed.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- ...neither the whole of truth nor the whole of good is revealed to any single observer, although each observer gains a partial superiority of insight from the peculiar position in which he
stands.'                                      --William James, 1899

---

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

> I guess the first question is whether we need *A* reference. Or, do we assume that, if an MSD comes along, it is what we requested?

I think it is bad to do that unless there is something that ties it to 
the request.

But it may not be necessary to know if the one you get is in response to 
your request for a new one. You want a new one, and you get a new one. 
Isn't that good enough? Later you might get another new one, even 
without asking again.

	Thanks,
	Paul

---

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

Hi,

>>>>>>>> MSD (or whatever data was requested), e.g. if there was 
>>>>>>>> something wrong with the request). But, if the UA does accept 
>>>>>>>> the request, and does send the data, I don¹t see why the 
>>>>>>>> explicit ACK is needed. It will only add message size (and maybe 
>>>>>>>> even additional INFO messages).
>>>>>>>
>>> Content-ID is limited to a single message. (I don't think there is 
>>> any expectation the the Content-ID values are unique beyond the message they are contained in.) But I don't know if that is well defined.
>>
>>> would be an obvious place, but is there any way to do that? If not, 
>>> then *with* the MSD.
>>
>> If we place in *in* the MSD it would be MSD-specific, and we'd have to define another mechanism 
>> once a new type of data comes along. I'd prefer to place it *with* the MSD - either associated with 
>> the MSD message body or the INFO request carrying it.
>>
>>> indicate it was acted upon. It is just a > hint that you would be 
>>> happy to have the recipient do something. And it may lead to some 
>>> other subsequent actions, like a 487 indicating that another request 
>>> was terminated. But you never know, or expect to know, for certain 
>>> whether that action was the result of your CANCEL, or happened for 
>>> some other reason.)
>>
>>>> header field parameter? And, regarding "never acknowledged", we 
>>>> anyway need some guidance on for how long the requester should wait 
>>>> for the acknowledgment (no matter if it's implicit or explicit).
>>>
> I think it is bad to do that unless there is something that ties it to the request.
>
> But it may not be necessary to know if the one you get is in response to your request for a new one. You want a new one, and you get a new one. 
> Isn't that good enough? Later you might get another new one, even without asking again.

I just think it's good protocol design to be able to match the delivered data with the request for the data to be delivered. 

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Fri, 19 Aug 2016 15:09:20 -0700

Hi Paul,

At 3:51 PM -0400 8/19/16, Paul Kyzivat wrote:

>>>>  the MSD
>  I am ok with sending the MSD as additional data on the INFO 
> response. But I don't think that should be taken as an affirmative 
> statement that the MSD is specifically in response to the request.

I'm fine with that.  As you said in a different response, the PSAP 
asks for an updated MSD, and gets an updated MSD.  I'm not sure it 
matters if the MSD is specifically in response to the request or not. 
Especially given the context: we expect the PSAP to request an MSD 
only when the call taker thinks something may have changed, which we 
expect will be fairly uncommon.  So, the call taker asks for an 
updated MSD, and the PSAP receives a new MSD and updates the display. 
The call taker doesn't care if the MSD was specifically in response 
to the request or not.

>   Doing that would tightly couple two mechanisms that should only be 
> loosely coupled.
>
> concurrently in different threads. Can the MSD in the INVITE 
> satisfy the request in the INFO? Does it matter whether it sends 
> the INVITE before or after the INFO response?

I think that if the IVS receives a request for an MSD, it needs to 
respond with an MSD, even if it had just sent one.  However, the IVS 
would have no reason to send an MSD except in the initial INVITE or 
after a request, so I don't think this situation would ever arise.

--Randy

-------------- Randomly selected tag: ---------------
People that are really very weird can get into sensitive
positions and have a tremendous impact on history.
    --then U.S. Vice President Dan Quayle

---

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

> after a request, so I don't think this situation would ever arise.

ISTM that the IVS *could* realize that something has changed, and 
spontaneously send a new MSD. (E.g., sometime after the crash perhaps 
the car catches fire, or starts moving because it is sliding down an 
embankment.)

(I don't know what is *in* an MSD, since that seems to be defined in EN 
15722, and that apparently isn't freely available. Maybe there is 
nothing in it that *could* change. But then this whole discussion is moot.)

	Thanks,
	Paul

---

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

Hi,

This is not about MSD. It's about the request protocol (which I assume in future might also be used in other applications than ecall), and whether a request shall be explicitly acknowledged or not - and how.

And, as I've said before, there needs to be guidance on how long the requester should wait for the requested data, before it considers the request a failure.

Regards,

Christer

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎20/‎08/‎2016 01:44
To: Randall Gellens<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests?

        Thanks,
        Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 19 Aug 2016 21:14:25 -0700

At 6:44 PM -0400 8/19/16, Paul Kyzivat wrote:

> spontaneously send a new MSD. (E.g., sometime after the crash 
> perhaps the car catches fire, or starts moving because it is 
> sliding down an embankment.)
>
>  (I don't know what is *in* an MSD, since that seems to be defined 
> in EN 15722, and that apparently isn't freely available. Maybe 
> there is nothing in it that *could* change. But then this whole 
> discussion is moot.)

The MSD contains information about the vehicle's state and position, 
including some information about the occupants, so it's possible that 
the data could change (e.g., if the vehicle moves or occupants that 
were in the vehicle aren't).  That's the reason for the mid-call 
update request: to allow the PSAP to request an updated MSD if the 
call taker thinks something might have changed.  My point was simply 
that, based on current eCall requirements, there's nothing that says 
that the vehicle should send an updated MSD on its own, so I doubt 
that any IVS implementations would do so.

-------------- Randomly selected tag: ---------------
Collaboration: A literary partnership based on the false assumption
that the other fellow can spell.

---

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

On 8/19/16 6:57 PM, Christer Holmberg wrote:
> Hi,
>
> This is not about MSD. It's about the request protocol (which I assume
> in future might also be used in other applications than ecall), and
> whether a request shall be explicitly acknowledged or not - and how.

That is a fair question.

The response to the INFO acknowledges that it was received. But that is 
only at the signaling level. It doesn't confirm that the content was 
processed and understood. And explicit ACK (in its own INFO) is a way to 
achieve that for an explicit request/response protocol.

Of course that ACK need not be in an INFO. It could be something else, 
as long as it is well defined by the protocol, and unambiguously linked 
to the request.

I don't think an MSD conveyed in additional-data can be unambiguously 
linked to the request, distinguishing it from an MSD that that was send 
unsolicited but just happens to arrive.

If the goal is to optimize messages, then I could see embedding an MSD 
in an explicit ACK. (In an info-package body.) That would be an 
*alternative* to sending an MSD as additional-data. But that doesn't 
really save much (a few bytes) over sending a simpler ACK and 
piggybacking an MSD in additional-data in the same message.

	Thanks,
	Paul

> And, as I've said before, there needs to be guidance on how long the
> requester should wait for the requested data, before it considers the
> request a failure.
>
> Regards,
>
> Christer
>
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: Randall Gellens <mailto:[email-masked]>; Christer
> Holmberg <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Aug 2016 18:20:16 +0000

Hi,

> The response to the INFO acknowledges that it was received. But that is only at the signaling level. It doesn't confirm that the content was processed and understood.

Agree.

> And explicit ACK (in its own INFO) is a way to achieve that for an explicit request/response protocol.

Agree.

> Of course that ACK need not be in an INFO. It could be something else, as long as it is well defined by the protocol, and unambiguously linked to the request.

Yes.

> I don't think an MSD conveyed in additional-data can be unambiguously linked to the request, distinguishing it from an MSD that that 
> was send unsolicited but just happens to arrive.
>
> If the goal is to optimize messages, then I could see embedding an MSD in an explicit ACK. (In an info-package body.) That would be an
> *alternative* to sending an MSD as additional-data. But that doesn't really save much (a few bytes) over sending a simpler ACK and 

Well, we don't have an agreement on how to transport the MSD. I was hoping that we could decide in general whether an ACK is needed or not.

In addition, even if an ACK is sent, the next question is whether there must be *A* indicator mapping the content (e.g. MSD) to the corresponding request. 

Regards,

Christer

> (I don't know what is *in* an MSD, since that seems to be defined in 
> EN 15722, and that apparently isn't freely available. Maybe there is

---

From: "Randall Gellens (IETF)" <[email-masked]>
Date: Mon, 22 Aug 2016 11:53:58 -0700

Sent from my iPad

> On Aug 22, 2016, at 11:20 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

In the compromise proposal last week, each request would have an explicit ack. I don't think we need to have a mechanism to tie an MSD to a specific request. The ack acknowledges the request, and an MSD satisfies it. The PSAP performs a mid-call request for an MSD only when the call taker thinks something might have changed. If it gets an updated MSD, it doesn't matter if it was sent to satisfy the request or for some other reason (although in reality it won't be sent for any other reason).

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Aug 2016 19:09:49 +0000

Hi,

>>>> This is not about MSD. It's about the request protocol (which I 
>>>> assume in future might also be used in other applications than 
>>>> ecall), and whether a request shall be explicitly acknowledged or not - and how.
>>> 
>>> That is a fair question.
>>> 
>>> linked to the request, distinguishing it from an MSD that that was send unsolicited but just happens to arrive.
>>> 
>>> If the goal is to optimize messages, then I could see embedding an 
>>> MSD in an explicit ACK. (In an info-package body.) That would be an
>>> really save much (a few bytes) over sending a simpler ACK and piggybacking an MSD in additional-data in the same message.
>> 
> In the compromise proposal last week, each request would have an explicit ack. I don't think we need to have 
> a mechanism to tie an MSD to a specific request. The ack acknowledges the request, and an MSD satisfies it. 
> The PSAP performs a mid-call request for an MSD only when the call taker thinks something might have 
> changed. If it gets an updated MSD, it doesn't matter if it was sent to satisfy the request or for some other 
> reason (although in reality it won't be sent for any other reason).

Again, I am taking about using the request protocol to request data in general.

In my opinion, there should be a way to associate requested content with the actual request.

Regards,

Christer

>> ---------------------------------------------------------------------
>> -
>> --

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Aug 2016 16:05:06 -0400

> In my opinion, there should be a way to associate requested content with the actual request.

That is another layer of protocol design. While it doesn't seem 
necessary for MSD, it could be important for some other (as yet 
hypothetical) cases.

If you want to address that, then I think one of the following would work:

1) define an extensible body for the ACK. (E.g., a multipart body) Use 
it to contain the "response" to a particular request.

2) define the request to contain an identifier. Use the ACK to confirm 
acceptance of the request and committment to follow up. Also include 
that identifier in any messaage(s) that are intended as answers to the 
request. Will then have to figure out what form those messages are, and 
how to associate the identifier with them.

Of those, (2) is potentially more flexible, but also more complex to 
design and use.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 Aug 2016 13:32:23 -0700

At 4:05 PM -0400 8/22/16, Paul Kyzivat wrote:

>>>  In the compromise proposal last week, each request would have an 
>>> explicit ack. I don't think we need to have
>>>  a mechanism to tie an MSD to a specific request. The ack 
>>> acknowledges the request, and an MSD satisfies it.
>>>  changed. If it gets an updated MSD, it doesn't matter if it was 
>>> sent to satisfy the request or for some other
>  1) define an extensible body for the ACK. (E.g., a multipart body) 
> Use it to contain the "response" to a particular request.
>
>  2) define the request to contain an identifier. Use the ACK to 
> confirm acceptance of the request and committment to follow up. 
> Also include that identifier in any messaage(s) that are intended 
> as answers to the request. Will then have to figure out what form 
> those messages are, and how to associate the identifier with them.
>
>  Of those, (2) is potentially more flexible, but also more complex 
> to design and use.

Each request has a unique ID which is also used in the ACK to 
acknowledge that specific request.  We don't have that in the MSD, 
and I don't think we need it for the MSD.  We might need it for a 
future type of data, and in that case, the future type of data should 
include the ID of the request it is in response to.

-------------- Randomly selected tag: ---------------
Our greatest fear is that the Internet will become a vehicle of free
distribution of information.  --Ken Wasch, President of the Software
                           Publishers' Association, 5 September 1995

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 Aug 2016 13:41:22 -0700

At 1:32 PM -0700 8/22/16, Randall Gellens wrote:

>>>>   In the compromise proposal last week, each request would have 
>>>> an explicit ack. I don't think we need to have
>>   1) define an extensible body for the ACK. (E.g., a multipart 
>> body) Use it to contain the "response" to a particular request.
>>
> future type of data, and in that case, the future type of data 
> should include the ID of the request it is in response to.

To add to this: the MSD is defined by CEN and encoded in ASN.1; we 
can't alter it to add an ID field.  Luckily, we don't actually need 
the ID in the case of the MSD.

-------------- Randomly selected tag: ---------------
There's no chance that the iPhone is going to get any significant
market share.  No chance.    --Steve Ballmer, Microsoft CEO, 2007

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Aug 2016 20:45:05 +0000

Hi,

>>> Also include that identifier in any messaage(s) that are intended as 
>>> answers to the request. Will then have to figure out what form those 
>>> messages are, and how to associate the identifier with them.
>>>
>> acknowledge that specific request.  We don't have that in the MSD, and 
>> I don't think we need it for the MSD.  We might need it for a future 
>> type of data, and in that case, the future type of data should include 
>> the ID of the request it is in response to.
>
> To add to this: the MSD is defined by CEN and encoded in ASN.1; we can't alter it to add an ID field.  Luckily, we don't actually need the ID in the case of the MSD.

I am not talking about adding the information to the MSD content itself - then we would have to do it for every new type of content than can be requested. I am talking about something generic in the message that is carrying the MSD.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Mon, 22 Aug 2016 13:49:46 -0700

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

>> can't alter it to add an ID field.  Luckily, we don't actually 
>> need the ID in the case of the MSD.
>
>  I am not talking about adding the information to the MSD content 
> itself - then we would have to do it for every new type of content 
> than can be requested. I am talking about something generic in the 
> message that is carrying the MSD.

I think it's better in the data, since it's small, not all data needs 
it, and the data can be sent in different ways.

-------------- Randomly selected tag: ---------------
Who's on first?

---

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

Hello,

my view:

1) unless we want to allow an IVS participating in a call to send a new MSD to the PSAP on the IVS own decision, then MSD itself is successful acknowledgement of the request. Thus, an explicit successful acknowledgement of the request is NOT needed.

2) if we want to allow an IVS participating in a call to send a new MSD to the PSAP on the IVS own decision:

	- we need to distinguish:
		- MSD-sent-upon-IVS-own-decision; and
		- MSD-sent-upon-PSAP-request;
		and indicate so from the IVS to the PSAP. For MSD-sent-upon-PSAP-request, there would have to be some linkage to the request from PSAP.

	- MSD-sent-upon-PSAP-request is a successful acknowledgement of the request. Again, another explicit successful acknowledgement of the request is NOT needed.

3) I agree that we need and explicit message from the IVS to the PSAP if, upon receiving request from the PSAP, the IVS decides NOT to send an MSD 

So, the first step to find a way forward is:

	Do we want to allow an IVS participating in a call to send a new MSD to the PSAP on the IVS own decision?

Kind regards

Ivo Sedlacek

---

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

Just finished working back over the entire thread. This discussion is getting way too complicated and I think we need to simplify it. Working through the issues as follows:

1)	Transactional uniqueness.

We have a dialog. 3GPP stage 1 documents require it for all emergency calls. The Info package is correlated with the dialog - a separate dialog would have a separate instance of the Info package. When one defines an application using an Info package, one has to decide what sort of protocol is running over the top, in terms of transactional complexity. This one is a very simply protocol where I do not believe one would ever need two simultaneous transactions within this instance of the Info package, and given that the result of the request is the current MSD, I do not think it would ever matter if there were allowed to be two requests outstanding - it does not matter if the MSD is sent in response to request 1 or request 2. So the MSD received relates to the endpoints identified within the dialog, and if any audit trail is required, then the SIP timestamp header field can be utilised, but there is never a need to relate a response to a specific request.

As far as I am aware, there is no such parallel transactional behaviour in the existing CS domain modem mechanism.

2)	Knowing that a response to an request for MSD is not lost.

I agree with Paul in stating that a response to an INFO request indicates that the data has been received, but does not indicate that it has been processed.

So when the emergency user agent sends an MSD in an INFO request, it will not know for sure that the application in the PSAP has received it. I believe it is up to the PSAP to police and resolve this issue (and we should agree this).

The PSAP will know that data has been received validly at the SIP level, even if it is corrupted or malformed at the application level. If such data is malformed, then it is a simple matter for the PSAP application to send another request. Depending on the nature of the original failure, the second one will either suceed or not. At some point in a sequence of such failures the PSAP will need to decide that requesting will never work, but this mechanism should be used for one off errors.

3)	Knowing that a request for MSD is not lost. 

The PSAP application will need to communicate with the SIP layer so that the PSAP application is notified if a response is not received to a request for an MSD in an INFO message.

4)	Knowing that the initial MSD sent in the INVITE request has been received. 

I have not yet seen a discussion of this in this thread, but because it relates I will raise it. This is the only point where I believe an explicit acknowledgement is needed, but for different reasons to what might be expected. It is not needed so that the emergency user agent knows that the MSD has been received, because a similar discussion to that in 2) above applies - there are a number of indicators to the PSAP that it should have received an MSD, and if it does not get one it can request one, assuming the Info package has been negotiated. It is needed because the PSAP and the emergency user agent need to know that the call has fallen back to operating in the CS domain at some point, and therefore end to end transfer of SIP data is lost, and therefore the CS domain mechanism of in-band data needs to be adopted. A mechanism is provided for in the 3GPP specifications.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 22 August 2016 21:50
To: Christer Holmberg; Randall Gellens; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests?

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

>>>>>>    changed. If it gets an updated MSD, it doesn't matter if it 
>>>>>> was  sent to satisfy the request or for some other
>>>>    Of those, (2) is potentially more flexible, but also more 
>>>> complex  to design and use.
>>>

I think it's better in the data, since it's small, not all data needs it, and the data can be sent in different ways.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Who's on first?

---

From: <[email-masked]>
Date: Tue, 23 Aug 2016 12:15:26 +0000

Hi Keith,
You are talking about:

... It is needed because the PSAP and the emergency user agent need to know that the call has fallen back to operating in the CS domain at some point, and therefore end to end transfer of SIP data is lost, and therefore the CS domain mechanism of in-band data needs to be adopted. A mechanism is provided for in the 3GPP specifications.

So my question is if you see now the need to add some words with regard to Fallback within this draft or do we need something other where we document that?
Or is this a 3GPP task?

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Drage, Keith (Nokia - GB)
Gesendet: Dienstag, 23. August 2016 13:26
An: Randall Gellens; Christer Holmberg; Paul Kyzivat
Cc: [email-masked]
Betreff: Re: [Ecrit] ecall: Why do we need ACK for successful requests?

Regards

Keith