Re: [sipcore] draft-kaplan-sip-session-id-02
"Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> Wed, 15 July 2009 14:47 UTC
Return-Path: <Peter.Dawes@vodafone.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D17D3A6CED for <sipcore@core3.amsl.com>; Wed, 15 Jul 2009 07:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_84=0.6]
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 6w+d+M2X1gZp for <sipcore@core3.amsl.com>; Wed, 15 Jul 2009 07:47:01 -0700 (PDT)
Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by core3.amsl.com (Postfix) with ESMTP id E28A03A6BF0 for <sipcore@ietf.org>; Wed, 15 Jul 2009 07:47:00 -0700 (PDT)
Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id A0FEA84895 for <sipcore@ietf.org>; Wed, 15 Jul 2009 16:46:45 +0200 (CEST)
Received: from mi1.vodafone.com (mi1.vodafone.com [195.232.246.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 9489E84255; Wed, 15 Jul 2009 16:46:45 +0200 (CEST)
Received: from avoexs02.internal.vodafone.com ([145.230.4.135]) by mi1.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n6FEkfVY009667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Jul 2009 16:46:44 +0200
Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 16:46:45 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Jul 2009 16:46:40 +0200
Message-ID: <C6A11A02FF1FBF438477BB38132E474104B23BFB@EITO-MBX02.internal.vodafone.com>
In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02
Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwAAGgysAAavX4kA==
References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <C6A11A02FF1FBF438477BB38132E474104B236BB@EITO-MBX02.internal.vodafone.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de>
From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com>
To: L.Liess@telekom.de, HKaplan@acmepacket.com
X-OriginalArrivalTime: 15 Jul 2009 14:46:45.0106 (UTC) FILETIME=[12EB6520:01CA055B]
Cc: sipcore@ietf.org, Gerold.Pinker@telekom.de, dworley@nortel.com, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de
Subject: Re: [sipcore] draft-kaplan-sip-session-id-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 14:47:02 -0000
Hello Laura, Thanks for the very interesting extra perspective. Does your traffic monitoring solution pass all SIP signalling through this 'separate device for monitoring', and does this device record all network activity all the time? I ask because one thing that the session-id-02 draft does not seem to help with is how you identity a particular session you are interested in. Since session-id is very similar to Call-ID, it doesn't seem very different from recording everything and then searching based on Call-ID. I agree with you that a solution should not rely on end devices, although ideally end devices are included in troubleshooting. Draft http://tools.ietf.org/html/draft-dawes-sipping-debug-01 also does not rely on end devices (in 5.2 it says that the first proxy in the path can insert the new P-Debug-ID header), but I should probably revise the draft structure to make the responsibilities of each entity (UAC, Proxy, UAS, etc.) clearer. Best regards, Peter -----Original Message----- From: L.Liess@telekom.de [mailto:L.Liess@telekom.de] Sent: 13 July 2009 17:00 To: Dawes, Peter, VF-Group; HKaplan@acmepacket.com Cc: dworley@nortel.com; sipcore@ietf.org; R.Jesske@telekom.de; Martin.Huelsemann@telekom.de; Gerold.Pinker@telekom.de Subject: RE: [sipcore] draft-kaplan-sip-session-id-02 Peter, we intend to use the Session-ID for traffic monitoring. Personally, I like the debug drafts a lot because it is a quite efficient mechanism for detecting faults quickly but it covers quite different scenarios than Session-ID. We discussed internaly what to use and decided for Session-ID for following reasons: - The monitoring is done by a separate device, we don't use the logfiles of the proxies. - We can not rely on end devices. We already have a lot of end devices in the field which do not have session-ID or debug-id implemented. First SBC in the path has to insert the new ID. Also, the security people whant to use the ID to trace attacks and we assume that the attacker's clients will not insert the debugg-id. - We want to be able to correlate the messages end-to-end also if we do not know in advance if we want to monitor a specific call. - The monitoring is active all the time. The security people want to be able to look what happened in the past. So the global uniqueness requirement makes sense for me. - The hashing is needed because we do not want the calle to see the IP-address of the caller end most devices insert the IP-address in the call-id. Kind regards Laura > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, July 13, 2009 1:12 PM > To: SIPCORE; Hadriel Kaplan > Cc: Dale Worley > Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 > > Hello Hadriel, Dale, > Regarding the length of the session-id header field, is it really > necessary to guarantee global uniqueness and use 128 bits? The uses of > this new header field described in -02 are 'troubleshooting' and > 'identity verification mechanisms', but troubleshooting will be > restricted to relatively short time period after which a session-id > value could be reused. Identity verification is not described but does > it require a globally unique session-id? > > Troubleshooting is also the topic of my draft > http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is > similar to session-id but also describes how troubleshooting starts > and stops, and how entities determine when to add a header field for > debugging. According to session-id-02, the session-id header field is > present in all dialogs, which implies troubleshooting needs to record > everything, potentially at multiple entities some of which may not be > involved in the session being investigated, and then post-analyse for > the particular session that is targetted for troubleshooting. > This seems > inefficient, or have I misunderstood? > > Best Regards, > Peter > > > Peter Dawes > Group R&D > > Tel: +44 (0)7717 275009 > Fax: +44 (0)1635 234873 > > > E-mail: peter.dawes@vodafone.com > > www.betavine.net - Web > betavine.mobi - Mobile Web > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, Berkshire > RG14 2FN Registered in England No 3802001 > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Dale Worley > Sent: 24 June 2009 21:51 > To: SIPCORE > Subject: [sipcore] draft-kaplan-sip-session-id-02 > > Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id > header is, the fewer complaints people will have about using it in > practice. A couple of things could be done to shorten it: > > - assign a single-letter abbreviation for the name > > - use base64 rather than hex encoding > > Base64 encoding reduces the header value to 22 characters from 32. > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >
- [sipcore] draft-kaplan-sip-session-id-02 Dale Worley
- Re: [sipcore] draft-kaplan-sip-session-id-02 Dawes, Peter, VF-Group
- Re: [sipcore] draft-kaplan-sip-session-id-02 L.Liess
- Re: [sipcore] draft-kaplan-sip-session-id-02 Dawes, Peter, VF-Group
- Re: [sipcore] draft-kaplan-sip-session-id-02 L.Liess
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Dale Worley
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Martin.Huelsemann
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Martin.Huelsemann
- Re: [sipcore] draft-kaplan-sip-session-id-02 Dale Worley
- Re: [sipcore] draft-kaplan-sip-session-id-02 Hadriel Kaplan
- Re: [sipcore] draft-kaplan-sip-session-id-02 Dale Worley
- Re: [sipcore] draft-kaplan-sip-session-id-02 Gonzalo Camarillo
- Re: [sipcore] draft-kaplan-sip-session-id-02 L.Liess