[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
Hi Ian,
Comments inline...
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz at ericsson.com]
> Sent: Monday, December 01, 2008 4:35 AM
>
> I know that we have to work with B2BUAs, and I understand the sentiment
> behind getting rid of them all together. The ietf work tends to preclude
> handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a
> concatenation of the UAC and UAS then all the ietf specifications have
> to ensure is that each Request can be routed to the correct B2BUA and
> then it is up to the B2BUA to ensure that it performs the correct
> actions for the end-to-end service.
This requires 2 things:
(1) that every B2BUA constantly bFrom sip-bounces at ietf.org Mon Dec 1 11:01:35 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 8AC5D3A6B93;
Mon, 1 Dec 2008 11:01:35 -0800 (PST)
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 A21693A6843
for <sip at core3.amsl.com>; Mon, 1 Dec 2008 11:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051,
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 NHJYhDTnY5PL for <sip at core3.amsl.com>;
Mon, 1 Dec 2008 11:01:33 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6])
by core3.amsl.com (Postfix) with ESMTP id A52243A6B94
for <sip at ietf.org>; Mon, 1 Dec 2008 11:01:33 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1;
Mon, 1 Dec 2008 14:00:00 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with
mapi; Mon, 1 Dec 2008 14:00:00 -0500
From: Hadriel Kaplan <HKaplan at acmepacket.com>
To: Ian Elz <ian.elz at ericsson.com>, Dan Wing <dwing at cisco.com>, "James M.
Polk" <jmpolk at cisco.com>
Date: Mon, 1 Dec 2008 14:01:28 -0500
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
Thread-Index: AclKfoqxkFCB9EHRT7mtNKPC52FJDQAAcB3QAX2SdRAAIen5UAAeULYwAAIYV3AAhaJ4YAARnCNA
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC313776E21B0 at mail>
References: <E6C2E8958BA59A4FB960963D475F7AC3136C7E982E at mail>
<F4B3A18038FD4A41B80EE1DE5451726F at laura>
<031c01c94a0f$7130acb0$1c91150a at cisco.com>
<C0E80510684FE94DBDE3A4AF6B968D2D0481798D at esealmw118.eemea.ericsson.se>
<039601c94a53$ba11f5d0$1c91150a at cisco.com>
<XFE-RTP-201D1OrRlig000014c5 at xfe-rtp-201.amer.cisco.com>
<01bc01c94a80$563d3150$dc5b150a at cisco.com>
<C0E80510684FE94DBDE3A4AF6B968D2D04913A0F at esealmw118.eemea.ericsson.se>
<E6C2E8958BA59A4FB960963D475F7AC31374A09EC2 at mail>
<C0E80510684FE94DBDE3A4AF6B968D2D0493D335 at esealmw118.eemea.ericsson.se>
<E6C2E8958BA59A4FB960963D475F7AC31374B1F0AE at mail>
<C0E80510684FE94DBDE3A4AF6B968D2D0493D807 at esealmw118.eemea.ericsson.se>
In-Reply-To: <C0E80510684FE94DBDE3A4AF6B968D2D0493D807 at esealmw118.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: SIP List <sip at ietf.org>
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
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
Hi Ian,
Comments inline...
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz at ericsson.com]
> Sent: Monday, December 01, 2008 4:35 AM
>
> I know that we have to work with B2BUAs, and I understand the sentiment
> behind getting rid of them all together. The ietf work tends to preclude
> handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a
> concatenation of the UAC and UAS then all the ietf specifications have
> to ensure is that each Request can be routed to the correct B2BUA and
> then it is up to the B2BUA to ensure that it performs the correct
> actions for the end-to-end service.
This requires 2 things:
(1) that every B2BUA constantly be upgrade upgraded to handle whatever new mechanism's syntax is for the identifiers, every time a new one is defined. (e.g., new XML schema or new header) I realize that's the nature of "you break it, you fix it", but if people want to have their new thing work without needing B2BUA's to be upgraded or re-configured, then there needs to be some generic way of handling this.
(2) that the mechanism using the call-id+tags gets sent to the B2BUA that changed them. Often it will. Sometimes it can't. For example, the mediactrl-framework model. Stick a b2bua between the UA and the Media-Control-Client, and the application doesn't work - or wouldn't have, except they changed it to use a new identifier different from call-id to avoid this problem.
> Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
> globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
> the B2BUA are different dialogs and must have different Call-ids.
Actually that's debatable. I don't think we'd want to say B2BUA's MUST change the Call-ID. 3261 did say a B2BUA is the logical concatenation of a UAS and UAC, but clearly not much text in 3261 was given to how a B2BUA should operate.
> The major issue which currently occurs is that a PUI is used to try and
> route a request which should be directed to specific UA, e.g. when
> referencing an extant dialog. To reach the specific UA the Contact
> should be used and if a B2BUA maps the Contact as well as the Call-id
> then the new Request should route to the B2BUA which can perform its
> 'magic' to provide the end-to-end service.
Some folks (from 3gpp) have asked that B2BAU's not change the contact-uri if it's a GRUU, though I'm not exactly sure why. There are also some cases in which having a B2BUA change the contact to be its specific instance doesn't work, because that address is not globally reachable; so leaving it as a GRUU (or something like a GRUU), is necessary but means out-of-dialog requests don't always reach the same B2BUA instance. This has been found in REFER transfer cases, where the referred party can't reach the same B2BUA as the referrer can.
-hadriel
_______________________________________________
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
ed to handle whatever new mechanism's syntax is for the identifiers, every time a new one is defined. (e.g., new XML schema or new header) I realize that's the nature of "you break it, you fix it", but if people want to have their new thing work without needing B2BUA's to be upgraded or re-configured, then there needs to be some generic way of handling this.
(2) that the mechanism using the call-id+tags gets sent to the B2BUA that changed them. Often it will. Sometimes it can't. For example, the mediactrl-framework model. Stick a b2bua between the UA and the Media-Control-Client, and the application doesn't work - or wouldn't have, except they changed it to use a new identifier different from call-id to avoid this problem.
> Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
> globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
> the B2BUA are different dialogs and must have different Call-ids.
Actually that's debatable. I don't think we'd want to say B2BUA's MUST change the Call-ID. 3261 did say a B2BUA is the logical concatenation of a UAS and UAC, but clearly not much text in 3261 was given to how a B2BUA should operate.
> The major issue which currently occurs is that a PUI is used to try and
> route a request which should be directed to specific UA, e.g. when
> referencing an extant dialog. To reach the specific UA the Contact
> should be used and if a B2BUA maps the Contact as well as the Call-id
> then the new Request should route to the B2BUA which can perform its
> 'magic' to provide the end-to-end service.
Some folks (from 3gpp) have asked that B2BAU's not change the contact-uri if it's a GRUU, though I'm not exactly sure why. There are also some cases in which having a B2BUA change the contact to be its specific instance doesn't work, because that address is not globally reachable; so leaving it as a GRUU (or something like a GRUU), is necessary but means out-of-dialog requests don't always reach the same B2BUA instance. This has been found in REFER transfer cases, where the referred party can't reach the same B2BUA as the referrer can.
-hadriel
_______________________________________________
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