Re: [sipcore] draft-kaplan-sip-session-id-02

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Dawes, Peter, VF-Group [mailto:[e-mail]]
> Sent: Wednesday, July 15, 2009 10:47 AM
> Subject: RE: [sipcore] draft-kaplan-sip-session-id-02
> 
> 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.

With regards to identifying a particular session you're interested in, I'm not sure if you mean that in the sense of:
    1) Once I know I want Session X, how do I find the messages for it? 
Or...
    2) How do I even decide Session X is what I want to log?  

The answer to the first question is: using the Session-ID.  And Session-ID is different from a Call-ID, purely because it gets through B2BUA's.  If you determine you want to find all SIP messages from a given Call-ID, you have to take into account that the Call-ID changes along the path.  Some of the devices change it due to security reasons, which is what I wrote http://tools.ietf.org/html/draft-kaplan-sip-secure-call-id-00 to try to avoid - but some devices change it for very different, unavoidable reasons.  You can record everything all day long, but you have to figure out what inbound dialog is associated with what outbound dialog(s) in the B2BUA's along the path, to actually troubleshoot it.  So Session-ID is to solve that problem.

For the question (2) semantically that is more of a "filter" question, than an identifier once the filter is triggered.  It's just asking "what filters do I want to use, in order to choose which calls to debug?"  In other words, deciding what session to analyze is a separate thing from identifying which messages are part of the same session.  In your debug draft, the "filter" is the set of things in the XML identified by the <start-trigger> and <stop-trigger> elements, for things like target URI's and time.  The debug draft just ties those together with the message identifier, so that it can only be done in real-time, and in a certain way. (I think)

-hadriel