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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Oct 2008 09:12:19 -0400

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.

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.

The document does make a start at this. Section 3 says:

    SIP applications in the endpoints can however accomplish most
    telephony functions as well. This has been well documented in SIP
    related work in the IETF, such as:

   o "A Call Control and Multi-party usage framework for SIP" [13] ...
   o "SIP Service Examples" [14] ...

The two referenced documents do enumerate a set of features/services.
They also illustrate how to realize those using sip. But they do not
make a case that this set of services is either necessary or sufficient
for any particular environment. And not all of them can be accomplished
with the nine standards selected in this document. I didn't do an
exhaustive study, but among the additional standards needed to
accomplish all of those services are:

- RFC3857 (watcherinfo)
   (Referenced from RFC3856}

- RFC3515 (REFER), RFC3891 (Replaces)
   (referenced from service-examples [14],
    used for MoH, transfer, park, click to dial)

- RFC4235 (Dialog evt pkg)
   (referenced from service-examples,
    only used (I think) for rendering tag!)

- RFC4579 (CC)
   (referenced from service-examples,
    only for description of use of isfocus tag!)

- 3911 (Join)
   (referenced from draft-ietf-sipping-cc-framework-10 [13])

- draft-ietf-sip-answermode-07
   (referenced from draft-ietf-sipping-cc-framework-10.)

I can't decide which conclusion to draw from this:
- the list of required RFCs accidentally omitted these.
- the services that use these aren't considered essential
- the services that use these can be done some other
   way (unspecified) that doesn't require these.

I suspect that all of my concerns above could be resolved by adding some
additional text to the document and possibly by adding a few additional
required documents to the existing set of nine.

Security Concerns:

For security, this draft has called for the use of sips URIs and TLS for
sip signaling security, but with only 3261 for the definition of SIPS.

I believe there is a problem here because the use of the sips URI to
provide signaling security is underspecified in RFC 3261. There is work
in progress to improve on this situation: draft-ietf-sip-sips-08.
Without that there does not seem to be a good security solution here.

For identity, RFC 4474 is specified. However RFC 4474 requires an
Authentication Service. This draft seems to eschue the use of external
servers. The alternative seems to be for the UAC to act as its own
authentication service, which is allowed by RFC 4474. However that
requires that the UAC be able to obtain its own certificate, which in
turn requires it to have its own domain name. These may be hurdles that
are too high for many UAs to surmount. If this is intended as a
prerequisite for the use of this tool set then it would be good to spell
that out in detail.

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.

The Hitchhiker's Guide intends to point out documents of relevance to
sip implementors, but it is much more expansive. I expect one of the
motivations for this document is the daunting extent of the list
presented in the Hitchhiker's Guide. So, if the intent of this document
can be realized it won't conflict with the Hitchhiker's Guide.

Since this document currently only references other sipping documents
for examples of  feature definition, I don't think a conflict with Bliss
will occur unless Bliss does something in conflict with those examples.
This is perhaps best sorted out after this document gets more specific.
But for now I'm not concerned.

	Thanks,
	Paul Kyzivat

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

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 17 Oct 2008 20:40:11 +0200

> 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.)

> - 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?

[...]

> conflict, I think it would most likely be with the Bliss WG, or perhaps

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2008 17:23:02 -0400

> necessary. (necessary==one will not be able to make a basic

Well, I don't know about the politics of using the term "profile".
Certainly there are lots of sip profiles being made - most of them not 
by the ietf. So if there is value in this one, then it becomes a matter 
of whether it gets published by ietf or somewhere else.

> Do folks think that's the appropriate scope?

I don't think it is what Henry had in mind.
And its not very interesting to me either.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 18 Oct 2008 14:50:34 +0200

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.

-	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.

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?

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: Friday, October 17, 2008 7:40 PM
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03
> 
> Paul Kyzivat wrote:
> > 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.
> "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.
> > 
> > be constructed using this small set of "tools". There are 
> three parts 
> > to
> > that:
> Actually consumer VoIP is just that, only without the security part.
> 
> > conflict, I think it would most likely be with the Bliss WG, or 
> > perhaps the Hitchhiker's Guide.
> 
> scope. (As said, I consider basic call with security a good choice.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 11:56:11 -0400

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

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Oct 2008 11:27:41 -0500

Paul,

> Many (most?) deployments work in
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"

>> 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.

> 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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 21 Oct 2008 18:30:21 +0200

See below

Keith 

> From: Eunsoo Shim [mailto:[email-masked]] 
> Sent: Tuesday, October 21, 2008 4:08 PM
> To: DRAGE, Keith (Keith)
> Cc: Jiri Kuthan; Paul Kyzivat; 
> [email-masked]; [email-masked]; 
> On Sat, Oct 18, 2008 at 8:50 AM, DRAGE, Keith (Keith) 
> <[email-masked]> wrote:
> > I don't have a problem with people creating profiles, but 
> as so much 
> > of SIP is about:
> >
> > Any profile should make clear the applicability of the proposed 
> > profile, and this document falls short in a number of manners.
> >
> > 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. 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.

> > 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 
> > 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.

> Thanks.
> Eunsoo
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Jiri Kuthan
> >> 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.
> 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.)
> >>
> >>
> >> >
> >> 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.)
> >>
> --
> Eunsoo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 13:03:59 -0400

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

More inline.

Thanks.

> 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.

> 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.

> 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???

> 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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 21 Oct 2008 19:13:34 +0200

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

> Behalf Of Henry Sinnreich
> Sent: Tuesday, October 21, 2008 5:28 PM
> To: Paul Kyzivat; Eunsoo Shim
> > this way - the (dumb) phones connect to a B2BUA. It then 
> handles all 
> > the harder stuff.
> * I also don't suppose you support SIP networks based on 
> B2BUA to handle "harder stuff"
> 
> Eunsoo Shim 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.
> 
> > 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.
> 
> 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
> 
> certainly by 
> >> 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.
> > 
> > this way - the (dumb) phones connect to a B2BUA. It then 
> handles all 
> > the harder stuff.
> > 
> > environment that doesn't require servers in the cloud to handle the 
> > hard stuff.
> > 
> > If you have nothing between you and the PSAP then you are going to 
> > need more.
> > 
> > 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

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Oct 2008 12:32:23 -0500

> this be expanded to include sipping?

Sure, please go ahead.

Henry

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 21 Oct 2008 12:53:44 -0500

Just to be clear, Paul said he was MOVING the thread to SIPPING, and has 
already done so (thank Paul for not cross-posting)...

Thanks,

Spencer

----- Original Message ----- 
From: "Henry Sinnreich" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Eunsoo 
Shim" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 21, 2008 12:32 PM
Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03

>>>> clear
>>>> hard
>>>> clear

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Oct 2008 13:16:36 -0500

>>> this be expanded to include sipping?

It says "expanding", not "moving".

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 14:19:39 -0400

Eunsoo Shim wrote:

>> 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.

Hmm. Are you then saying that these tools are sufficient to develop a UA 
for attachment to Vonage and Comcast? I never would have gotten that 
from reading it.

And I'm surprised. AFAIK neither Vonage nor Comcast support attachment 
of third party sip devices to their networks - only the ones they 
supply. (Or am I out of date regarding their policies?)

	Thanks,
	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 21 Oct 2008 22:07:40 +0200

>>>> Surely this is something that should be explicitly said in

I wholeheartly agree that a profile is a useful thing as long as
its scope is defined, which includes a proactive definition of what's
out of scope as well. If we do this, as I would like to, keeping
a minimalistic scope (==basic call) seems interesting -- we have
already too many things that are bigger than that.

> 
> 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.

agreed!

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

agreed too. I prefer "simple".

one of the questions to me is what granularity it should be aiming at.
Per-RFC granularity could be in fact too coarse -- as an example,
GRUU instance is is certainly massively importnat, which cannot be
said of the rest.

-jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Oct 2008 15:18:47 -0500

> To use 911 or similar numbers you are assuming the use of RFC 3966 which

Both are correct and need to be added. Thanks for catching it!

>(because it puts the mapping

Good points as well that we need to state explicitly.

Thanks, Henry

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 21 Oct 2008 22:32:28 +0200

> with something that has to be admired for it's beauty rather than its

Actually usefulness is to an extent function of deployability, which is to
an extent function of simplicity. Thus defining the simple thing if not
simplest seems useful to me. If some enterprise community has desires
for roaming features, it is certainly welcome to write "enterprise
community profile for roaming feature", but that should be kept away
from a minimalistic profile, which is labeled as such.

Well, it is true that one could go too far with it too -- how about
profile of SIP with only INVITE in it? (like in the sip-0? draft) :)
a bit vaguely basic call seems as scope quite right to me, including
SIP, NAT, RTP, DNS, and Security (privacy and authenticity).

-jiri

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 21 Oct 2008 17:30:23 -0500

Thanks Jiri again!

Henry

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 22 Oct 2008 01:09:21 +0200

Well -- I don't think I deserve any thanks, the point is apparent to me that
some ways to find simplicity are overdue. We hear it from both guys on
the learnig curve (our students, and new hires) as well as, which worries
me even more, customers actually running SIP.

One can possibly consider it an education matter -- but with a bit of
protectionisms I think it is useful to provide a quick start to
learners and User Agent builders.

-jiri

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 22 Oct 2008 13:57:38 +0200

So is this list of supported RFCs just what appeared on the data sheet, or did you actually look at the SIP signalling sent to see what was included.

I'd quite happily implement and claim RFC 3261, but if a header in some other document proved useful to a function I wanted to perform, I'd add it to the implementation but not necessary claim conformance to that other RFC in the published documentation, particularly if I only implemented half of it, and therefore only conformed to half.

Keith 

> Sent: Tuesday, October 21, 2008 9:34 PM
> To: Paul Kyzivat
> Cc: DRAGE, Keith (Keith); Jiri Kuthan; 
> On Tue, Oct 21, 2008 at 2:19 PM, Paul Kyzivat 
> <[email-masked]> wrote:
> >
> >
> > Eunsoo Shim wrote:
> >
> > Hmm. Are you then saying that these tools are sufficient to 
> develop a 
> > UA for attachment to Vonage and Comcast? I never would have gotten 
> > that from reading it.
> >
> What I said was that Vonage and Comast request the end users 
> to register the location (the address) of the phone adapter 
> for emergency call purpose.
> 
> Regarding your question whether the tools are sufficient for 
> a UA to be used in Vonage or Comcast, what I can say is that 
> the manufacturer's specification of some of the phone 
> adapters for the VoIP providers lists only a few SIP RFCs.
> You can check the specifications of phone adapters in the 
> market. A large manufacturer implemented just RFC 3261, 3262, 
> 3263, and 3264 (and SDP). Another manufacturer implemented 
> just RFC3261 and SDP!
> 
> 
> > of third party sip devices to their networks - only the 
> ones they supply.
> 
> You are right.
> But I guess they just configured the phone adapters and 
> locked them but did not have the adapters custom-developed 
> with more RFC support.
> 
> 
> Thanks.
> --
> Eunsoo
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 10:36:46 -0400

Eunsoo Shim wrote:
> On Wed, Oct 22, 2008 at 7:57 AM, DRAGE, Keith (Keith)
> Both.
> I doubt any manufacturer would not list RFCs they implemented unless
> it is omitted by mistake.
> 
> The RFC list implemented in a phone adapter is from one of the largest
> VoIP product manufactures, one employer of many folks active in the
> IETF. Instead of asking me, you can check the specs of phone adapters
> in the market easily.

Hmm. I wonder who that might be? :-)

I have been through these exercises of deciding what RFC support to 
claim in a product spec. (Not for a product like that above.) Given that 
there aren't any formal certifications of conformance to RFCs this is 
all subjective. But I don't think it would be normal to claim support 
for an RFC if just a tiny part of it were implemented. In reality it 
pretty much impossible to claim support for RFC 3261 as a whole. Any 
given product at best supports it in a certain *role* or a few roles, 
but not all the roles that are defined. Such nuances are typically 
omitted from claims.

While I have not been close to the development of such products, its my 
impression that this is in practice a sort of negotiation. Features get 
implemented as they are required by a customer. So the phone device and 
the server it connects to get matching sets of features.

As much as some of us dislike it, most of the focus has been on B2BUA 
feature servers in the network managing phone devices that have little 
feature support of their own, and hence are relatively dumb. This is 
especially the case for phone adapters, where the user interface 
restricts how features can be implemented. So for instance it is 
incorrect to say that you can implement emergency services in the phone 
adapter using just the specs listed in sinnreich-sip-tools. The 
emergency services are actually implemented in the server, based on the 
user dialing 911. The adapter has no idea there is an emergency call. 
And because of that, the full set of requirements are not met. (E.g. 
preventing hangup.)

So, it is indeed true that you can implement a UA that can work with 
such a server while only following a small number of RFCs. But that then 
makes you dependent on the server to do all the good stuff. If you want 
to follow that approach to implement a fancier device that supports a 
richer set of features you will find that you are painted into a corner. 
The server you must connect to may well prevent you from doing the 
things you want. And if you want to just provide a better UI to an 
existing feature (e.g. transfer) then you must implement it by 
transforming to the mechanism the server normally uses to signal it 
(e.g. sending an INVITE with a "start-code" URI.) And the details of 
that are dictated by the server provider, not an RFC.

	Thanks,
	Paul

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 21 Oct 2008 11:08:10 -0400

> 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.

Thanks.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 21 Oct 2008 13:52:58 -0400

> 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.

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 21 Oct 2008 16:33:39 -0400

On Tue, Oct 21, 2008 at 2:19 PM, Paul Kyzivat <[email-masked]> wrote:
> Hmm. Are you then saying that these tools are sufficient to develop a UA for
> attachment to Vonage and Comcast? I never would have gotten that from
> reading it.
>
What I said was that Vonage and Comast request the end users to
register the location (the address) of the phone adapter for emergency
call purpose.

Regarding your question whether the tools are sufficient for a UA to
be used in Vonage or Comcast, what I can say is that the
manufacturer's specification of some of the phone adapters for the
VoIP providers lists only a few SIP RFCs.
You can check the specifications of phone adapters in the market. A
large manufacturer implemented just RFC 3261, 3262, 3263, and 3264
(and SDP). Another manufacturer implemented just RFC3261 and SDP!

> And I'm surprised. AFAIK neither Vonage nor Comcast support attachment of
> third party sip devices to their networks - only the ones they supply.

You are right.
But I guess they just configured the phone adapters and locked them
but did not have the adapters custom-developed with more RFC support.

Thanks.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 22 Oct 2008 10:01:58 -0400

Both.

Eunsoo

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 22 Oct 2008 07:37:04 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE,
Keith (Keith)
Sent: Tuesday, October 21, 2008 1:14 PM
To: Henry Sinnreich; Paul Kyzivat; Eunsoo Shim
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03

 

Regards

Keith

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 22 Oct 2008 17:06:21 -0500

Thanks Brian for making this point.

>the problem that the location isn't sent
> 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

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 23 Oct 2008 00:17:57 +0200

> supply. (Or am I out of date regarding their policies?)

I would be surprised if any  provider did filter messages based on 
User-Agent
header field and decline requests from unsupported ones -- with all 
operations
I'm familiar with this is not the case. Support for other equipment is
a different thing though -- I think it is quite understandable that the
companies are not interested in spending effort on supporting equipment
they are not familiar with.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 23 Oct 2008 00:21:58 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 18:29:57 -0400

Jiri Kuthan wrote:
>> Hmm. Are you then saying that these tools are sufficient to develop a 

I don't see much future in targeting the development of devices that are 
intended to connect to servers that don't willingly accept them. Perhaps 
there aren't checks for User-Agent. But I think Comcast devices may be 
configured remotely based on mac address. And last I knew Comcast was 
using MGCP phones, not SIP. I presume that will change eventually, but I 
haven't seen any evidence that they plan to support devices they don't 
deploy. You would have to reverse engineer based on sniffing the 
protocol to figure out how to set up another device to connect to them. 
And then they would probably cancel your service as soon as they noticed 
anything funny.

It would probably be easier to connect to Vonage but again you would be 
swimming up stream. OTOH I know there are other service providers that 
are more flexible about what they allow to connect.

But the bottom line here is whether this sort of usage is in scope or 
not for sip-tools. From what Henry says, it is out of scope.

	Thanks,
	Paul