Subject: AW: [Iptel] Calling Party Category

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

Hi,
I would also like to support Takuya' and the comments from Sebatien proposal.

A in addition it could be used for routing purposes in a SIP Proxy to choose the best MGC/MG. 

EG 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.

Best Regards

Roland 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag
> von GARCIN Sebastien RD-CORE-ISS
> Gesendet: Donnerstag, 9. Dezember 2004 13:41
> An: Takuya Sawada; [email-masked]; [email-masked]
> Betreff: RE: [Iptel] Calling Party Category
> 
> 
> 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
> 

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

---

From: "Chaidez, Fidencio (Fidencio)" <[email-masked]>
Date: Thu, 9 Dec 2004 11:08:05 -0600

All,
It is clear that a solution is needed
in relation to supporting "cpc" type of information. 
Many SIP-based service providers will likely be 
making use of a walled-garden, trust-based, approach,
for which Takuya's proposal will be sufficient
to meet their requirements.  Because of the
non-general nature of this solution (as Takuya 
pointed out) targetting a revived cpc draft as an 
Informational RFC would be a good way to go.  
Regards,
Fidencio

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]Im Auftrag
von Jesske, Roland
Gesendet: Donnerstag, 9. Dezember 2004 14:06
An: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Betreff: AW: [Iptel] Calling Party Category

Hi,

Best Regards

Roland