Subject: Re: [Simple] SIMPLE and Emergency Services

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 1 Nov 2012 10:58:17 +0100

Hi Bernard,

On Oct 31, 2012, at 11:08 PM, Bernard Aboba wrote:

> In response to Olle's question about whether SIMPLE is an abject and irredeemable failure,  I would note that SIMPLE is still under consideration for use in emergency services, if only because XMPP isn't yet a viable alternative.  For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to XMPP support of emergency services as future work.  In emergency scenarios, presence and address books are typically not considered since the PSAP is neither a presentity nor a watcher.   Instead, SIMPLE is used as a way of conveying information between the caller and PSAP, including location, a message body and additional data. 
> 
> With SMS to 911 under active discussion with regulatory bodies, the question about whether we can rely on SIMPLE for emergency use has become a "hot issue".   As an example, there has been a suggestion that MESSAGE could be used to  support conveyance of SMS text messages to a "text gateway"  that would then pass them on to the PSAP (possibly in a different form, such as translating to TTY/TDD).  Not only might this help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services. 
> 

I see you are mentioning SIP MESSAGE all along, but (please someone correct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not SIP MESSAGE. For translating SMS messages SIP MESSAGE works, but it lacks the concept of a 'session', so it doesn't fit well a model for a conversation.

> While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE in SIP trunking services as an indication that even basic uses of SIMPLE are unlikely to see much deployment, and that alternatives for disabled access to emergency services (such as RFC 4103 realtime text) should be given priority. 

Realtime text is another stream type negotiated with an INVITE, so I guess MSRP could be used just fine for the same purpose by sending one MSRP chunk with a single character at a time. There would be a bit of overhead, however.

> 
> IMHO,  unless XMPP for emergency uses is specified by IETF in the near future, it is likely that SIMPLE will find its way into emergency services architectures in some form.  Since the IETF is still recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to public safety to address interop issues that will arise in next generation emergency services scenarios.  AFAIK, SIMPLE interop issues haven't killed anyone yet.  Hopefully this will remain true in the future.  

I'm unfamiliar with those documents, but are we talking presence here? Because this whole thing started about the presence part. To my knowledge there are no interoperability problems with MSRP implementations following the standard.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 10:41:31 -0400

> I see you are mentioning SIP MESSAGE all along, but (please someone correct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not SIP MESSAGE. For translating SMS messages SIP MESS…

IIRC, MESSAGE is indeed a *part* of SIMPLE. But its use is restricted to 
"page mode" messaging (analogous to SMS), and not for "session mode" 
messaging.

	Thanks,
	Paul

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 1 Nov 2012 15:56:19 +0100

> IIRC, MESSAGE is indeed a *part* of SIMPLE. But its use is restricted to "page mode" messaging (analogous to SMS), and not for "session mode" messaging.
> 

Thanks for the clarification, Paul!

--
Saúl Ibarra Corretgé
AG Projects

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 01 Nov 2012 16:15:41 +0100

All three SIP related text protocols are not only considered for 
emergency service use, they are actually implemented.
I mean T.140/RFC 4103 real-time text, SIP Message and MSRP. They are all 
three required by RFC 6433, NENA NG-9-1-1 i3 technical specification and 
EENA NG-1-1-2 Long Term Definition.

There was an interop event arranged by NENA a couple of weeks ago, 
dedicated to accessibiity to emergency services for people with 
disabilities, but also including many other media related features.
Here is a link to what was done:
http://www.nena.org/?NG911_ICE5
It is only feasible to implement what is specified in common 
specifications and standards. So, it is quite late in the process and 
urgent to both discuss exclusion of MSRP and inclusion of XMPP if any 
such change shall be ready when services made according to these 
specifications are put in operation.

It would be natural to try to include XMPP in emergency service 
specifications, because of its dominance in the IM world. There is 
always a risk that some detail is lost in conversion to any of the other 
protocols. But there is a lot to consider when opening the emergency 
service speifications for one more protocol. Location, recording, 
multi-party calling, transfer, additional information, combination with 
video and audio, real-time flow, session start and end, call-back, 
protocol selection when calling etc.

You said "Realtime text is another stream type negotiated with an 
INVITE, so I guess MSRP could be used just fine for the same purpose by 
sending one MSRP chunk with a single character at a time. There would be 
a bit of overhead, however."

I want to kill the idea that real-time text would be sent character by 
character. All modern real-time text protocols are time-sampled, just 
like audio and video, but with longer sampling interval. RFC4103 is RTP 
based and uses a sampling interval of 300 ms. With the low overhead or 
RTP, and a maximum of 3.3 packets per second, it is very economical. The 
user acceptance for end-to-end delay is higher for real-time text than 
for video and audio. One second is easily accepted, and two seconds is 
still usable. Annoyance begins between two and three seconds. But 
presentation must be smooth, not in second-long jerks.

There was once a draft in IETF for real-time text based on MSRP. It was 
dropped because of a fear that it would be too heavy and because there 
was already a solution for real-time text. However, any text protocol 
gains in usability by being used in a real-time manner with time 
sampling and smooth display. XMPP is about to get its real-time 
enhancement in an XMPP extension called XEP-0301 Real-time text, 
intended to improve the usability of XMPP based IM. If that is used by 
an emergency caller, it would need to be converted to RFC 4103 at the 
border to the emergency service according to current specifications in 
order to not lose its real-time flow. That will be a bit messy - 
negotiate XMPP to MSRP conversion for old time IM use of XMPP, but XMPP 
to RFC 4103 conversion when XMPP is used with its real-time text extension.

It is maybe worth the effort to specify XMPP use in emergency services ( 
including its real-time extension) right away.

Gunnar

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 16:38:13 +0100

> IMHO,  unless XMPP for emergency uses is specified by IETF in the near future, it is likely that SIMPLE will find its way into emergency services architectures in some form.  Since the IETF is stil…
Thank you for your response, Bernard.

Yes, if the emergency services don't want to sign a contract with a single vendor of both servers and clients, but wants to have a choice - we need to fix interoperability. I do understand that many of the issues we've discussed here doesn't apply - like XCAP documents and buddy lists, so it MAY be easier, to use RFC language :-)

Realtime Text with RFC 4103/T.140 is implemented in many places today (and supported by Asterisk :-) )
so that's something that should not be ignored, regardless of plans to support IM/Chat.

/O

> 
> Olle E. Johansson said: 
> "Any other thoughts in regards to SIMPLE?
> 
> Is it a failure or not?
> 
> Do we have a chance of fixing this within the IETF?
> 
> Is anyone interested in fixing it so we actually reach the WG goal of interoperability?"
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Nov 2012 16:44:28 +0100

Release 11 of 3GPP IMS specifications add session based media to emergency call usage in addition to voice and real time text. For messaging, that includes MSRP.

While many countries are trying to ensure that PSAPs can handle SMS (which is not session based), this needs to be regarded as something that exists where nothing else does - as it provides the responder with no ability to interrogate the user to obtain more information.

For presence, nothing special has been specified by 3GPP.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 31 October 2012 22:08
To: [email-masked]
Subject: Re: [Simple] SIMPLE and Emergency Services

Olle E. Johansson said:

Is it a failure or not?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 12:11:01 -0400

On 11/1/12 11:44 AM, DRAGE, Keith (Keith) wrote:
> Release 11 of 3GPP IMS specifications add session based media to
> emergency call usage in addition to voice and real time text. For
> messaging, that includes MSRP.

PSAPs are going to provide an interesting and motivated testbed for 
SIMPLE interoperability. We know there will be an IMS SIMPLE client to 
the PSAPS. Unless the PSAP sw is built on an IMS platform, that will 
guarantee one point where interop will be required.

	Thanks,
	Paul

> While many countries are trying to ensure that PSAPs can handle SMS
> (which is not session based), this needs to be regarded as something
> that exists where nothing else does – as it provides the responder with
> no ability to interrogate the user to obtain more information.
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Bernard Aboba
> *Sent:* 31 October 2012 22:08
> *To:* [email-masked]
> *Subject:* Re: [Simple] SIMPLE and Emergency Services
>
>
>   *In response to Olle's question about whether SIMPLE is an abject and
>   irredeemable failure,  I would note that SIMPLE is still under
>   consideration for use in emergency services, if only because XMPP
>   isn't yet a viable alternative. For example, both NENA i3 and ECRIT
>   PhoneBCP mention SIMPLE, but refer to XMPP support of emergency
>   services as future work. In emergency scenarios, presence and address
>   books are typically not considered since the PSAP is neither a
>   presentity nor a watcher.  Instead, SIMPLE is used as a way of
>   conveying information between the caller and PSAP, including location,
>   a message body and additional data. *
>
> With SMS to 911 under active discussion with regulatory bodies, the
> question about whether we can rely on SIMPLE for emergency use has
> become a "hot issue". As an example, there has been a suggestion that
> MESSAGE could be used to support conveyance of SMS text messages to a
> "text gateway" that would then pass them on to the PSAP (possibly in a
> different form, such as translating to TTY/TDD).  Not only might this
> help standardize the transport of SMS messages to 911, but it would also
> support future uses of MESSAGE for next generation emergency services.
>
>
>
> While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE
> specs, some folks have pointed to the lack of support for MESSAGE in SIP
> trunking services as an indication that even basic uses of SIMPLE are
> unlikely to see much deployment, and that alternatives for disabled
> access to emergency services (such as RFC 4103 realtime text) should be
> given priority.
>
>
>
> IMHO, unless XMPP for emergency uses is specified by IETF in the near
> future, it is likely that SIMPLE will find its way into emergency
> services architectures in some form. Since the IETF is still
> recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF
> has a responsibility to public safety to address interop issues that
> will arise in next generation emergency services scenarios. AFAIK,
> SIMPLE interop issues haven't killed anyone yet. Hopefully this will
> remain true in the future.
>
>
>
> Olle E. Johansson said:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 19:27:16 +0100

1 nov 2012 kl. 16:44 skrev "DRAGE, Keith (Keith)" <[email-masked]>:

> While many countries are trying to ensure that PSAPs can handle SMS (which is not session based), this needs to be regarded as something that exists where nothing else does – as it provides the responder with no ability to interrogate the user to obtain more information.
>  
Keith,
Please guide me through this. Is 3gpp not using the OMA specs? 

For me that is classified as "special" and not part of the IETF specs. :-)

If not, have 3gpp tested interoperability of SIMPLE across vendors? The ability to add buddies and share buddy lists, regardless of client? Just curious of the process.

/O

> In response to Olle's question about whether SIMPLE is an abject and irredeemable failure,  I would note that SIMPLE is still under consideration for use in emergency services, if only because XMPP isn't yet a viable alternative. For
> example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to XMPP
> support of emergency services as future work. In emergency scenarios, presence
> and address books are typically not considered since the PSAP is neither a
> presentity nor a watcher.  Instead, SIMPLE is used as a way of conveying
> information between the caller and PSAP, including location, a message body and
> additional data. 
> 
> With SMS to 911 under active
> discussion with regulatory bodies, the question about whether we can rely on
> SIMPLE for emergency use has become a "hot issue". As an example,
> there has been a suggestion that MESSAGE could be used to support conveyance of SMS text messages to a
> "text gateway" that would then pass them on to the PSAP (possibly in
> a different form, such as translating to TTY/TDD).  Not only might this
> While documents like NENAi3 and ECRIT PhoneBCP still point
> to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE in
> SIP trunking services as an indication that even basic uses of SIMPLE are
> unlikely to see much deployment, and that alternatives for disabled access to
> emergency services (such as RFC 4103 realtime text) should be given priority. 
> 
> 
> 
> 
> 
> 
> 
> 
> IMHO, unless XMPP for emergency uses is specified by IETF
> in the near future, it is likely that SIMPLE will find its way into emergency
> services architectures in some form. Since the IETF is still recommending
> SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility
> to public safety to address interop issues that will arise in next generation
> emergency services scenarios. AFAIK, SIMPLE interop issues haven't killed
> anyone yet. Hopefully this will remain true in the future. 
> 
> 
> 
> 
> 
> 
> Olle E. Johansson said: 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Nov 2012 11:34:28 -0700

> I see you are mentioning SIP MESSAGE all along, but (please someone correct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not SIP MESSAGE. For translating SMS messages SIP MESS…

[BA] NENA i3 requires implementation of both MSRP and MESSAGE at the PSAP.  ECRIT PhoneBCP also mentions both.  So for emergency  uses, both MSRP and MESSAGE are potentially relevant. 

> Realtime text is another stream type negotiated with an INVITE, so I guess MSRP could be used just fine for the same purpose by sending one MSRP chunk with a single character at a time. There would…

[BA]  Currently the Access Board and other regulatory bodies do not have MSRP on the list of approved "realtime text" standards. 

> I'm unfamiliar with those documents, but are we talking presence here? Because this whole thing started about the presence part. To my knowledge there are no interoperability problems with MSRP imp…

[BA] Presence and address books are not relevant to emergency services because the PSAP is neither a presentity nor a watcher.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Nov 2012 19:40:11 +0100

As regards presence usage in 3GPP, my statement about presence related to emergency usage only.

As a capability, 3GPP specified presence in release 6, in 3GPP TS 24.141. This is an endorsement of IETF SIMPLE documents with the minor exception of collection of presence information about the user using existing 3GPP internal interfaces (e.g. status from HSS, location from GMLC), which are then adapted into SIMPLE protocols.

OMA subsequently specified their stuff which enhances and expands on IETF SIMPLE.

TISPAN took the 3GPP presence usage, but took the OMA XDM stuff to cover the list management.

GSMA took the OMA documents to create RCS.

Operators could be deploying any of this, but I suspect they are using RCS primarily.

And as said, none of this applies to emergency call to my knowledge, except possibly in the context of the PSAP being a normal user and being able to watch with those capabilities.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 01 November 2012 18:27
To: DRAGE, Keith (Keith)
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Simple] SIMPLE and Emergency Services

1 nov 2012 kl. 16:44 skrev "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>>:

/O

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernard Aboba
Sent: 31 October 2012 22:08
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Simple] SIMPLE and Emergency Services

Olle E. Johansson said:

Is it a failure or not?

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Nov 2012 11:45:52 -0700

Olle said:

"have 3gpp tested interoperability of SIMPLE across vendors? The ability to add buddies and share buddy lists, regardless of client? Just curious of the process."

[BA] AFAIK, there has been no interoperability testing of SIMPLE in emergency services scenarios (e.g. NENA ICE), and I am not aware of any emergency service providers that support either MSRP or MESSAGE.  The vast majority of SIP service providers also do not support SIMPLE, even for basic scenarios such as sending/receiving SMS via MESSAGE.   Given the potential timelines for shutdown of POTS (e.g. projections indicate that POTS will not longer be economically viable by 2018) and the transition to next generation emergency services (by the time POTS is shut down, we better have NG PSAPs), there is still quite a bit of work to do.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 19:53:25 +0100

> [BA] AFAIK, there has been no interoperability testing of SIMPLE in emergency services scenarios (e.g. NENA ICE), and I am not aware of any emergency service providers that support either MSRP or M…
Thanks for your information.

I'm personally a bit involved in the Swedish implementation of emergency services, so this is important information. In Sweden, the goal is to allow enterprises to call directly, bypassing the SIP trunks. That way we could possibly get more support for non-phone-call SIP, like MESSAGE or MSRP.

My questions to Keith was more general - not specific to emergency services. Sorry, I should have changed the subject.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 20:20:59 +0100

> And as said, none of this applies to emergency call to my knowledge, except possibly in the context of the PSAP being a normal user and being able to watch with those capabilities.

Keith,
Thanks for taking me through that dance... I now have a better understanding.

What is the current relationship betwen OMA and the IETF? ANy cooperation, like between 3Gpp and the IETF?

/O

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Nov 2012 14:52:45 -0500

> What is the current relationship betwen OMA and the IETF? ANy cooperation, like between 3Gpp and the IETF?

There is a liaison, but I don't think it's been very active for a while now.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 01 Nov 2012 21:39:58 +0100

Bernard Aboba wrote:
> [BA] AFAIK, there has been no interoperability testing of SIMPLE in 
> emergency services scenarios (e.g. NENA ICE), and I am not aware of 
> any emergency service providers that support either MSRP or MESSAGE. 
NENA ICE5 results say:

Testing covered a range of subjects that included:

  * Testing of methods for handling text messages within the i3 architecture

See http://www.nena.org/?NG911_ICE5

/Gunnar

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 22:05:45 +0100

> There is a liaison, but I don't think it's been very active for a while now.

Follow-up question:
When it was active, did any contributions from OMA make it into RFCs?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 1 Nov 2012 22:14:39 +0100

> When it was active, did any contributions from OMA make it into RFCs?

No. OMA publishes its own specification documents.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 1 Nov 2012 22:22:31 +0100

> No. OMA publishes its own specification documents.

Right, but they could have cooperated and been contributing anyway to the IETF docs...

SIP forum has a some documents too, but have been built them on RFCs and where RFCs where missing, initiated work to create them - like GIN.

/O

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Nov 2012 16:46:00 -0500

> SIP forum has a some documents too, but have been built them on RFCs and where RFCs where missing, initiated work to create them - like GIN.

Does anyone know if SIP Forum had any discussions on any of the SIMPLE interop topics?