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

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 13:40:56 +0000

Hi,

Regarding fallback, I think it could be useful to add a note saying that
3GPP TS XXXXX defines how to do fallback to CS. I don¹t think we need to
say much more than that.

Regards,

Christer

On 23/08/16 15:15, "[email-masked]" <[email-masked]> wrote:

>Hi Keith,
>You are talking about:
>
>4)	Knowing that the initial MSD sent in the INVITE request has been
>received. 
>
>... 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?
>
>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:
>
>>  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).
>>>>>>
>>>>>>    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.
>>>>>
>>>>>    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.
>>>>
>>>>   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.
>>>
>>>  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.
>
>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?
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

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

CS domain is outside the scope of the IETF work, and therefore any mention needs to be informative.

The purpose of mentioning it was to distinguish between cases where an explicit response is required, which is this one, versus the cases where I believe we should rely on timeouts and SIP failures, and therefore no explicit response is required.

I believe the use case for CS fallback is the only case where an explicit application level response is required.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 23 August 2016 14:41
To: [email-masked]; Drage, Keith (Nokia - GB); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: AW: [Ecrit] ecall: Why do we need ACK for successful requests?

Hi,

Regarding fallback, I think it could be useful to add a note saying that 3GPP TS XXXXX defines how to do fallback to CS. I don¹t think we need to say much more than that.

Regards,

Christer

On 23/08/16 15:15, "[email-masked]" <[email-masked]> wrote:

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