Subject: [Ecrit] WGLC - Data-Only Emergency Calls

From: Marc Linsner <[email-masked]>
Date: Fri, 09 Nov 2012 12:35:53 -0500

This start the WGLC for draft Data-Only Emergency Calls

The draft can be found at:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea

Please review the draft and provide comments to the list before COB on
November 23, 2012.

Thanks,

Marc & Roger

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 10 Nov 2012 00:19:02 +0100

I see a slight protocol contradiction in section 4.1.

There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is 
used for exchanges where no session establishment is needed, i.e.., 
one-shot message exchange, and the SIP INVITE [RFC3261] where the 
establishment of session is useful (e.g., when multiple independent 
messages have to be logically tied together). "

I wonder if RFC 3261 and RFC3264 allows setting up a session without 
session description defined media. To me it seems that all session need 
to have media agreed through session descriptions.

In RFC 3261 SIP, section 13.3.1.4, it is said:

"If the INVITE did
    not contain an offer, the 2xx MUST contain an offer if the UAS had
    not yet sent an offer."

So, it seems that an Offer/Answer sequence is required.

And in RFC 3264 Offer/answer model, chapter 6.1, it is said:
"If there are no media formats in common for all streams, the entire
    offered session is rejected."

These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange.

This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session.

Do you agree in this conclusion?

Gunnar

----

On 2012-11-09 18:35, Marc Linsner wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 10:34:35 -0500

Gunnar,

> So, it seems that an Offer/Answer sequence is required.

Yes, to establish a session an O/A is required.

>     offered session is rejected."

The above statement is a bit ambiguous wrt the degenerate case where no 
streams are offered. (No m-lines in offer.) I would argue that there 
*are* media formats in common for every offered stream, so the "session 
is rejected" does not apply. In any case this statement is 
non-normative. I have always thought that an answerer is free to keep 
the session up with no media streams if that seems useful.

I do think it would be useful to provide an example of a Data-Only 
Emergency call that establishes a session. Also, it would be helpful to 
have an explanation of *why* one might want that session established.

I presume the idea is that there could then be a new O/A within the 
session to establish media, without the need for a psap-callback. Is 
that right?

Has any concern been given for cases where UDP must be used and the 
messages are too big for that? It might be helpful in some cases to 
establish a session with an MSRP stream and send the data over that. 
That could also be helpful if the local sensors are capable of sending a 
sequence of data readings rather than just one.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 12 Nov 2012 11:01:14 -0500

The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate.

Brian

On Nov 12, 2012, at 10:34 AM, Paul Kyzivat <[email-masked]> wrote:

> The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful.
> 
> I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established.
> 
> I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right?
> 
> Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one.
> 
> 	Thanks,
> 	Paul
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Nov 2012 17:20:42 +0100

I do not think an example is needed.

I am just afraid that SIP stack implementors could have read SIP + SDP + 
O/A model as I did, and introduced automatic disconnection for a 
media-less session.

The behavior Paul describes is a mutual agreement between implementers 
of the CAP alerting. What if there is a B2BUA in between, created by a 
careful implementer.

How do you mean that a session with "m-lines for all 0 offered media" 
look like?
Shall it be SDP exchange but with no m-lines?

Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 11:28:28 -0500

> The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate.

That is a good example, and it would be good to have it in the document.
ISTM that it doesn't clearly fit the mechanisms included in the 
document. IIUC the doc includes two mechanisms:

- send a MESSAGE with no dialog, with the data in the MESSAGE body.

- send an INVITE with no media, with the data in the body of the INVITE.
   The session remains up for further use, but no mention of *what* use.
   In the case you describe above, how would the additional readings
   be transmitted? In a MESSAGE within the dialog? In the body of a
   reINVITE? This needs further explanation.

ISTM that if the *intent* is to establish a session in order to send a 
sequence of data readings over time, then it would make sense to 
establish an MSRP session and send them all (including the first) over 
this channel.

OTOH, if there is a *single* data reading to transmit but there is a 
desire to establish a session in order to facilitate later adding media 
streams, then the mechanism in the document makes sense. In that case it 
might be *better* to offer the media streams that *can be* supported, 
either in inactive state, or with port set to zero.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Nov 2012 11:56:08 -0500

> of the CAP alerting. What if there is a B2BUA in between, created by a

I explained my reasoning for why it is valid according to 3264.
Others may believe otherwise. We can deal with it as it arises, or apply 
an errata to 3264 if need be.

OR, different signaling that has higher likelihood of being accepted 
could be chosen. (Elsewhere I suggested m-lines with port=0, or inactive.)

> Shall it be SDP exchange but with no m-lines?

Yes. An INVITE with an SDP containing no m-lines is an offer - it is 
different from an INVITE with no SDP body at all.

	Thanks,
	Paul

>> The example is a sensor that detects some bad circumstance, but
>> continues to take readings and wants to send updates at some
>> reasonable rate.
>>
>> Brian
>>
>>> The above statement is a bit ambiguous wrt the degenerate case where
>>> no streams are offered. (No m-lines in offer.) I would argue that
>>> there *are* media formats in common for every offered stream, so the
>>> "session is rejected" does not apply. In any case this statement is
>>> Emergency call that establishes a session. Also, it would be helpful
>>> to have an explanation of *why* one might want that session established.
>>>
>>> That could also be helpful if the local sensors are capable of
>>> sending a sequence of data readings rather than just one.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> These rules taken together seem to result in that in order to set up
>>>> a session to convey a series of CAP MESSAGES, then some (e.g. dummy)
>>>> medium must be agreed also in a sessions description exchange.
>>>>
>>>> This would mean that a session cannot be set up for only CAP MESSAGE
>>>> conveyance, but of course it is possible to have CAP messages and
>>>> some other useful media in the same session.
>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Nov 2012 18:35:14 +0100

There is also a discussion in RFC 3428 SIP Message to consider.

e.g in chapter 2:

"implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE
    requests with one another."

So, it is no clean case to set up a session just for transmission of SIP Messages and nothing else, it is a composition of grey areas.

I do not think we should complicate the issue by requiring MSRP or having the CAP as Body part in the INVITE. Maybe just some words of advice on how to create the kind of session you want with highest likelihood of success.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

On 2012-11-12 17:56, Paul Kyzivat wrote:
> Others may believe otherwise. We can deal with it as it arises, or 
> apply an errata to 3264 if need be.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 12 Nov 2012 13:35:51 -0500

I should have expanded my answer, because I agree with you.

Having talked it over with several SIP folks, the idea of multiple MESSAGES in a session is a bad idea, and if we want to do updates to the CAP message, MSRP is the right answer.  

I don't see the value in a "maybe I'll send media later" session.  I see no use case for that.

We do want to be able to include the CAP message in a regular (with media) INVITE.  That allows the sensor data AND the media ("Help I've fallen and can't get up").  So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow.  

Brian

On Nov 12, 2012, at 11:28 AM, Paul Kyzivat <[email-masked]> wrote:

> ISTM that it doesn't clearly fit the mechanisms included in the document. IIUC the doc includes two mechanisms:
> 
> ISTM that if the *intent* is to establish a session in order to send a sequence of data readings over time, then it would make sense to establish an MSRP session and send them all (including the first) over this channel.
> 
> OTOH, if there is a *single* data reading to transmit but there is a desire to establish a session in order to facilitate later adding media streams, then the mechanism in the document makes sense. In that case it might be *better* to offer the media streams that *can be* supported, either in inactive state, or with port set to zero.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 12 Nov 2012 19:46:28 +0100

Brian, you say:
"We do want to be able to include the CAP message in a regular (with 
media) INVITE. That allows the sensor data AND the media ("Help I've 
fallen and can't get up"). So a CAP message in a Body with SDP in an 
INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow."

Good conclusion.

Gunnar

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Nov 2012 12:58:14 -0500

Hi all, 

In the data-only ES document we have two use cases:

Use Case #1: a one-shot MESSAGE with a body that contains a CAP message.

There is no session concept there. There does not seem to be a problem with this approach. 

Use Case #2: a sequence of MESSAGE msgs

The example that Brian mentioned on the mailing list is a sensor that detects some bad circumstance. It sends an alarm but continues to take readings and wants to send updates. We would like to to avoid the situation where messages end up at different places since they are addressed to the SOS URN. For this reason we thought that it would be good to use a session concept here. 

As Gunnar had pointed out that our understanding of how this would work contracts with existing specifications. Very good feedback, Gunnar. 

So, how do we address this feedback? I see three options. 

Option #1: Omit use case #2 from the document and just focus on the individually routed SIP MESSAGE payloads. 

Option #2: Include use case #2 by utilizing MSRP*, as suggested by Paul. 

Option #3: Limit use case #2 by using a CAP payload in a regular SIP INVITE (with media)
With this case it is not possible to use the CAP payloads alone without media.  

I prefer option #3. 

Ciao
Hannes

*: As we learned in discussions on a separate mailing list MSRP is actually not that difficult to implement when only focusing on the emergency services use case. 

On Nov 12, 2012, at 1:46 PM, Gunnar Hellström wrote:

> Brian, you say:
> "We do want to be able to include the CAP message in a regular (with media) INVITE. That allows the sensor data AND the media ("Help I've fallen and can't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow."
> 
> Good conclusion.
> 
> Gunnar
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Nov 2012 15:51:42 -0500

> With this case it is not possible to use the CAP payloads alone without media.

I'm not sure I understand what you are suggesting for #3. I think you 
are proposing to send subsequent CAP payloads in reINVITEs. I don't know 
what you mean "it is not possible to use the CAP payloads alone without 
media". Are you continuing the worry that some middlebox won't allow an 
INVITE without m-lines? I think that calls for more investigation before 
assuming.

Option #4: Set up INVITE session (with or without media). Send 
subsequent CAP in INFO. (Maybe send first CAP in INFO too - your choice.)

	Thanks,
	Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Nov 2012 22:46:40 -0500

Hi Paul, 

see my response below. 

On Nov 13, 2012, at 3:51 PM, Paul Kyzivat wrote:

> I'm not sure I understand what you are suggesting for #3. I think you are proposing to send subsequent CAP payloads in reINVITEs. I don't know what you mean "it is not possible to use the CAP payloads alone without media". 

Actually, in option #3 there are no subsequent re-INVITEs. Option #3 just documents that the CAP payload can also be used with an INVITE that carries media. 

> Are you continuing the worry that some middlebox won't allow an INVITE without m-lines? I think that calls for more investigation before assuming.

I don't know whether the INVITE + CAP payload + SDP payload without m-lines and using MESSAGE msgs for subsequent CAP messages within the same dialog actually works in existing deployments. 

> 
> Option #4: Set up INVITE session (with or without media). Send subsequent CAP in INFO. (Maybe send first CAP in INFO too - your choice.)

In this case I guess you are assuming that the SDP is again without m-lines. Right? 

Ciao
Hannes

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Nov 2012 09:52:33 -0500

Option 4: both 2 and 3

We want to show how to do updates or stream of sensor data.

We also want to show how you do the CAP + media.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2012 10:38:33 -0500

> In this case I guess you are assuming that the SDP is again without m-lines. Right?

Yes.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Nov 2012 10:51:17 -0800

If the scenario is updating the PSAP on developments, continuing notification via any option is not the best choice, because it can add load without necessarily providing info that the PSAP needs or cares about. Providing the PSAP with a link which it can access to get more info may make more sense.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 15 Nov 2012 15:51:46 -0500

Not sure I agree with that, but perhaps it would be better to do a subscription from the PSAP for updates.

The only issue with THAT is how to indicate the subscription URI in the MESSAGE or INVITE.

Brian

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Nov 2012 17:29:03 -0800

Sorry for the delay in sending this.

In both the Abstract and Section 1, please delete the text regarding 
vehicles sending crash data, since that use case normally involves 
establishing an interactive media stream for voice communication 
between the vehicle occupants and the PSAP.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You may be only one person in the world,
but you may also be the world to one person.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Nov 2012 17:37:45 -0800

At 1:35 PM -0500 11/12/12, Brian Rosen wrote:

>  Having talked it over with several SIP folks, the idea of multiple 
> MESSAGES in a session is a bad idea, and if we want to do updates 
> to the CAP message, MSRP is the right answer.

What about INFO (with an info package specific to data-only emergency calls)?

>  We do want to be able to include the CAP message in a regular (with 
> media) INVITE.  That allows the sensor data AND the media ("Help 
> I've fallen and can't get up").  So a CAP message in a Body with 
> SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what 
> we want to allow.

Is this a use case where a medical device establishes a normal 
emergency call with interactive voice media, or is it where a device 
wants to send non-interactive media (e.g., pre-recorded voice 
announcement)?  The former seems outside the scope of this document, 
but the latter would fit, aside from the issue of how to send the 
media (perhaps as an attachment in the body and hence no session is 
needed).

-------------- Randomly selected tag: ---------------
The first rule is, you must not fool yourself.  And you are the
easiest person to fool.                       --Richard Feynman

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Nov 2012 17:42:05 -0800

At 3:51 PM -0500 11/15/12, Brian Rosen wrote:

>  perhaps it would be better to do a subscription from the PSAP for updates.
>

Call-Info with a new 'purpose' tag?

-------------- Randomly selected tag: ---------------
The Macintosh may only have 10% of the market, but it is clearly
the top 10%.
       --Douglas Adams, 1996 WWDC.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Nov 2012 07:02:52 +0100

On 2012-11-29 02:37, Randall Gellens wrote:
>> MESSAGES in a session is a bad idea, and if we want to do updates to 
>> the CAP message, MSRP is the right answer.
>

INFO would also need a session.
I am sorry I started this by pointing at wording in SIP and 
Offer/Answer, together indicating that a session without SDP media shall 
not be accepted. Maybe few or no implementations have followed that 
logic so that it would be feasible with errata to SIP or Offer/Answer to 
allow such sessions.
-- But that goes against Brian's finding declared above...

It would be good to have the same mechanism for a series of CAP messages 
in a session with media as for a series of CAP messages without media.

/Gunnar

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Nov 2012 09:20:56 -0500

> What about INFO (with an info package specific to data-only emergency calls)?
Gunnar correctly pointed out the problem with this, INFO needs a session.

> Is this a use case where a medical device establishes a normal emergency call with interactive voice media, or is it where a device wants to send non-interactive media (e.g., pre-recorded voice announcement)?  The former seems outside the scope of this document, but the latter would fit, aside from the issue of how to send the media (perhaps as an attachment in the body and hence no session is needed).
The former.  It may be "outside the scope", but that means we have the scope of the document (and maybe the title) wrong.  You ought to be able to send data with or without media the same way.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Nov 2012 09:23:07 -0500

Yeah, possible.  Another possible is a Type/Value in the CAP message.

Brian

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Nov 2012 06:32:56 -0800

At 7:02 AM +0100 11/29/12, Gunnar Hellström wrote:

>>>   Having talked it over with several SIP 
>>> folks, the idea of multiple MESSAGES in a 
>>> session is a bad idea, and if we want to do 
>>> updates to the CAP message, MSRP is the right 
>>> answer.
>>

Right, that's why I suggested INFO instead of 
MESSAGE for use within a session.  Brian said 
multiple MESSAGE within a session was bad, so how 
about multiple INFO, which is specifically 
designed for a session.  If however the problem 
is the session and not the use of MESSAGE within 
a session, then of course INFO doesn't help.

-------------- Randomly selected tag: ---------------
I find that a great part of the information I have was acquired by
looking up something and finding something else on the way.
                                   --Franklin P. Adams (1881-1960)

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Nov 2012 06:37:17 -0800

At 9:20 AM -0500 11/29/12, Brian Rosen wrote:

>> emergency call with interactive voice media, or is it where a 
>> device wants to send non-interactive media (e.g., pre-recorded 
>> voice announcement)?  The former seems outside the scope of this 
>> document, but the latter would fit, aside from the issue of how to 
>> send the media (perhaps as an attachment in the body and hence no 
>> session is needed).

>  The former.  It may be "outside the scope", but that means we have 
> the scope of the document (and maybe the title) wrong.  You ought 
> to be able to send data with or without media the same way.

If there is an interactive media stream and a session, then it isn't 
a 'data-only' call, is it?

If this document is handling both 'data-only' and 'normal' emergency 
calls with sensor data, then we need to pull it back out of WGLC, 
enlarge the scope, and work on the use cases and mechanisms more. 
It's not good to do significant redesign of technical work in a rush 
during WGLC.

-------------- Randomly selected tag: ---------------
Two things are infinite: the universe and human stupidity;
and I'm not even sure about the universe.
                                        --Albert Einstein

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Nov 2012 11:34:48 -0500

> in a session with media as for a series of CAP messages without media.

How about making a list of all the possible mechanisms people can think 
of, with their pros/cons? Then picking the best one(s). Here is a 
candidate list based mostly on things already discussed here:

1) MESSAGE, out of dialog, to carry CAP data.
    Sequence of MESSAGEs for sequence of data readings.

2) CAP message body part in INVITE, reINVITE, and UPDATE.
    Use offer with no m-lines if no media is available.
    (Or, audio m-line with c=0.0.0.0 if that works better.)

3) INVITE to establish session. INFO to carry CAP messages.
    Use offer with no m-lines if no media is available.
    (Or, audio m-line with c=0.0.0.0 if that works better.)

4) INVITE to establish session. MSRP media session to carry
    CAP messages.

5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to
    emergency device with NOTIFYs to carry subsequent CAP data.
    (TBD: mechanism to convey support for subscribe and the URI.)

(Note I have included things above that I consider bad ideas. That can 
be dealt with in the pros/cons.)

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 29 Nov 2012 23:52:56 +0100

On 2012-11-29 17:34, Paul Kyzivat wrote:
>
> How about making a list of all the possible mechanisms people can 
> think of, with their pros/cons? Then picking the best one(s). Here is 
> a candidate list based mostly on things already discussed here:
>
Good move.

It seems that also human texting with PSAPs would have the same need of 
a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:
" MESSAGEs received from the same caller within a configurable time (2-3 
minutes nominally) should be considered part of the same "call", and 
must be routed to the same PSAP (and the same call taker), regardless of 
movement of the caller while texting. If the origination network/device 
supports non session mode IM to NG9-1-1, it must assure that all 
messages from the same caller within this time frame is sent to the same 
ESInet (same ECRF query results).If the network/device cannot guarantee 
this, it must use session mode.

So the same question exists also for this case is:  What kind of 
session, and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this 
detail, therefore I looked at how the usage was in NG112 and NG911.

So, let us try to solve this the same way for both kinds of usage.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Nov 2012 16:00:04 -0800

At 11:52 PM +0100 11/29/12, Gunnar Hellström wrote:

>  It seems that also human texting with PSAPs 
> would have the same need of a solution.

Yes, but that's already covered.  NENA 08-003 
wants session mode, and other SDOs have agreed 
and specified MSRP within a session.

>  So, let us try to solve this the same way for both kinds of usage.

Data-only is (at least up to now) a different use 
case, since there is (up to now) no interactive 
media stream.

-------------- Randomly selected tag: ---------------
Nice guys finish last, but we get to sleep in.  --Evan Davis

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Nov 2012 19:00:50 -0500

A message session is MSRP.  So if we're using MESSAGE, we use MSRP if we have a sequence of them, but have no media.

If there is media, you have an INVITE.  ReINVITE or UPDATE could carry a CAP message, but probably we would be better served by INFO for in-dialog update of the CAP alert assuming push.

I believe I would be happiest with MESSAGE or INVITE for the first message, and SUB/NOT for updates.  That handles the case of MSRP for IM media, since the MSRP session is established with INVITE.

Brian

On Nov 29, 2012, at 5:52 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate list based mostly on things already discussed here:

(Note I have included things above that I consider bad ideas. That can be dealt with in the pros/cons.)

    Thanks,
    Paul
Good move.

It seems that also human texting with PSAPs would have the same need of a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:
" MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same “call”, and must be routed to the same PSAP (and the same call taker), regardless of movement of the caller while texting.  If the origination network/device supports non session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results).  If the network/device cannot guarantee this, it must use session mode.

So the same question exists also for this case is:  What kind of session, and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911.

/Gunnar

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

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 30 Nov 2012 07:50:34 +0100

On 2012-11-30 01:00, Rosen, Brian wrote:
> A message session is MSRP.  So if we're using MESSAGE, we use MSRP if 
> we have a sequence of them, but have no media.
Right. That makes sense.
>
> If there is media, you have an INVITE.  ReINVITE or UPDATE could carry 
> a CAP message, but probably we would be better served by INFO for 
> in-dialog update of the CAP alert assuming push.
>
> I believe I would be happiest with MESSAGE or INVITE for the first 
> message, and SUB/NOT for updates.  That handles the case of MSRP for 
> IM media, since the MSRP session is established with INVITE.
In case of SUB/NOT,  it has been indicated in this thread that the PSAP 
would do the SUBSCRIBE after receiving the initial MESSAGE.
- Then there would be a need for a way for the transmitting device to 
indicate that a SUBSCRIBE is wanted. How would that be indicated?
-Also, there is a need for a way to guarantee that the SUBSCRIBE is 
addressed to the transmitting device and is answered only by the 
transmitting device. It seems as a GRUU may needed, and other 
considerations similar to an emergency service callback.

Gunnar

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Nov 2012 13:47:47 +0100

The conclusion I seem to come to on all these emergency call issues is that a dialog is needed, because you need to deliver to the same PSAP who is handling this for possible emergency voice calls, and that PSAP needs to be able to correlate all the input. While there are some ways round this, it always seems so much easier to say a dialog must exist. That eliminates 1) and possibly 5).

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Hellström
Sent: 29 November 2012 22:53
To: [email-masked]
Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls

    Thanks,
    Paul
Good move.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:
" MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same "call", and must be routed to the same PSAP (and the same call taker), regardless of movement of the caller while texting.  If the origination network/device supports non session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results).  If the network/device cannot guarantee this, it must use session mode.

/Gunnar

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 30 Nov 2012 09:04:56 -0500

There are many situations where there is one, and only one message from device to PSAP.  There is no dialog and no media.  That's what started the entire draft.  We are now dealing with the case where there are updates to the data, and we're trying to make sure that if there is media AND data, that the data looks pretty much the same (i.e. a CAP message)

If you created a "dialog" with SUBSCRIBE that has all the right characteristics for routing and correlation.  It also lets the PSAP decide the rate of updates using filters.  I think "pull" via SUBSCRIBE is a better fit for the problem than PUSH with MESSAGE/INFO.  There has to be a device generated (push) trigger, so we need INVITE/MESSAGE for that.  It's possible to just say you always start with INVITE and do an immediate BYE if there is no media, but that seems pretty lame.

Brian

On Nov 30, 2012, at 7:47 AM, "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>> wrote:

Regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gunnar Hellström
Sent: 29 November 2012 22:53
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls

    Thanks,
    Paul
Good move.

/Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2012 12:33:05 -0500

> considerations similar to an emergency service callback.

Yes, this should be quite analogous to emergency callback.

	Thanks,
	Paul