[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: Tuesday, December 02, 2008 6:22 AM
>
> My main comment on your draft at present is the proposal to allow a
> proxy to insert the session-id header if it has not been inserted by the
> UA. I think that this introduces additional problems of how to ensure
> that the proxy in included in the message path of a new request that
> uses the session-id that it inserted as a reference to the original
> dialog.
You mean that a "Proxy" in particular could do this, right? (not that a B2BUA could do this?)
RFrom sip-bounces at ietf.org Tue Dec 2 13:36:34 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9789B3A6B3D;
Tue, 2 Dec 2008 13:36:34 -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 B19DA3A6B3D
for <sip at core3.amsl.com>; Tue, 2 Dec 2008 13:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045,
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 0pAtqP53uNK3 for <sip at core3.amsl.com>;
Tue, 2 Dec 2008 13:36:31 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6])
by core3.amsl.com (Postfix) with ESMTP id A121F3A67D4
for <sip at ietf.org>; Tue, 2 Dec 2008 13:36:31 -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;
Tue, 2 Dec 2008 16:34:58 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with
mapi; Tue, 2 Dec 2008 16:34:57 -0500
From: Hadriel Kaplan <HKaplan at acmepacket.com>
To: Ian Elz <ian.elz at ericsson.com>
Date: Tue, 2 Dec 2008 16:36:25 -0500
Thread-Topic: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
Thread-Index: AclKfoqxkFCB9EHRT7mtNKPC52FJDQAAcB3QAX2SdRAAIen5UAAeULYwAAIYV3AAhaJ4YAARnCNAACQUQdAADzQ+EA==
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC3137A7E3C87 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>
<E6C2E8958BA59A4FB960963D475F7AC313776E21B0 at mail>
<C0E80510684FE94DBDE3A4AF6B968D2D0497EE8A at esealmw118.eemea.ericsson.se>
In-Reply-To: <C0E80510684FE94DBDE3A4AF6B968D2D0497EE8A 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: Tuesday, December 02, 2008 6:22 AM
>
> My main comment on your draft at present is the proposal to allow a
> proxy to insert the session-id header if it has not been inserted by the
> UA. I think that this introduces additional problems of how to ensure
> that the proxy in included in the message path of a new request that
> uses the session-id that it inserted as a reference to the original
> dialog.
You mean that a "Proxy" in particular could do this, right? (not that a B2BUA could do tight now the draft is written to make the matching mechanics basically optional for a node. The Session-ID header has uses beyond dialog matching ones, and I prefer to keep the bar low for implementations to at least pass it through, or even generate it. You're right that a Proxy implementing the matching function would need to keep itself in the path - good catch - I will add it if we decide Proxies should be able to do the matching function. (and yes, it could only keep itself in the path in certain scenarios, so we may just not want to let Proxies do a matching function period to make the draft easier to comprehend)
> This requires 2 things:
> (1) that every B2BUA constantly be 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.
>
> [Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an
> attempt to give some guidance on how B2BUAs should behave to make them
> as proxy like as possible.
Yes, and my own product does that as well by default (dialog transparency). Many/most operators turn that off when they install it, fwiw. But this isn't really about SBC's. If it were only about SBC's, there would be other ways to skin this cat. The problem is all B2BUA's. The number of B2BUA vendors/products/types is scary. Most of them seem to change Call-ID+tag's all the time, for reasons only they know. I know it's not due to the security issues. I know some of them change them to handle spirals correctly. I know some of them change them for internal architecture reasons. But I don't know all the reasons. I can't speak for them.
> [Ian Elz ] I have seen some of the 3gpp CRs which have suggested making
> this change. My present view is that this should not be changed. The
> solution may be that a B2BUA inserted contact should always be globally
> routable
That is technically and practically impossible. If 3GPP thinks it's possible, I suggest they talk to people who actually deploy their technology - i.e., the operators. :) SBC's have been able to generate the equivalent of GRUU's long before GRUU was invented, and it only works in certain cases.
[and I don't mean that as a slam against 3gpp - it's hard to get the operators' views in the IETF too; and yes I know operators attend 3gpp, but either their voices aren't heard, or they're not aware of the nuances - none of us are aware of the nuances across all sip-related uses, imho]
-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
his?)
Right now the draft is written to make the matching mechanics basically optional for a node. The Session-ID header has uses beyond dialog matching ones, and I prefer to keep the bar low for implementations to at least pass it through, or even generate it. You're right that a Proxy implementing the matching function would need to keep itself in the path - good catch - I will add it if we decide Proxies should be able to do the matching function. (and yes, it could only keep itself in the path in certain scenarios, so we may just not want to let Proxies do a matching function period to make the draft easier to comprehend)
> This requires 2 things:
> (1) that every B2BUA constantly be 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.
>
> [Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an
> attempt to give some guidance on how B2BUAs should behave to make them
> as proxy like as possible.
Yes, and my own product does that as well by default (dialog transparency). Many/most operators turn that off when they install it, fwiw. But this isn't really about SBC's. If it were only about SBC's, there would be other ways to skin this cat. The problem is all B2BUA's. The number of B2BUA vendors/products/types is scary. Most of them seem to change Call-ID+tag's all the time, for reasons only they know. I know it's not due to the security issues. I know some of them change them to handle spirals correctly. I know some of them change them for internal architecture reasons. But I don't know all the reasons. I can't speak for them.
> [Ian Elz ] I have seen some of the 3gpp CRs which have suggested making
> this change. My present view is that this should not be changed. The
> solution may be that a B2BUA inserted contact should always be globally
> routable
That is technically and practically impossible. If 3GPP thinks it's possible, I suggest they talk to people who actually deploy their technology - i.e., the operators. :) SBC's have been able to generate the equivalent of GRUU's long before GRUU was invented, and it only works in certain cases.
[and I don't mean that as a slam against 3gpp - it's hard to get the operators' views in the IETF too; and yes I know operators attend 3gpp, but either their voices aren't heard, or they're not aware of the nuances - none of us are aware of the nuances across all sip-related uses, imho]
-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