Re: [RAI] Expert review of draft-sinnreich-sip-tools-03

["Brian Rosen" <[e-mail]>]

Going forward, in the U.S. at least, you will need all of phonebcp.  We're
going to start deploying "NG9-1-1" next year. Which, for VoIP, IM or any
other kind of multimedia, is built on -phonebcp.  And, in addition to
Henry's disdain for B2BUAs, much of what -phonebcp says could not be
implemented by a B2BUA.  The location stuff, in particular, is roughly
impossible to do with a B2BUA if the calling network cannot restrict the
access (broadband) network, something I'm sure this work is trying to cover.
If you fixed that, then you face the problem that the location isn't sent
unless the endpoint recognizes that the call it is placing is an emergency
call; but it doesn't know that without some more of -phonebcp, and without
location on the call, a downstream B2BUA or proxy can't figure out what is
an emergency call.  It goes on from there.  Bottom line is -phonebcp isn't
optional when used within a country that implements IP based emergency
calling.

Brian

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of DRAGE,
Keith (Keith)
Sent: Tuesday, October 21, 2008 1:14 PM
To: Henry Sinnreich; Paul Kyzivat; Eunsoo Shim
Cc: [e-mail]; [e-mail];
[e-mail]
Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03

Henry wrote:

> Correct. There is no reason an endpoint cannot use a 911-like 
> phone number, SOS or any other SIP address and also 
> communicate its location.

To use sos you need RFC 5031 which is not in your profile.

To use 911 or similar numbers you are assuming the use of RFC 3966 which
is not in your profile. 

It would also seem to invalidate (because it puts the mapping
responsibility back in the phone):

  o Avoiding design considerations for SIP for compatibility with 
     legacy telephony networks, traditional telephony services and their

     various addressing plans. This pushes the responsibility of mapping

     the URI to telephone numbers to edge networks where the IP-PSTN 
     gateway functions are performed. Other handling of telephony 
     specific functions such as early media are also pushed to edge 
     gateway networks. 
 
There is also an assumption in such cases that you are interworking with
the PSTN to get to the PSAP.

To send location using SIP you need draft-ietf-sip-location-conveyance,
which is not in your profile. Or were you assuming some other mechanism.

Regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Henry Sinnreich
> Sent: Tuesday, October 21, 2008 5:28 PM
> To: Paul Kyzivat; Eunsoo Shim
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03
> 
> Paul,
> 
> > Many (most?) deployments work in
> > this way - the (dumb) phones connect to a B2BUA. It then 
> handles all 
> > the harder stuff.
> Aha! You have pinpointed it very well.
> * We are looking here at the opposite of dumb phones that 
> handle only voice
> * I also don't suppose you support SIP networks based on 
> B2BUA to handle "harder stuff"
> 
> Eunsoo Shim wrote:
> >> I don't see a reason emergency calls cannot be supported with the 
> >> tools listed in the document.
> Correct. There is no reason an endpoint cannot use a 911-like 
> phone number, SOS or any other SIP address and also 
> communicate its location.
> 
> > A point of *my* comments was that the draft itself wasn't entirely 
> > clear about what it was asserting these tools are capable 
> of providing.
> 
> There is no limit in what applications in the endpoint can provide.
> Though we seem to focus in this discussion mostly on voice 
> (with some rare SIMPLE mentions), smart phones and Rich 
> Internet Applications (RIA) on the web are a proof from real 
> life. Most smart phone vendors report 1,000's of applications 
> from independent developers. I could not count for example 
> the number of SIP UA and SIP services for the iPhone alone 
> and my apology for not mentioning all the other excellent 
> smart phones.
> (One cannot also avoid seeing all these reports out showing 
> the diminishing numbers or plain disappearance of dumb 
> landline phones - service providers for sure are looking to 
> overcome this, possibly using our I-D :-) )
> 
> Question: Do you think the use cases with examples of RIA and 
> smart phone applications should be mentioned in the Introduction?
> 
> Henry
> 
> On 10/21/08 10:56 AM, "Paul Kyzivat" <[e-mail]> wrote:
> 
> > 
> > 
> > Eunsoo Shim wrote:
> > 
> >> Many phone adapters that are widely used in the market, 
> certainly by 
> >> some major VoIP service providers I know of, support just 
> a few SIP 
> >> related RFCs. One of the largest phone adapter vendors implemented 
> >> just RFC 3261, 3262, 3263, 3264 and 4566. And those VoIP service 
> >> providers support emergency calls. In the deployments I 
> know of, all 
> >> you need is routing emergency calls to a gateway that 
> interfaces with 
> >> databases and the PSTN infrastructure for emergency calls. The end 
> >> users have to register the addresses where the phone adapters are 
> >> used (often on web sites) and the addresses are relayed to 
> and stored 
> >> in databases with the corresponding phone numbers.
> > 
> > One *piece* of the overall system can get by with limited 
> > functionality
> > *if* other pieces pick up the slack. Many (most?) 
> deployments work in 
> > this way - the (dumb) phones connect to a B2BUA. It then 
> handles all 
> > the harder stuff.
> > 
> > But that isn't the point of the draft. It is trying to define an 
> > environment that doesn't require servers in the cloud to handle the 
> > hard stuff.
> > 
> >> I don't see a reason emergency calls cannot be supported with the 
> >> tools listed in the document.
> > 
> > If you have nothing between you and the PSAP then you are going to 
> > need more.
> > 
> >> I think it would help us a lot if you define "what are 
> required to be 
> >> universally deployable".
> > 
> > A point of *my* comments was that the draft itself wasn't entirely 
> > clear about what it was asserting these tools are capable of 
> > providing. I think it is insufficient to say "these tools are 
> > sufficient" without stating *what* they are sufficient for.
> > 
> > Thanks,
> > Paul
> > _______________________________________________
> > RAI mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rai
> 
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
> 
_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai

_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai