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

From: "Haluska, John J" <[email-masked]>
Date: Thu, 6 Jul 2006 12:38:42 -0400

Jonathan

Thanks very much for taking  the time to look at and  comment on this
draft.

The DA provider needs to brand the service, which includes things like
providing customized announcements, based on the VOIP provider identity.
The billing, though, is based on the aggregation provider identity, So
it's crucial that these are separately identifiable.

We will definitely look at the SAML-CPC draft, thank you for pointing
this out.

The SS7 versus MF indication would be needed for cases of PSTN
interworking - perhaps the draft was not clear that this case also needs
to be supported. If access to the DA provider is via MF (via a gateway),
then the set of features available might be limited or different, so
it's important to know this.

Thanks again for your comments.

John Haluska

 

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

Jdrosen wrote:

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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 14:11:54 -0400

inline.

Haluska, John J wrote:

> it’s crucial that these are separately identifiable.

OK, thanks for clarifying. That makes some sense. I'd suggest that the 
domain name in the P-Asserted-ID is probably what you want. TLS mutual 
auth would provide the identity of the previous hop provider, which 
might be the same thing.

> interworking – perhaps the draft was not clear that this case also needs 
> it’s important to know this.

Well, any such 'features' are exposed through SIP anyway, so the fact 
that its SS7 vs. MF is really irrelevant. You need to identify the 
specific functions you want access to, determine what SIP extensions 
provide those functions, and then look for the option tags that a 
gateway would insert to indicate whether its allowed. For example if you 
want to transfer a call via REFER, the gateway would insert Allow: REFER 
if it can receive a REFER for transfer.

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