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

["Eunsoo Shim" <[e-mail]>]

>> On Sat, Oct 18, 2008 at 8:50 AM, DRAGE, Keith (Keith)
>> <[e-mail]> wrote:
>> > I don't have a problem with people creating profiles, but
>> as so much
>> > of SIP is about:
>> >
>> > "I need to do this and therefore need to deploy this extension"
>> >
>> > Any profile should make clear the applicability of the proposed
>> > profile, and this document falls short in a number of manners.
>> >
>> > -       For example, at least certain regulators have a
>> view that if it
>> > looks and behaves like a phone, it must be able to make an
>> emergency
>> > call. Now the document does not reference any of the IETF work
>> > concerning how SIP phones should make emergency calls, and there is
>> > another pointer that says any considerations for
>> interworking with the
>> > PSTN are irrelevant - virtually all PSAPs are PSTN
>> connected at this
>> > time, therefore I assume that emergency calls are not supported.
>> > Surely this is something that should be explicitly said in
>> a profile.
>> >
>>
>> 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.
>>
>> I don't see a reason emergency calls cannot be supported with
>> the tools listed in the document.
>>
> Which VOIP service providers, and by what mechanism.

Vonage and Comcast. I am sure there are more.
By the mechanism I described briefly in the above.

> IETF has defined ecrit-phone-bcp as a package that should be used for emergency calls
> (including the service URN set to "sos" usage), and you are now recommending that that
> package is undesirable and should be ignored.
>

Not at all.
What I am saying is that there are existing deployments supporting 911
while implementing a limited set of RFCs and thus it is not correct to
say the draft does not supper emergency calls. I am not making any
recommendation about ecrit-phone-bcp. I am sure it is useful and
better in many deployment cases.

>> > -       I would also question some of the security
>> selections. They may
>> > work but they currently will not allow you to deploy your
>> SIP device
>> > in any universal sense. In order to communicate with SIP at present
>> > (at least to receive calls), someone has to provide a
>> registrar. This
>> > profile does not use P2PSIP. You will need to meet the security
>> > requirements of whoever you select to deploy that registrar
>> in order
>> > to register. That may well not be the set in this profile.
>> >
>>
>> I am sure a commercial deployment of VoIP services is
>> feasible with the security tools supported in the document.
>> It may not be sufficient for everyone. If you mean by
>> "universal sense" that it should be sufficient for everyone,
>> right, the document does not pursue it. I think actually that
>> is one of the points of the document - don't try to satisfy everyone.
>>
>> > So I guess that we have a profile for a device that in the current
>> > sense would not be universally deployable, yet even the enterprise
>> > community is now telling me how important the ability of enterprise
>> > end devices to roam into other networks is, which
>> predicates some sort
>> > of wider deployability. So how is this profile useful in
>> that sense.
>> > Do we end up with something that has to be admired for it's beauty
>> > rather than its general usefulness?
>> >
>>
>> I think it would help us a lot if you define "what are
>> required to be universally deployable".
>
> There was a direct connection between these paragraphs. It seems essential to me that you are able to register with a provider of a registrar. That registrar will specify security mechanisms to be used. Those security mechanisms may not be the same set specified in this document. You are essentially specifying TLS for SIP signalling using TCP and DTLS otherwise (by the way which RFC defines the setting of the transport parameter for the latter?). Neither of these are universally deployed even if they are implemented.
>
> For roaming, you may well find an outbound proxy (for at least registration) which needs to be involved in your security solution as well.
>
> You are essentially working with the restriction that you can only deploy your phone and receive incoming calls if your registrar (and any proxiess that handle the registration request) deploy your particular set of security solutions.
>
>

I think we should avoid using the word 'universal' here unless it can
be defined.

The draft tries to identify a limited set of basic tools but not to
cover all the tools to support every possible deployment scenario.

Thanks.

Eunsoo
>
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of
>> >> Jiri Kuthan
>> >> Sent: Friday, October 17, 2008 7:40 PM
>> >> To: Paul Kyzivat
>> >> Cc: [e-mail]; [e-mail];
>> >> [e-mail]
>> >> Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03
>> >>
>> >> Paul Kyzivat wrote:
>> >> > Draft: draft-sinnreich-sip-tools-03
>> >> > Reviewer: Paul Kyzivat
>> >> > Review Date:
>> >> > Review Deadline:
>> >> > Status: Expert Review
>> >> >
>> >> > Review Summary:
>> >> >
>> >> > I'll start by saying that the concept behind this draft is
>> >> attractive:
>> >> > that a relatively small number sip RFCs are sufficient
>> to provide a
>> >> > rich and functional communications environment.
>> >>
>> >> I'm just curious how folks think abot calling it by the
>> right name,
>> >> which is standard profiling. I mean many IETF participants have
>> >> actually negative sentiment towards it ("we do things
>> simple thus we
>> >> don't need profiles"). Nevertheless SIP is not simple and
>> an effort
>> >> to highlite essentials seems very important to me.
>> >> To some extent the galaxy draft does that (I like it tries to
>> >> "weight" many references by relevance), but I'm seeking
>> really some
>> >> galaxy-light, which only referse to pieces which are necessary.
>> >> (necessary==one will not be able to make a basic call
>> without them.)
>> >>
>> >>
>> >> >
>> >> > However, I remain unconvinced by the document as
>> written. While I'm
>> >> > not convinced that the document is wrong about the
>> >> sufficiency of this
>> >> > set of tools, I don't find enough meat in the document to
>> >> convince me
>> >> > it is right.
>> >> >
>> >> > Following are more detailed comments.
>> >> >
>> >> > Sufficiency of these Tools:
>> >> >
>> >> > For the document to convince me of its utility, it needs to
>> >> provide an
>> >> > existence proof that a "sufficient" set of basic
>> >> features/services can
>> >> > be constructed using this small set of "tools". There are
>> >> three parts
>> >> > to
>> >> > that:
>> >> > - enumerate a set of basic features/services
>> >> > - make a case that they are "sufficient"
>> >> > - show that they can be constructed using this small set
>> of tools.
>> >>
>> >> I think this shall be about basic call with security, period.
>> >> Actually consumer VoIP is just that, only without the
>> security part.
>> >>
>> >> Do folks think that's the appropriate scope?
>> >>
>> >> [...]
>> >>
>> >> > Possible Overlap with Current or Planned Chartered Work:
>> >> >
>> >> > I'm not sure if this is a valid concern for this kind of
>> >> document, but
>> >> > its worth considering. At the moment I don't think so. If
>> >> there were a
>> >> > conflict, I think it would most likely be with the Bliss WG, or
>> >> > perhaps the Hitchhiker's Guide.
>> >>
>> >> I see this as a subset to the galaxy draft, whose purpose to to
>> >> define an absolute minimium needed to achieve certain scope. (As
>> >> said, I consider basic call with security a good choice.)
>> >>
>> >> With that, I think this would be an excellent help for
>> implementers
>> >> and whoever is learning SIP.
>> >>
>> >> -jiri
>> >>
>> >> _______________________________________________
>> >> RAI mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/rai
>> >>
>> >
>>
>>
>>
>> --
>> Eunsoo
>>
>



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