Subject: [Iptel] AW: Calling Party's Category

From: "Jesske, R" <[email-masked]>
Date: Wed, 1 Dec 2004 07:27:54 +0100

Dear Tom, all,
I see there are several questions with regard to the CPC. Our approach is to use it for billing, charge info and routing purposes.

Payphone:
1. Payphone Calls are routed in an other manner than normal calls
2. Payphone Calls are billed differently compared with normal calls
3. The charge information shown to the user of the payphone is an other than for normal once
4. Based on the CPC a blocking of numbers (e.G premium rate or special destinations) can be performed
5. Special accounting mechanisms for free phone numbers are possible

A question was how to perform security and trust. Using the CPC within the P-Asserted-ID makes this information trusted. The UA can advice with the P-Preferred-ID that the SIP Proxy should use the proposed URI as P-Asserted-ID. But Proxy verifies this information. If the Information in the Hint is not correct the dialog will be candled or the stored ID will be provided by the network.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Tom Taylor [mailto:[email-masked]]
Gesendet: Dienstag, 30. November 2004 19:51
An: Nguyen, An
Cc: [email-masked]; [email-masked]; Jesske, Roland
Betreff: Re: [Iptel] Calling Party's Category

Jonathan, I hope I am stating this correctly.

The Chair's proposal at the meeting was that this draft be dropped, because with 
SIP-T defined, there is no need to define other means in SIP to carry signalling 
destined specifically to the PSTN.  However, if use cases can be provided which 
demonstrate a requirement to be met in the pure SIP environment, work can be done 
(probably in SIPPING) to meet those requirements.

Nguyen, An wrote:
> Mr. Taylor;
> 
> I am just curious ... What is the status of the Internet Draft?
> 
> An
> 
> 
[snip]

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Dec 2004 09:45:55 -0500

Just curious - what does it take to get a CPC code point allocated? If 
the IETF is to put this into SIP somehow, this issue will undoubtedly 
come up (as it did in spades for ENUM).

So, let's assume I want to have a CPC called "Bordello", with the 
following characteristics
- Calls to normal destinations are allowed and billed to the associated 
subscriber account
- Calls to the police are blocked
- Incoming calls are diverted to a sexy autoattendant.
- Calls to residences of known customers (provisioned by bordello 
owner) are anonymized, or alternatively obfuscated with a location 
header showing the origin is elsewhere.

The following questions obtain:
a) who allocates the "Bordello" codepoint?
b) what is the scope of the allocation?
c) where are the semantics documented (e.g. RFC, part of registration, 
etc.)
d) how does it interact with other call handling related functions?

this is beginning to look suspiciously like the "Namespace" discussion 
with respect to resource-priority, isn't it?

After thinking about this some more, I feel even more strongly along 
the lines Jon Peterson suggested - don't put this into SIP; instead 
deal with it as a role assertion through a SAML document provided as 
part of the (enhanced) identity work when we get around to it.

This comprises yet another use case for SAML (besides delegation) which 
may argue for our being more aggressive about moving this forward right 
on the heels of the identity work. Anyone want to tackle this with an 
i.d.?

Dave.

On Dec 1, 2004, at 1:27 AM, Jesske, R wrote:

> Dear Tom, all,
> I see there are several questions with regard to the CPC. Our approach 
> is to use it for billing, charge info and routing purposes.
>
> Payphone:
> A question was how to perform security and trust. Using the CPC within 
> the P-Asserted-ID makes this information trusted. The UA can advice 
> with the P-Preferred-ID that the SIP Proxy should use the proposed URI 
> as P-Asserted-ID. But Proxy verifies this information. If the 
> Information in the Hint is not correct the dialog will be candled or 
> the stored ID will be provided by the network.
>
> Best Regards
>
> Roland
>
>
>
>
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Dec 2004 15:45:11 -0500

On Dec 1, 2004, at 3:21 PM, James M. Polk wrote:

> At 09:45 AM 12/1/2004 -0500, David R Oran wrote:
>> ....this is beginning to look suspiciously like the "Namespace"  
>> discussion with respect to resource-priority, isn't it?
>>
>> This comprises yet another use case for SAML (besides delegation)  
>> which may argue for our being more aggressive about moving this  
>> forward right on the heels of the identity work. Anyone want to  
>> tackle this with an i.d.?
>
> How would this new ID idea be different than:
> http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ?
>
> The above is the answer doc to the requirements ID we authors have  
> been kinda dragging out feet about revving at:
> http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz 
> -00.txt
> but we think is essentially done once revved.
>
I agree.

>
>> Dave.
>
>
> cheers,
> James
>
>                                *******************
>                 Truth is not to be argued... it is to be presented
>
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Dec 2004 15:45:11 -0500

I agree.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 01 Dec 2004 14:21:56 -0600

At 09:45 AM 12/1/2004 -0500, David R Oran wrote:
>....this is beginning to look suspiciously like the "Namespace" discussion 
>After thinking about this some more, I feel even more strongly along the 
>lines Jon Peterson suggested - don't put this into SIP; instead deal with 
>it as a role assertion through a SAML document provided as part of the 
>(enhanced) identity work when we get around to it.
>
>may argue for our being more aggressive about moving this forward right on 
>the heels of the identity work. Anyone want to tackle this with an i.d.?

The above is the answer doc to the requirements ID we authors have been 
kinda dragging out feet about revving at:
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz-00.txt
but we think is essentially done once revved.

cheers,
James

                                *******************

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Dec 2004 23:24:01 -0500

> 1. Payphone Calls are routed in an other manner than normal calls

In what way are they routed differently?

> 5. Special accounting mechanisms for free phone numbers are possible

I think its also worth pointing out that the general topic of 
"payphones" in sip is a complicated one, of which the cpc aspect - 
asserting the trait of being a payphone - is one of the easier ones. 
Figuring out a way to do the payments securely is a much more 
challenging issue.

I also wanted to note that if there are requirements for endpoint 
assertion of characteristics and capabilities, we have a spec for that 
too - namely rfc3840. The usage of SAML for doing the network asserted 
traits also seems right to me.

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