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
> 