A point for discussion: I believe below is evidence that the complexity of
implementation may hinder deployment of emergency services, and may even be
a root cause of things breaking down at a critical moment. People's lives
may depend on a proxy interpreting location information properly
Especially for the use case of emergency calls, would it not be wise to
select a much more simple approach/syntax, e.g.:
Emergency-Location: lat=x; lon=y
So no XML, no mime/multipart, as simple as possible (no complex semantics,
usage-rules etc), something to reduce the barrier of
implementation/deployment, and to reduce the risk for interop issues?
Regards,
Jeroen
Brian Rosen wrote:
I'd like to point out one thing about this:
This is how they answered for multipart/mime:
2% I break if someone sends me multipart/mime
24% I pretend multipart/mime doesn't exist if someone sends it to
me 24% I ignore multipart/mime but will proxy it or hand it to my
application if it shows up
10% I try to do something useful with multipart/mime I receive,
but I never send it
4% I ignore multipart/mime that I receive, but I try to do
something useful with multipart/mime I send
24% I try to do something useful with multipart/mime I send and
receive
12% Other
Moving forward, SIP UAs and proxies will be required to support
location-conveyance (currently draft-ietf-sip-location-conveyance-07)
in order to support location for emergency calls (citizen to
authority, like 1-1-2 or
9-1-1). -conveyance requires multipart support.
The consequences of not supporting emergency call location will be
serious. I believe it is likely that there will eventually be
regulatory requirements to support emergency calls in some
jurisdictions. Upgrades to several components of today's
infrastructure will be needed before this all works, but stack
vendors and UA developers should put multipart (and
location-conveyance) on their development plans for next year at the
latest.
Brian
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
