Re: SIMPLE and Emergency Services

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

On 2012-11-01 10:58, Sa=FAl Ibarra Corretg=E9 wrote:
> 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 irr=
edeemable failure,  I would note that SIMPLE is still under consideration f=
or use in emergency services, if only because XMPP isn't yet a viable alter=
native.  For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but r=
efer to XMPP support of emergency services as future work.  In emergency sc=
enarios, 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 locatio=
n, a message body and additional data.
>>
>> With SMS to 911 under active discussion with regulatory bodies, the ques=
tion about whether we can rely on SIMPLE for emergency use has become a "ho=
t issue".   As an example, there has been a suggestion that MESSAGE could b=
e used to  support conveyance of SMS text messages to a "text gateway"  tha=
t would then pass them on to the PSAP (possibly in a different form, such a=
s translating to TTY/TDD).  Not only might this help standardize the transp=
ort of SMS messages to 911, but it would also support future uses of MESSAG=
E for next generation emergency services.
>>
> I see you are mentioning SIP MESSAGE all along, but (please someone corre=
ct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not S=
IP MESSAGE. For translating SMS messages SIP MESSAGE works, but it lacks th=
e 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 spe=
cs, some folks have pointed to the lack of support for MESSAGE in SIP trunk=
ing services as an indication that even basic uses of SIMPLE are unlikely t=
o see much deployment, and that alternatives for disabled access to emergen=
cy services (such as RFC 4103 realtime text) should be given priority.
> Realtime text is another stream type negotiated with an INVITE, so I gues=
s MSRP could be used just fine for the same purpose by sending one MSRP chu=
nk with a single character at a time. There would be a bit of overhead, how=
ever.
>
>> IMHO,  unless XMPP for emergency uses is specified by IETF in the near f=
uture, it is likely that SIMPLE will find its way into emergency services a=
rchitectures in some form.  Since the IETF is still recommending SIMPLE in =
documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to pub=
lic safety to address interop issues that will arise in next generation eme=
rgency services scenarios.  AFAIK, SIMPLE interop issues haven't killed any=
one yet.  Hopefully this will remain true in the future.
> I'm unfamiliar with those documents, but are we talking presence here? Be=
cause this whole thing started about the presence part. To my knowledge the=
re are no interoperability problems with MSRP implementations following the=
 standard.
>
>
> Regards,
>
> --
> Sa=FAl Ibarra Corretg=E9
> AG Projects
>
>
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple