RE: [Sip] outbound open issues from IETF 67
"Drage, Keith \(Keith\)" <drage@lucent.com> Thu, 23 November 2006 15:02 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnG5o-0006Up-FQ; Thu, 23 Nov 2006 10:02:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnG5n-0006Uj-1E for sip@ietf.org; Thu, 23 Nov 2006 10:02:23 -0500
Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnG5l-00024b-KE for sip@ietf.org; Thu, 23 Nov 2006 10:02:23 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kANF22Zf016411; Thu, 23 Nov 2006 09:02:02 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 09:02:02 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 16:02:00 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Sip] outbound open issues from IETF 67
Date: Thu, 23 Nov 2006 16:01:59 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180846E9F@DEEXC1U01.de.lucent.com>
In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03060C56@esebe103.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] outbound open issues from IETF 67
Thread-Index: AccM2vJiy3PjIkueQJ+nLnCBrLAx5wAobaYgAGTjQtA=
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Erkki.Koivusalo@nokia.com, rohan@ekabal.com, sip@ietf.org
X-OriginalArrivalTime: 23 Nov 2006 15:02:00.0463 (UTC) FILETIME=[53E309F0:01C70F10]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
They, in this case, is I believe one organisation. The proposal was referred back until the requirements are known - in any case 3GPP cannot define option-tags. Keith > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > Sent: 21 November 2006 15:11 > To: rohan@ekabal.com; sip@ietf.org > Subject: RE: [Sip] outbound open issues from IETF 67 > > > Hi Rohan, > > I do not have any objections to any of the proposals you made > for Outbound. However I have a question related to the Issue > 3G you had on your slideset. The slideset outlined the 3GPP > requirement as follows: > > - 3GPP and others want to store multiple path vectors back to > an instance, each associated with a reg-id. > - New registrations with the same reg-id would replace the > old binding. > * BUT 3GPP wants to do this unrelated to outbound flow-token > processing > * 3GPP wants separation of binding behavior and flow-token behavior > * Why? Their IPsec UDP uses several pairs of actual flows, > instead of just one. > > In 3GPP there is also a backwards compatibility issue related > to the IPSec SA management in the edge proxy (P-CSCF). Old > implementations not supporting Outbound would drop the old > logical flow (IPSec SA) if the UA registers with a new reg-id > and IP address. Thus the UA should be able to make sure that > the edge proxy supports the new behaviour, before trying to > establish multiple flows over different access networks > towards the single edge proxy. > > They have been proposing a new option tag for this purpose, > something like this: > > Name: mreg > Description: This option-tag is used to identify SIP servers which > are able to maintain multiple logical flows per UA instance. > > What do you think about this proposal ? > > Regards, > > Erkki > > >-----Original Message----- > >From: ext Rohan Mahy [mailto:rohan@ekabal.com] > >Sent: 20.November.2006 21:21 > >To: sip@ietf.org > >Cc: Rohan Mahy > >Subject: [Sip] outbound open issues from IETF 67 > > > >Hi Folks, > > > >I've incorporated all the changes we agreed to at IETF67. For those > >who have not seen them yet, please consult the slides available here: > >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf > > > >In addition, I have proposed text for Issues D&E (see below). > > > >In summary, we agreed from the meeting: > >- Consensus to use 430 response > >- Consensus to keep the "stable flow timer" > >Bug A: No objection to fixing this bug > >Issue B: consensus to only require 1st hop and registrar to > participate > >Issue C: consensus for No Action Issue D: did not discuss, proposal > >mentioned below Issue E: did not discuss, proposal mentioned below > >Issue F: consensus for No Action Issue 3G: rough consensus to Accept > >action 2 > > > >(Bug A): Provided mention of the 'rport' parameter. > > > >(Issue 3G): Relaxed flow-token language slightly. Instead of > flow-token > >saving specific UDP address/port tuples over which the > request arrived, > >make language fuzzy to save token which points to a 'logical > flow' that > >is known to deliver data to that specific UA instance. > > > >(Issue B): Changed registrar verification so that only > first-hop proxy > >and the registrar need to support outbound. Other intermediaries in > >between do not any more. > > > >(Issues D&E): Proposal text: > >The UAC can situationally decide whether to request outbound > behavior > >by including or omitting the 'reg-id' parameter. For > example, imagine > >the outbound-proxy-set contains two proxies in different domains, > >EP1 and EP2. > > If an outbound-style registration succeeded for a flow through EP1, > >the UA might decide to include 'outbound' in its option-tag when > >registering with EP2, in order to insure consistency. Similarly, if > >the registration through EP1 did not support outbound, the UA might > >decide to omit the 'reg-id' parameter when registering with EP2. > > > >I believe the proposed text for D&E is sufficient and should > be fairly > >non-controversial. If anyone has any objections, please > speak up ASAP > >(and *send text* ;-). > > > >thanks, > >-rohan > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use > >sip-implementors@cs.columbia.edu for questions on current sip Use > >sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] outbound open issues from IETF 67 Rohan Mahy
- RE: [Sip] outbound open issues from IETF 67 Erkki.Koivusalo
- Re: [Sip] outbound open issues from IETF 67 Rohan Mahy
- RE: [Sip] outbound open issues from IETF 67 Erkki.Koivusalo
- Re: [Sip] outbound open issues from IETF 67 Rohan Mahy
- RE: [Sip] outbound open issues from IETF 67 Drage, Keith (Keith)