Subject: [Iptel] Calling Party's Category

From: Tom Taylor <[email-masked]>
Date: Wed, 01 Dec 2004 10:56:11 -0500

Summarizing the discussion to date:

1. It appears that a case has been made for work in the area of transmitting 
characteristics of the calling party in a call, as a basis both for decisions on 
what services to provide and to support charging policies.

2. An architectural framework is required to address the trust issues associated 
with the user's potential control over signalling content.

3. Suggestions have been made about the actual mechanisms that might be applied 
within such a framework.

This seems like a fruitful area of cooperation between the IETF and the ITU-T, 
with the latter defining the framework and requirements and describing the 
application of the mechanisms provided by the IETF.

-- 
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: "Jesske, R" <[email-masked]>
Date: Thu, 2 Dec 2004 07:56:33 +0100

The CPC in ITU-T/ETSI and the OLI in ANSI (Originating Line Identification) are well defined code points. I think IETF is also able to restrict definitions of code points used for routing aspects (Or Im Wrong?)

more comments in the text

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag von
> David R Oran
> Gesendet: Mittwoch, 1. Dezember 2004 15:46
> An: Jesske, Roland
> Cc: list iptel; [email-masked]'
> Betreff: Re: [Sip] AW: Calling Party's Category
> 
> 
> 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.

If I use a P-Asserted-ID (with regard to 3323+3323 a trust model is defined) the CPC will be provided by the network and should be secure and as I said this element is also used for routing purposes so the definition of new code points should be restricted. 
The concept described within draft-mahy-iptel-cpc-00 is to add the CPC as an element within the URI. From my point of view it could be also a normal header or P-header.
We see the need of such kind of mechanism and others too.
> 
> 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?

No. draft-ietf-sip-resource-priority-05 is addressing priority services. CPC is addressing other issues.

> 
> 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 could be used for billing services but not for routing from my understanding.

> 
> 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:
> > 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
> > 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]
> 
> 
> 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
>

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 9 Dec 2004 14:22:26 +0100

> -----Ursprungliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Donnerstag, 9. Dezember 2004 05:24
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Jesske, R wrote:
> Our approach is to use it for billing, charge info and 
> routing purposes.
> > 
> > Payphone:
> In what way are they routed differently?

One of our main issues is interoperability between PSTN/ISDN and SIP/NGN. PSTN/ISDN use this indication also for routing.
In PSTN/ISDN the "data-call" can be only transferred over 64kbit/s trunks. This can be used for a efficient coos of the correct MGC/MG combination with the clearmode codec.

> > 3. The charge information shown to the user of the payphone 
> is an other than for normal once
> or special destinations) can be performed
> 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.

As Takuya said:  cpc parameter will be used with 
P-Asserted-Identity header. In this scenario, trust domains 
model described in RFC 3324 is enough solution for security 
and authorization issues. Anyway we will require cpc value to 
be asserted by the network as it is in ISUP.
> 
> 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
>

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 15 Dec 2004 08:18:36 +0100

Hello An
The below mentioned draft is expiered. There is no work in SIP or IPTEL at the moment, but we hope it will.
We brought up the issue, becuse we see the demand on such a element in SIP.

Best Regerds

Roland

> Nguyen, An
> Gesendet: Dienstag, 30. November 2004 19:00
> An: 'Tom Taylor'
> Cc: [email-masked]; [email-masked]; Jesske, Roland
> Betreff: [Sip] RE: [Iptel] Calling Party's Category
> 
> 
> Mr. Taylor;
> 
> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2004 10:07 AM
> To: Jesske, R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Iptel] Calling Party's Category
> 
> 
> The question was what the requirement is for this sort of 
> indication.  How
> is it used?
> 
> Jesske, R wrote:
> > Dear all,
> > in the past there was a discussion regarding the specification of a
> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt)
> > What is the actual status of this activity. 
> > We are still interested in such kind of originating 
> indication if the
> call/communication is coming from a normal SIP user or a SIP 
> -Payphone or
> SIP-Hotelphone. 
> > Is there a interest from other parties in this issue?
> > 
> > Best Regards
> > 
> > Roland
> > 
> > Deutsche Telekom AG
> > T-Com Zentrale
> > Roland Jesske, TE332-2
> > Section TE33; Signalling, Gateways and Switching Systems 
> > Am Kavalleriesand 3, 64295 Darmstadt, Germany
> > Phone:  +49 6151 83-5940 
> > Fax:      +49 6151 83-4577 
> > email:   [email-masked]
> > 
> > 
> > 
> >