Subject: [Ecrit] draft-ietf-ecrit-ecall-07

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 23 Mar 2016 09:08:43 +0000

>From my knowledge of the 3GPP work so far (essentially the stage 1 service requirements) I would note at least some things with this draft:

1)	The service URN is meant to identify the resource that is required by the requesting user. In a 3GPP environment that resource will be an entity that supports both some data means of transmission (I can guess it will sometimes be a body but that discussion has not reached that point yet), but will also be required to support an in-band form of the existing CS supported MSD. This is for interoperability and migration purposes. Any URN that does not identify support of both resources cannot be used in a 3GPP environment.

2)	Roaming is important in 3GPP. Some countries do not support ecall (and therefore do not provided dedicated ecall PSAPs). The proposed URNs will therefore, by virtue of stripping unrecognized subtypes, end up on the normal PSAPs. That could be OK if there is a voice media included. However there is a data only case in ecall which will not be directly usable by a standard PSAP - it will essentially be a silent emergency call. Note that the attitude of regulatory authorities to calls they cannot handle varies from country to country (some countries might even prosecute the generator of such calls). Mechanisms may need to be in place to prevent such ecalls when in regulatory regimes where ecall is not supported.

3)	The 3GPP requirements for test calls are not yet clear (at least to me). What is clear is that if they are treated as normal calls then they will not "MNOs can treat a vehicle call in the "test" service URN in a way that tests as much functionality as desired" because much of the network equipment will not be the same. Further for a roaming user, the test call may not even succeed. Further it is not yet clear (to me) whether all 3GPP ecall equipment and network providers will support non-emergency calls from an ecall device.

Given that resolving these will be different from any published IETF document based on the current draft and may well cause deployment problems in some regulatory areas if the current IETF document is implemented, my proposal is simple...

Regards

Keith Drage

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 24 Mar 2016 13:33:06 +0000

> On Mar 23, 2016, at 5:08 AM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
The URN is a marker, not a resource required.  It marks emergency calls.  The route is in the Route header.  You can put anything you want in there.  Additionally, we never found it necessary to mix CS supported emergency calls with IP supported emergency calls, and I don’t see why CS calls would change at all from what they are now.  You mark CS calls with “112”, not a service URN, and you treat them considerably differently than IP calls.
> 2)	Roaming is important in 3GPP. Some countries do not support ecall (and therefore do not provided dedicated ecall PSAPs). The proposed URNs will therefore, by virtue of stripping unrecognized sub…
If you want to “prevent” them, you have two choices.  One is to return an error on the signaling, the other is to route them to an IVR or something equivalent that tells them such calls are not permitted.  The former would require some more mechanism, but I don’t see that it would be incompatible with this document.  The latter doesn’t take any standards, just convention and provisioning of the route database.   Since the prevention is location dependent, it would be easiest to do it all in the route database and route to an IVR or tones generator that informs the user they are not allowed. 

> 3)	The 3GPP requirements for test calls are not yet clear (at least to me). What is clear is that if they are treated as normal calls then they will not "MNOs can treat a vehicle call in the "test"…
You can just disallow test calls if you want to, but I think that would be very unfortunate.  While implementations probably have to have mechanisms to limit intake of test calls if they will cause impairment of the network or PSAP, in every other way, the network should treat them exactly like emergency calls.  I don’t see any impact on 3GPP networks - they should be treated as emergency ecalls.  If you are handling test calls where “much of the network  equipment will not be the same”, you are doing it wrong.  The whole point of the test call is that the only difference is in how the PSAP responds to them.  The network doesn’t differentiate.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit