[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Signing P-Asserted-Identity
If you are talking enterprise to some sort of public service provider
you will get both cases happening, and possibly on the same interface
between the two providers.
It may well be distinguished based on whether the traffic is public
network traffic or private network traffic, see the definitions in
http://www.ietf.org/internet-drafts/draft-vanelburg-sipping-private-netw
ork-indication-01.txt
(rFrom sip-bounces at ietf.org Thu Jul 10 02:56:25 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CDA653A6986;
Thu, 10 Jul 2008 02:56:25 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CBFFE3A6986
for <sip at core3.amsl.com>; Thu, 10 Jul 2008 02:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TKIDY7obrv1A for <sip at core3.amsl.com>;
Thu, 10 Jul 2008 02:56:23 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39])
by core3.amsl.com (Postfix) with ESMTP id 997233A68F0
for <sip at ietf.org>; Thu, 10 Jul 2008 02:56:23 -0700 (PDT)
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6A9tYk8009829;
Thu, 10 Jul 2008 04:56:34 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 10 Jul 2008 04:56:32 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by
DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 10 Jul 2008 11:56:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 10 Jul 2008 11:56:27 +0200
Message-ID: <5D1A7985295922448D5550C94DE291800210D663 at DEEXC1U01.de.lucent.com>
In-Reply-To: <48753B83.40205 at cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Signing P-Asserted-Identity
Thread-Index: AcjiEx0tMIFXsvUCRxyJeJPkCxhyyQAX0B7w
References: <E6C2E8958BA59A4FB960963D475F7AC30EEDF3C361 at mail.acmepacket.com> <4873B3C5.4020202 at cisco.com> <E6C2E8958BA59A4FB960963D475F7AC30EEDF3CD21 at mail.acmepacket.com> <4873C037.5050203 at cisco.com><E6C2E8958BA59A4FB960963D475F7AC30EEDFAA52E at mail.acmepacket.com> <4873ECF2.5030908 at nostrum.com> <102a01c8e150$3e05a610$c2f0200a at cisco.com> <48742BC9.2090701 at nostrum.com> <051701c8e1d8$de07fc70$c2f0200a at cisco.com> <4874E1A9.1030106 at nostrum.com> <029401c8e209$70e52e70$eaa36b80 at cisco.com> <48752F47.8060905 at nostrum.com> <048901c8e20d$1dddda70$eaa36b80 at cisco.com> <48753393.5090307 at nostrum.com><48753605.5010604 at cisco.com>
<487536D9.900 at nostrum.com> <48753B83.40205 at cisco.com>
From: "DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>
To: "Jonathan Rosenberg" <jdrosen at cisco.com>, "Adam Roach" <adam at nostrum.com>
X-OriginalArrivalTime: 10 Jul 2008 09:56:30.0012 (UTC)
FILETIME=[39DF6FC0:01C8E273]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: sip at ietf.org, Michael Thomas <mat at cisco.com>, Dan Wing <dwing at cisco.com>
Subject: Re: [Sip] Signing P-Asserted-Identity
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
If you are talking enterprise to some sort of public service provider
you will get both cases happening, and possibly on the same interface
between the two providers.
It may well be distinguished based on whether the traffic is public
network traffic or private network traffic, see the definitions in
http://www.ietf.org/internet-drafts/draft-vanelburg-sipping-private-netw
ork-indication-01.txt
(revision evision expected shortly)
For public network traffic, the situation you are talking about has wide
acceptance for the PSTN in the US, but virtually no appearance in the
PSTNs of some European countries. When these operators go to IP, you can
expect the same approach to P-Asserted-Identity.
For private network traffic, I would expect the trust domain to
encompass the enterprise and the public service provider for the support
of such a capability to make any sense, but there are still some awkward
public service providers out there.
Regards
Keith
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Jonathan Rosenberg
> Sent: Wednesday, July 09, 2008 11:28 PM
> To: Adam Roach
> Cc: sip at ietf.org; 'Michael Thomas'; Dan Wing
> Subject: Re: [Sip] Signing P-Asserted-Identity
>
> I had assumed enterprises would be part of the trust domain
> of the provider.
>
> -Jonathan R.
>
> Adam Roach wrote:
> > On 7/9/08 5:04 PM, Jonathan Rosenberg wrote:
> >> Bringing this back to the original topic:
> >>
> >> I did not think Hadriels draft was proposing that PAI get
> stripped at
> >> that boundary.
> >
> > From the abstract: "The use of these extensions is only applicable
> > inside a set of administrative domains with previously agreed-upon
> > policies for generation, transport and usage of such information."
> >
> > This means that there's either an agreement with the ITSPs
> (which I'm
> > arguing have demonstrably no interest in making this
> happen), or the
> > information is stripped before handing to the ITSPs. Or am
> I missing
> > something?
> >
> > /a
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
> Cisco Fellow Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen at cisco.com
> http://www.jdrosen.net PHONE: (408) 902-3084
> http://www.cisco.com
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
expected shortly)
For public network traffic, the situation you are talking about has wide
acceptance for the PSTN in the US, but virtually no appearance in the
PSTNs of some European countries. When these operators go to IP, you can
expect the same approach to P-Asserted-Identity.
For private network traffic, I would expect the trust domain to
encompass the enterprise and the public service provider for the support
of such a capability to make any sense, but there are still some awkward
public service providers out there.
Regards
Keith
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Jonathan Rosenberg
> Sent: Wednesday, July 09, 2008 11:28 PM
> To: Adam Roach
> Cc: sip at ietf.org; 'Michael Thomas'; Dan Wing
> Subject: Re: [Sip] Signing P-Asserted-Identity
>
> I had assumed enterprises would be part of the trust domain
> of the provider.
>
> -Jonathan R.
>
> Adam Roach wrote:
> > On 7/9/08 5:04 PM, Jonathan Rosenberg wrote:
> >> Bringing this back to the original topic:
> >>
> >> I did not think Hadriels draft was proposing that PAI get
> stripped at
> >> that boundary.
> >
> > From the abstract: "The use of these extensions is only applicable
> > inside a set of administrative domains with previously agreed-upon
> > policies for generation, transport and usage of such information."
> >
> > This means that there's either an agreement with the ITSPs
> (which I'm
> > arguing have demonstrably no interest in making this
> happen), or the
> > information is stripped before handing to the ITSPs. Or am
> I missing
> > something?
> >
> > /a
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
> Cisco Fellow Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen at cisco.com
> http://www.jdrosen.net PHONE: (408) 902-3084
> http://www.cisco.com
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip