Subject: RE: [Sip] RE: [Iptel] Calling Party's Category

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 30 Nov 2004 17:51:33 +0100

In the Call Return service, a destination exchange memories an incoming call which failed due to non-reply. If the call was orginated by a payphone then the destination exchange does not memories the number since it makes no sense in calling back a payphone. 

BR,
sebastien

-----Message d'origine-----
De : David R Oran [mailto:[email-masked]] 
Envoyé : mardi 30 novembre 2004 17:23
À : GARCIN Sebastien RD-CORE-ISS
Cc : Jesske, R; Tom Taylor; [email-masked]; [email-masked]
Objet : Re: [Sip] RE: [Iptel] Calling Party's Category

On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote:

> Hi,
>
> As an fixed line operator we also are interested in this feature and 
> would be happy that the IETF finally moves forward with this draft.
> This type of parameter is widely signalled in ISDN/PSTN networks. In 
> SIP (for example) it is required in context of both:
>
> - pure SIP networks (e.g. in case of a SIP payphone), and
> - interworking with legacy networks
>
> I think the uses case for this parameter will depend on the operator 
> service portfolio. For example, in France, the calling party's 
> category parameter is used for the Call Return service.
>
Could you explain a bit about how this is used? I, for one would find it helpful and possibly a motivating use case.

Also note that if this information is used for any security or billing-sensitive operations, we have to deal with the issue of how to secure it against spoofing (SIP UAs are generally not trusted). Would you believe a call made by Robert Mitnick from a prison phone would actually have a prison CPC in it's SIP headers :-) ?

(Mitnick is a widely known phone freak and network hacker who served a number of years in US prisons).

> Best regards,
> sebastien
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Tom Taylor Envoyé : mardi 30 novembre 2004 16:07 À : Jesske, R Cc : 
> [email-masked]; [email-masked] Objet : 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]
>>
>>
>>
>>
>> _______________________________________________
>> Iptel mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/iptel
>>
>>
>
> --
> 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
>
> _______________________________________________
> 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: "Ben Gatewood" <[email-masked]>
Date: Tue, 30 Nov 2004 16:47:00 -0000

His name is Kevin. Other than that I agree with you.

I'm interested in this area as well as I might be able to make use of this type of functionality in a hospitality industry scenario. 

Regards,

B

http://www.freekevin.com/

Ben Gatewood
Streamdoor Ltd
114b Power Rd
London
W4 5PY
+44 20 7422 0439
+44 7835 136 187
[email-masked]

-----Original Message-----
From: [email-masked] on behalf of David R Oran
Sent: Tue 11/30/2004 4:23 PM
To: GARCIN Sebastien RD-CORE-ISS
Cc: Jesske, R; [email-masked]; Tom Taylor; [email-masked]
Subject: Re: [Sip] RE: [Iptel] Calling Party's Category

> category parameter is used for the Call Return service.
Could you explain a bit about how this is used? I, for one would find 
it helpful and possibly a motivating use case.

Also note that if this information is used for any security or 
billing-sensitive operations, we have to deal with the issue of how to 
secure it against spoofing (SIP UAs are generally not trusted). Would 
you believe a call made by Robert Mitnick from a prison phone would 
actually have a prison CPC in it's SIP headers :-) ?

(Mitnick is a widely known phone freak and network hacker who served a 
number of years in US prisons).

> de Tom Taylor
> Envoyé : mardi 30 novembre 2004 16:07
> À : Jesske, R
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Iptel] Calling Party's Category
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

**************************************************************************************
Disclaimer:

This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this email in error, please contact  Streamdoor Group IT&C Helpdesk by email at [email-masked] or write to  Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
**************************************************************************************
**************************************************************************************
Disclaimer:

This electronic message may contain privileged or confidential information. If you are not the intended recipient, be advised that any disclosure, copying, distribution or use of this information is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this message. Views expressed in this message are those of the individual sender, and are not necessarily the views of the Streamdoor Limited, unless otherwise stated.

Although Streamdoor Limited has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachement

Employees of Streamdoor Limited and its affiliates are expressly required not to make defamatory statements and not to infringe or authorise any infringements of copyrights or any other legal right by email communications. Any such communication is contrary to company policy and outside the scope of the employment of the individual concerned.

For further assistance on email policy, or if you have received this email in error, please contact  Streamdoor Group IT&C Helpdesk by email at [email-masked] or write to  Streamdoor Ltd , Head of IT&C Department , 114 Power Road , Chiswick, London , W4 5PY.

www.streamdoor.com
**************************************************************************************

---

From: [email-masked]
Date: Tue, 30 Nov 2004 16:06:13 EST

> actually have a prison CPC in it's SIP headers :-) ?

Of course, this shows a basic difference in the way this capability is 
handled in SIP vs today's telephone network. It's an important thing to deal with, 
since many of these things are mandated by law. For example, I believe the 
requirement to identify calls from a prison as such is mandated.

In today's network, in order to provide assurance that the call is properly 
marked, not just for CPC but calling party ID as well, the phone in the prison 
is rnot esponsible for the marking. The switch outside the prison marks any 
call that comes over that pair of wires. Robert Mitnick had no opportunity to 
change that marking.

The issue for SIP is to provide the same level of assurance for such 
functions. I'm sure anxious to hear a resolution to this problem, since it keeps 
coming back. CPC is not unique in this regard, so a general solution is needed.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Nov 2004 19:39:50 -0500

I view these sorts of security attributes as elements of trait-based
authorization. The calling party's category requires the sort of
pre-arrangement and federation to which something like SAML naturally lends
itself.

Jon Peterson
NeuStar, Inc.

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2004 9:27 PM
> To: David R Oran
> David R Oran wrote:
> I'm equally confused. I'm familiar with the calling party category in 
> ISUP, which works only because of the walled-garden nature of the SS7 
> network. Without that, there are really two major factors around this 
> which need to be characterized:
> 
>    1. Who is authorized to assert a particular calling party category?
>       This is much trickier than the identity problem; with 
> identity, we
>       can trust that a domain is the authority for the use of 
> user names
>       in that domain. For calling party category, there is no such
>       relationship. For example, it would probably not be valid for a
>       domain of "adamroach.com" to assert a calling party category of
>       "priority," "operator," or "police."
>    2. Under which circumstances is the calling party category required
>       to be present? Is there some architectural mechanism that can be
>       used to enforce this? (We don't need to define it, but there
>       should at least be some idea about whether it's 
> possible). If not,
>       then there is no purpose in coming up with a protocol mechanism
>       for conveying such information.
> 
> /a
>