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

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

[I accidentally sent this to rai. trying again on the new thread.]

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.

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

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

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

The issue was about endpoints calling an emergency service.

Are you suggesting some service providers will block emergency calls from a
registered endpoint?

This is a different issue of what providers allow what fixed and mobile
devices on their networks.

Henry

---

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

> Are you suggesting some service providers will block emergency calls from a

I'm saying AFAIK they don't support any endpoints other than those they 
sanction registering in the first place. Maybe you can fake them into 
believing your device is legit, but probably they are trying to prevent 
you from that.

In case of Comcast, I'm assuming you mean Comcast voice service. 
Actually, I believe that isn't even SIP - its MGCP for the phones. Or if 
you mean the comcast network service, then I don't think it will provide 
any sip emergency services.

	Thanks,
	Paul

---

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

Paul,

I did not intend to go there, but since you bring it up, there are press
reports about Sprint and others preparing for an open wireless network and
Verizon opening their wireless network to large degree to various mobile
devices. (AT&T seems to be pretty open to my iPhone). I don't think this is
the place to discuss policies of specific service providers, just to make
the point they cannot be put all in the box of closed networks that exclude
innovative endpoints; for sure.

In the enterprise and most of all, on the Internet, there is also ample room
for endpoint features and services. In P2P SIP networks all features are in
the endpoints...

To make it clear: Our I-D does not exclude or even comment on network based
SIP services, but only shows the alternative of providing _rich_ services in
the endpoints as well, or even better in our opinion.

This is a good point probably to state explicitly in the I-D and thanks for
leading us to it.

Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 16:30:12 -0400

Henry,

Based on this discussion, it now sounds like you are heading in *two* 
directions:

- connecting to a SP that provides services (e.g. 911, maybe others,
   like voicemail, forwarding, ...)
   The SP in this case is largely looking for a "dumb" device and
   provides the services in the network. The "request for service"
   is then "tunneled" via simple services like invite, with the
   service request encoded in the AOR. (e.g. the "911", or "star" codes).
   In this case you are then competing with other profiles, such as
   SIPConnect or PacketCable.

- very low added value SP, that simple provides registration
   and routing. All services are provided by the UAs.

I'd like to see the goals spelled out better. Then we can discuss if 
they are met.

	Thanks,
	Paul

---

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

Thanks Paul!

> I'd like to see the goals spelled out better. Then we can discuss if

This looks reasonable.

>   and routing. All services are provided by the UAs.

More accurately: The richest applications in the opinion of the authors,
combined with RIA, etc. can be provided in the endpoints as an interesting
alternative for service providers. There is no reason why SIP endpoints
cannot also be designed to interact with existing VoIP infrastructure, but
this is beyond the scope of our I-D.

Thanks for helping to clear this up as well.

Henry

---

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)
> <[email-masked]> 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:[email-masked]]
>>> Sent: Tuesday, October 21, 2008 9:34 PM
>>> To: Paul Kyzivat
>>> Cc: DRAGE, Keith (Keith); Jiri Kuthan;
>>> [email-masked]; [email-masked];
>>> [email-masked]
>>> Subject: Re: [RAI] Expert review of draft-sinnreich-sip-tools-03
>>>
>>> On Tue, Oct 21, 2008 at 2:19 PM, Paul Kyzivat
>>> <[email-masked]> wrote:
>>>>
>>>> Eunsoo Shim wrote:
>>>>
>>>>>>> I don't see a reason emergency calls cannot be supported
>>> with the
>>>>>>> tools listed in the document.
>>>>>>>
>>>> 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
>>>
> 
> 
>