Subject: AW: [Iptel] Calling Party Category

From: "Jesske, R" <[email-masked]>
Date: Fri, 10 Dec 2004 07:03:01 +0100

Some comments to your addings.

Using SIP-T or SIP-I assumes that the applications have to support the full ISUP stack, but we want to use SIP.

The P-Asserted-ID is used within standards from 3GPP, ITU-T, ETSI, T1S1... so I don't think that it is very limited...

I don't think that the use is very limited e.G:

-Billing
-Routing based on originating indications (e.G. special domainnames or numbergroups)
-Services selective Call Forwarding
-incomming screening of Calls based on a trusted number 
...

Best Regards

Roland

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag
> von Cullen Jennings
> Gesendet: Donnerstag, 9. Dezember 2004 21:21
> An: Takuya Sawada; [email-masked]
> Betreff: Re: [Iptel] Calling Party Category
> 
> 
> 
> Not really disagreeing with but adding a bit more inline ...
> 
> On 12/9/04 4:21 AM, "Takuya Sawada" <[email-masked]> wrote:
> 
> > 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.
> > 
> It seems that this is better addressed by something like 
> SIP-T that can
> explicitly deal with caring all the ISUP that is needed.
> 
> > 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.
> 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.
> 
> > 
> > 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
> 

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 Dec 2004 11:49:28 -0800

> ISUP stack, but we want to use SIP.

Yes - I agree, but this is the grief I am having is an arguments of the
form:

People come and say please add parameter X from ISUP. Then folks say sure,
why what do you want to do with it? Then the answer is well it is in ISUP so
we must have it. 

If this is true for all values of X then you need all of ISUP and just go do
ISUP. 

If their is some feature you want (that ISUP can do), like special billing
from a payphone, then don't even mention ISUP. Say "I would like to be able
to bill payphone users extra" - take that to the sipping WG and I predict
people will come up with a solution to the problem.

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 13 Dec 2004 17:49:43 +0900

I would also like to keep SIP clean, really.
I would be happy if we could throw ISUP away and go with pure SIP.
We know it is not possible.

Can we understand cpc work along the following way?

- It is NOT a SIP extension. cpc parameter does not affect any SIP behaviour.
  (Actually, it is a tel URI extension)
- It is just additional information to be added to the resource indicated
  by tel URI in a certain circumstances.
- Billing from a payphone is a use case, not a requirement. Requirement is
  that cpc parameter value range should cover all the characteristics used 
  in ISUP network at minimum. It is not the work for SIPPING WG.

---
For the general problem, adding other parameters X from ISUP, I think
we should be careful in doing that. I hope there are not so much candidates,
though I can imagine ATP, access transport prameter, and UUS, user-to-user
information.....
I noticed that Q.1980.1, which is in progress in ITU-T, is related to that
type of problem. I am not so familiar with that work that I am not sure it
will fit and cover all the problems.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)