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

[Henry Sinnreich <[e-mail]>]

Thanks Brian for making this point.

>the problem that the location isn't sent
> unless the endpoint recognizes that the call it is placing is an emergency
> call; 

Would an emergency call button on the SIP UA be OK?
In this case, the emergency call could also carry the location and possibly
other information as well. I will make sure to read the BCP.

Henry


On 10/22/08 6:37 AM, "Brian Rosen" <[e-mail]> wrote:

> 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