[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Eunsoo Shim wrote:

On Wed, Oct 22, 2008 at 7:57 AM, DRAGE, Keith (Keith)
<drage at alcatel-lucent.com> wrote:

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.


Both.


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.



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


Eunsoo


-----Original Message-----
From: Eunsoo Shim [mailto:eunsooshim at gmail.com]
Sent: Tuesday, October 21, 2008 9:34 PM
To: Paul Kyzivat
Cc: DRAGE, Keith (Keith); Jiri Kuthan;
draft-sinnreich-sip-tools at tools.ietf.org; rai at ietf.org;
sipping-chairs at tools.ietf.org
Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03

On Tue, Oct 21, 2008 at 2:19 PM, Paul Kyzivat
<pkyzivat at cisco.com> wrote:


Eunsoo Shim wrote:


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.

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






_______________________________________________
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