Re: [Sipping] draft-sinnreich-sip-tools-03 - expanding-not moving

[Henry Sinnreich <hsinnrei at adobe.com>]

>>> I'm not changing the recipient list, but its pretty restricted. Should
>>> this be expanded to include sipping?

It says expanding, not moving; so it's not with my agreement.

The discussion of services in the endpoints vs. "in the network" is central
to SIP and its related WGs IMO, though this is the decision of the owners of
the lists. 

The discussion is helpful to the authors either way.
It would not be fair to SIP users to be left with the impression that in can
work _only_ "in the network" - legacy telephony style.

Henry


On 10/21/08 12:43 PM, "Paul Kyzivat" <pkyzivat at cisco.com> wrote:

> We have been discussing this on the rai list, but I think it might be
> more appropriate on the sipping list, so with Henry's permission I'm
> moving it here.
> 
> Paul
> 
> Henry Sinnreich wrote:
>> 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.
> 
> Thanks.
> 
>> * 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.
> 
> This presumes the phone can *get* its location in the correct form.
> Aren't there more standards that are needed to sort that out?
> Also, the emergency services folk, and the governmental agencies, have
> all sorts of rules about the behavior of the device when making an
> emergency call. If the device being constructed is subject to such
> rules, then more standards are required.
> 
>>> 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.
> 
> Its great that *more* can be provided. I'm just looking for the basic
> minimum that this tool set is supposed to enable. Without that, how can
> someone decide if this tool set is good for them?
> 
> I guess its possible to simply state: this is an interesting set that
> you might find useful. Take a look and see if it is sufficient for your
> needs before looking further. But I got the impression it was claiming
> more than that.
> 
>> 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.
> 
> Are you saying that these are done with just the set of standards
> mentioned in this draft???
> 
>> (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?
> 
> Perhaps, *if* you know for certain that those things can be accomplished
> with just this set of sip standards.
> 
> Thanks,
> Paul
> 
>> Henry
>> 
>> On 10/21/08 10:56 AM, "Paul Kyzivat" <pkyzivat at cisco.com> 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
>>> RAI at ietf.org
>>> https://www.ietf.org/mailman/listinfo/rai
>> 
>> 
> 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP