Subject: RE: [Iptel] Calling Party Category

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 9 Dec 2004 13:41:04 +0100

Hi,

I would like to support Takuya' proposal. I'd also like to point out that there are clear uses cases for the calling party's category and operators experience those requirements every day in their networks. 

Here is a brief summary of those that relate to the "payphone" value:

Charging
--------
The cpc value "payphone" is used for charging purposes

Services
--------
Some services (e.g. Call return, Freephone services) use the "payphone" value.

The fact that we are in a pure SIP or ISUP environment does not change those requirements.

Regards,
Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Takuya Sawada
Envoyé : jeudi 9 décembre 2004 13:22
À : [email-masked]; [email-masked]
Objet : Re: [Iptel] Calling Party Category

Hi,

Regarding 1), I think the requirements from those who reqire cpc parameter are simple and clear; carry the ISUP cpc information in SIP messages with tel URI.
Use cases are varied as they are varied in ISUP.

Regaerding 2), IMHO, 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.

I totally agree that 'because ISUP has it' is not sufficient to move it forward as an iptel WG item. During the discussion I feel it is very difficult to justify cpc work for iptel work item beyond 'because ISUP has it'.

Now I propose that let's move cpc draft forward as an individual document and make it an informational RFC. It may be a good idea to add the limited scope of cpc and some use cases.
If we can find more complete and general solution to cover cpc work later, we will make it a standard track RFC.
I think we did that way for network asserted identity.

How do people think about the above idea?

Note that according RFC 3966, new tel URI RFC, an informational RFC is sufficient for optional tel URI parameters.

Regards,
Takuya
> 
> I promised to start a thread on this and figure out what people want 
> to do with it and if we understand the requirements for it then 
> propose next steps.
> 
> Fortunately, there is a thread going in the sip mailing list. I would 
> summarize that thread as:
> 
> 1) the requirements and use case are varied and not clear
> 2) they involved complex security and authorization issues
> 3) SAML looks like it might help with many of them
> 4) there are issues with extension and scope of future categories
> 
> This makes me very uncomfortable with moving forward with this work 
> right now as a WG item in IPTEL. What I suggest is that we shelve this 
> work for now and let sipping figure out what the requirements are and 
> if the solutions looks like we need to add something to the tel URL, 
> revive the draft and figure out what to do with it.
> 
> What do people think of this? Folks ok with this? I will take silence 
> as well, just a fact of life on the iptel list :-)
> 
> Cullen
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/iptel

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 09 Dec 2004 12:23:24 -0800

Yes, I agree that there is an interest in billing calls from payphone
differently than from say, bordellos (thanks Dave :-). However, I'm sitting
here reading the charter of iptel and sipping and this seem like a great set
of requirements to take to sipping and figure out how to solve the problem.
The connection to a tel URL seem very tenuous other than it's a place this
data could be stuck for transport.

On 12/9/04 4:41 AM, "GARCIN Sebastien RD-CORE-ISS"
<[email-masked]> wrote:

> Hi,
> 
> I would like to support Takuya' proposal. I'd also like to point out that
> there are clear uses cases for the calling party's category and operators
> experience those requirements every day in their networks.
>