Subject: [Sipping] comments on draft-haluska-sipping-directory-assistance-00

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 23:28:42 -0400

The draft spends a bunch of time talking about how to identify the 
various providers involved in the call. Various options are called out 
on which headers can be used to carry this. However, the solution that 
seems right to me has been omitted - mutual TLS authentication. In the 
model where the VoIP provider talks to the directory assistance 
provider, mutual TLS authentication between proxies gives each side the 
identities that are needed.

The mutual TLS auth runs into troubles if there is an intermediate SIP 
provider. You have introduced a requirement for an aggregation provider 
of some sort, which sits between the voip provider and the directory 
assistance provider. These kinds of clearinghouse/middleman providers 
are common in voip, but you have introduced a requirement that the DA 
provider still knows the identity of the voip provider (for billing 
purposes) even when there is a middleman operator in the loop. That 
seems odd to me.

For originating station type, work is underway on using security 
assertions to convey endpoint attributes. See 
http://www.ietf.org/internet-drafts/draft-schubert-sipping-saml-cpc-01.txt 
for example. Network type would come through this vehicle also based on 
your description.

You introduce a requirement for knowing whether a call arrives via ss7 
or MF. This is clearly meaningless in a pure SIP environment. If a call 
arrives via a gateway and is then converted to SIP, it would be lost. 
Why do you need to know though in this case?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.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: Thu, 6 Jul 2006 06:13:41 -0700

Jonathan's comments are right on the mark and I would add we live
probably in different worlds.
 
I would promptly cancel my VoIP service that dares to list my SIP URI or
VoIP phone number. As for the Yellow Pages, Google is doing a better
job.

Also, clearing houses for free VoIP? :-)

So what's the motivation to burden SIPPING with even more overload?

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 10:29 PM
To: IETF Sipping List
Subject: [Sipping] comments on
draft-haluska-sipping-directory-assistance-00

For originating station type, work is underway on using security 
assertions to convey endpoint attributes. See 
http://www.ietf.org/internet-drafts/draft-schubert-sipping-saml-cpc-01.t
xt 
for example. Network type would come through this vehicle also based on 
your description.

Thanks,
Jonathan R.

---

From: "Haluska, John J" <[email-masked]>
Date: Thu, 6 Jul 2006 13:17:50 -0400

Henry

Thanks for taking the  time to comment. 

We don't want to tell the VOIP subscribers that they can no longer
access the same  directory assistance services they are used to by
calling a well known number, but rather need to launch a browser. In
some cases it does make sense to use e.g. Google, but in other cases
it's extra effort when they could just dial the DA service they way they
always have. Those DA services are also becoming more advanced even
today. E.g. if the customer wishes, they can have a coupon for the
restaurant whose listing they just  called about sent via SMS to their
cellphone. Or, they might be able to get connected to a directions
service guiding them verbally  to get to that restaurant. SIP-enabling
DA providers will open up a whole new set of services which can be
offered - multimedia, etc. 

This is a different issue from listing the VOIP subscriber's URI. It is
allowing the VOIP subscriber to access the same DA services that others
can. 

As  Jonathan pointed out, such clearinghouses do exist, this is a fact
that DA providers are faced deal with. I am not sure we are both talking
about _free_ VOIP, though I'm not sure there is any technical reason why
users of free VOIP services would  not be  able to access such DA
services. 

The intent of this work is to allow DA service providers to become
SIP-enabled so that they can natively service VOIP subscribers (while
continuing to service PSTN subscribers), and so that they can offer new
exciting services using SIP that cannot be  easily done using the more
limited PTSTN-type interfaces currently available. This is not about
simply mimicking the existing PSTN service. Being able to do so is a
requirement, and is what the draft currently focuses on, as DA providers
don't want  to lose existing capabilities  in moving to SIP.

Thanks again for your comments.

John Haluska

==================================================

Henry Sinnreich wrote:

job.

Thanks, Henry