Henry Sinnreich wrote:
Keith,
Sorry to repeat: The SIP UA can call any emergency SIP URI such as SOS or
dial 911 through a PSTN gateway. Is this clear enough?
I'm pretty sure that the emergency services experts will tell you that
"dial 911 through a PSTN gateway" is not an acceptable implementation.
It won't provide the location information (at least not without a lot of
other configuration), among other things.
Nor will calling an emergency SIP URI (urn:service:sos I think) work
unless you have some server in the network that provides the service of
routing that to the right place. Again you will need location info, etc.
to make this work. IOW, stuff that currently isn't part of sip-tools.
Needless to point out that using the Internet for emergency and avoiding 911
will also support life saving data such as medical vital signs, location
(GPS & mobile triangulation) and video.
If you do the long list of stuff required to make this all work, which
requires stuff not in sip-tools.
If you intend for emergency services calls to be among the things that
you can do with sip-tools, then call it out and somebody will verify if
you have specified everything needed to make it work. But if we don't
know that is in scope then we can't do that.
Thanks,
Paul
Henry
On 10/22/08 11:45 AM, "DRAGE, Keith (Keith)" <drage@xxxxxxxxxxxxxxxxxx>
wrote:
I believe most of us are actually on the same page which is:
- if you consider a feature is necessary (for this profile) then
list all the documents needed to support that feature.
- if a feature is not necessary (for this profile) then clearly
say that the set of documents identified will not support that feature.
Thus I seized on RFC 3966 earlier. Using that as an example, I have no
problem with the profile either including it or not, but if it is not
there, then clearly say that interworking with the PSTN will not be
possible, and that emergency calls using PSTN like numbers will be
impossible.
Obviously various network providers will have their reasons for various
extensions being necessary and supported in their networks. Readers need
to be able to clearly identify the mismatch between what the profile
contains and what those operators think is needed. What those network
providers would call "plain SIP" would not be the same list as you would
use. The security requirements invariably differ.
Regards
Keith
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Adrian Georgescu
Sent: Wednesday, October 22, 2008 10:43 AM
To: sipping@xxxxxxxx
Subject: [RAI] Expert review of draft-sinnreich-sip-tools-03
Hi Paul,
I believe Henry is heading into one direction only. The idea
is to help developers implement the minimum necessary
features in their User Agent and not biased towards a voice
only application. The SIP end- points as describe by Henry
would work with any service provider as long as they talk
plain SIP. So 911 and voicemail and other services can be
performed in the network as well, they are just another end- point.
If I were to develop a SIP UA today (which I do actually)
Henry's draft would be the starting point. I would definitely
add MSRP to it, without relays as a minimum but adding relay
extension is not that difficult, because any application that
requires reliable or large data transport need a TCP media
plane that SIP signalling or RTP does not provide. End-to-end
encryption can also be realized on top of established MSRP
session. File transfer and session based IM are applications
that an end user would take for granted today and SIP lacks both.
Also the rich presence conflicts with the basic presence
PIDF, I would go for rich presence even if the "richness" of
the information is something that would be avoided due to its
complexity in the presentation to end-user interface.
For the rest I would not do much changes to the draft.
Regards,
Adrian
Henry,
Based on this discussion, it now sounds like you are heading in *two*
directions:
- connecting to a SP that provides services (e.g. 911, maybe others,
like voicemail, forwarding, ...)
The SP in this case is largely looking for a "dumb" device and
provides the services in the network. The "request for service"
is then "tunneled" via simple services like invite, with the
service request encoded in the AOR. (e.g. the "911", or "star"
codes).
In this case you are then competing with other profiles, such as
SIPConnect or PacketCable.
- very low added value SP, that simple provides registration
and routing. All services are provided by the UAs.
I'd like to see the goals spelled out better. Then we can
discuss if they are met.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current
sip Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
