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

[Jiri Kuthan <[e-mail]>]

That's again the question of the scope. I'm sure that there are
organizations that would be publishing profiles for some country-
specific regulation-compliant phones. I'm peresonally more interested
in a techniucal profile for making a simple phone call on the Internet. (and
leave 911, choking hazards, ergonomical compliance, national
safety requirements, and many other important aspects to other profiles).
Of course such a profile should not raise expectation it delivers
more than it does.

-jiri

Henry Sinnreich wrote:
> 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
> 
_______________________________________________
RAI mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rai