Subject: [Iptel] Calling Party Category

From: Cullen Jennings <[email-masked]>
Date: Wed, 08 Dec 2004 14:45:51 -0800

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

---

From: Takuya Sawada <[email-masked]>
Date: Thu, 9 Dec 2004 21:21:52 +0900

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
> well, just a fact of life on the iptel list :-)

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

---

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

Not really disagreeing with but adding a bit more inline ...

> Use cases are varied as they are varied in ISUP.
It seems that this is better addressed by something like SIP-T that can
explicitly deal with caring all the ISUP that is needed.

> be asserted by the network as it is in ISUP.
P-Asserted-Identity was an Information document not standards track because
it had a very limited deployment model. It solved a very specific problem of
dealing call trace for anonymous calls in a particular walled garden model.