[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Iptel] [Sipping] draft-mahy-iptel-cpc

To: "DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>
Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
From: Paul Kyzivat <pkyzivat at cisco.com>
Date: Tue, 01 Apr 2008 21:54:12 -0400
Authentication-results: ams-dkim-2; header.From=pkyzivat at cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Cc: iptel at ietf.org, Jean-Francois Mule <jf.mule at cablelabs.com>, Ian Elz <ian.elz at ericsson.com>, sipping at ietf.org
Delivered-to: ietfarch-iptel-web-archive at core3.amsl.com
Delivered-to: iptel at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=6476; t=1207101234; x=1207965234; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat at cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com> |Subject:=20Re=3A=20[Sipping]=20draft-mahy-iptel-cpc |Sender:=20; bh=NbMMGUM9L2z7zTO8GbruAyIvzGa6KPRGfRdh/FpxNCU=; b=lUCWfjGcS2phDzfDsI6+B4URhD2MPd0wemIrXWSg8E1/8laQ+Vh74CXRyy QQEwZ6ILfF07jKs78gsrewvoMQseroFi6NGayYh7iCLbK3g3bzkDdYAhhkZs mGs76PIu0l;
In-reply-to: <28F05913385EAC43AF019413F674A0171246EDB5 at OCCLUST04EVS1.ugd.att.com>
List-archive: <http://www.ietf.org/pipermail/iptel>
List-help: <mailto:iptel-request@ietf.org?subject=help>
List-id: IP Telephony <iptel.ietf.org>
List-post: <mailto:iptel@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>, <mailto:iptel-request@ietf.org?subject=unsubscribe>
References: <28F05913385EAC43AF019413F674A0171246EDB0 at OCCLUST04EVS1.ugd.att.com> <45AEC6EF95942140888406588E1A6602043FD676 at PACDCEXCMB04.cable.comcast.com> <28F05913385EAC43AF019413F674A0171246EDB5 at OCCLUST04EVS1.ugd.att.com>
Sender: iptel-bounces at ietf.org
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

If the semantics are to be defined by SS7 then it makes sense to have 
the same two parameters that it has. But is that the right thing?

If you dig thru the stuff in there, some of the values indeed fall into 
mutually exclusive sets. Others seem to be orthogonal. (E.g. police vs 
celular, or test vs lots of things.) Why not decompose these things into 
orthogonal dimensions and have a parameter for each? If not all 
combinations are conveyable in SS7 it won't be a problem going from SS7 
to SIP, and when going the other way it can simply be a policy about 
which attributes trump which other attributes.

	Paul

DOLLY, MARTIN C, ATTLABS wrote:
> I think 2 separate PAI parameters.  
> 
> -----Original Message-----
> From: Lee, Yiu [mailto:Yiu_Lee at cable.comcast.com] 
> Sent: Tuesday, April 01, 2008 9:01 PM
> To: DOLLY, MARTIN C, ATTLABS; Ian Elz; iptel at ietf.org; sipping at ietf.org;
> Jean-Francois Mule; Daryl Malas
> Subject: RE: [Sipping] draft-mahy-iptel-cpc
> 
> Hi Martin,
> 
> Forgive me that I am not an expert for SS7. So, you support to separate
> OLI and CPC into two parameters. I have no objection for it, I just want
> to see how we move forward.
> 
> Thanks,
> Yiu
> 
> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly at att.com] 
> Sent: Tuesday, April 01, 2008 8:54 PM
> To: Lee, Yiu; Ian Elz; iptel at ietf.org; sipping at ietf.org; Jean-Francois
> Mule; Daryl Malas
> Subject: RE: [Sipping] draft-mahy-iptel-cpc
> 
> How could you come to that conclusion for a North American deployment?
> 
> CPC and OLI have separate meanings.
> 
> CPC: Information sent in the forward direction indicating the category
> of the calling party and, in case of semiautomatic calls, the service
> language to be spoken by the incoming, delay and assistance operators.
> The format of the calling party's category is shown below.
> 
> OLI:  Information sent in the forward direction indicating toll class of
> service. Identification of the originating line.
> 
> Agreed, they are never seen by an end point (walled garden only), as
> they both will be asserted, therefore needed to be associated with the
> PAI. 
> 
> -----Original Message-----
> From: Lee, Yiu [mailto:Yiu_Lee at cable.comcast.com]
> Sent: Tuesday, April 01, 2008 8:40 PM
> To: Ian Elz; DOLLY, MARTIN C, ATTLABS; iptel at ietf.org; sipping at ietf.org
> Subject: RE: [Sipping] draft-mahy-iptel-cpc
> 
> After reading all the mails in the list, I think we agree:
> 
> 1. OLI-CPC should be carried in one parameter. Exact syntax yet to be
> defined.
> 2. This parameter should be inserted by originating network but not the
> UAC (From vs. PAI).
> 3. This parameter is useful for both SIP-URI and TEL-URI.
> 
> We haven't agreed if we allow the parameter carries multiple values (due
> to SIP->ISUP interop)
> 
> Now my question is what is next step?
> 
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
> Behalf Of Ian Elz
> Sent: Tuesday, April 01, 2008 8:21 AM
> To: DOLLY, MARTIN C, ATTLABS; iptel at ietf.org; sipping at ietf.org
> Subject: Re: [Sipping] draft-mahy-iptel-cpc
> 
> Martin,
> 
> Sorry my choice of words. 'back to ISUP' was not meant to imply a
> backward direction message but where the interworking from SIP -> ISUP.
> 
> ISUP -> SIP working is easy as ISUP will only contain one value but if
> SIP contains multiple values as Paul has suggested then we need to be
> able to map these to a single value in ISUP.
> 
> Ian Elz
> 
> System Manager
> DUCI LDC UK
> (Lucid Duck)
> 
> Office: + 44 24 764 35256
> gsm: +44 7801723668
> ian.elz at ericsson.com
> 
> 
> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly at att.com]
> Sent: 01 April 2008 13:16
> To: Ian Elz; iptel at ietf.org; sipping at ietf.org
> Subject: RE: [Sipping] draft-mahy-iptel-cpc
> 
> Ian,
> 
> CPC: Information sent in the forward direction indicating the category
> of the calling party and, in case of semiautomatic calls, the service
> language to be spoken by the incoming, delay and assistance operators.
> The format of the calling party's category is shown below.
> 
> OLI:  Information sent in the forward direction indicating toll class of
> service. Identification of the originating line.
> 
> Martin
> 
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz at ericsson.com]
> Sent: Tuesday, April 01, 2008 4:58 AM
> To: Paul Kyzivat
> Cc: iptel at ietf.org; DOLLY, MARTIN C, ATTLABS; sipping at ietf.org
> Subject: RE: [Sipping] draft-mahy-iptel-cpc
> 
> Paul,
> 
> My comments are made based upon the content of the latest draft (06).
> 
> The introduction begins:
> 
>    "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that
>    characterizes the station used to originate a call and carries other
>    important state that can describe the originating party.  When
>    telephone numbers are contained in URIs, such as the tel URI [2], it
>    may be desirable to communicate any CPC associated with that
>    telephone number or, in the context of a call, the party calling from
>    it."
> 
> Based upon this the current requirement appears to be to support the
> ISUP CPC/OLI.
> 
> If the requirement is greater than this then that is a discussion that
> we should have before the draft is finalized.
> 
> The issue with mutual exclusivity exists in the current ISUP
> implementations. If that limitation is to be overcome then that
> requirement also needs to be discussed. If we are to move from mutual
> exclusivity of values then we need to ensure that interworking back to
> ISUP is supported. The resolution of the overlapping cases as you have
> indicated may have to be at the discretion of the network operator.
> 
> Ian Elz
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sip at ietf.org for new developments of core SIP
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP
> 
_______________________________________________
Iptel mailing list
Iptel at ietf.org
https://www.ietf.org/mailman/listinfo/iptel

References:
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
  - From: DOLLY, MARTIN C, ATTLABS
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
  - From: Lee, Yiu
- Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
  - From: DOLLY, MARTIN C, ATTLABS

Prev by Date: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
Next by Date: [Iptel] test to iptel
Previous by thread: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc
Next by thread: [Iptel] Last Call: draft-ietf-iptel-tel-reg (The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry) to Proposed Standard
Index(es):
- Date
- Thread