Subject: [dispatch] What session-id is for

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 14:13:36 -0400

So I was looking back in the mailing list archive to try to figure out the background on alert-info URN proposal, and came upon this thread on the Session-id draft that I hadn't seen.

To be clear: the *secure-call-id* draft was just describing a way for Call-ID to be created by any UAC, such that topology-hiding middleboxes such as SBC's don't have to go mucking with them.  That's all.

*Session-ID* is meant to be an end-to-end identifier created by any UA, that goes through ANY form of B2BUA, not just SBC's.  I mean App servers, softswitches, PBX's, IP-IP transcoders, 3PCC servers, MSC's, S-CSCF's, BGCFs, ALG's, and whatever else sits "in the middle".

Frankly if session-id was just for SBC's, I wouldn't bother with an IETF internet draft.  I don't care much about interoperating with the other SBC vendors. :)

-hadriel

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: Friday, February 05, 2010 8:35 AM
> To: Spencer Dawkins
> Cc: Richard Shockey; Hadriel Kaplan; [email-masked]
> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-
> 00.txt
> 
> Hadriel Kaplan wrote:
> 
> > >>  I've re-submitted a draft I originally submitted to the SIP WG back
> > >>  when it was in existence.  The draft defines a session correlation
> > >>  identifier for troubleshooting purposes.
> 
> > >>  > There are several reasons for having a globally unique session
> > >>  > identifier for the same SIP session, which can be maintained
> across
> > >>  > B2BUAs and other SIP middle-boxes.  This draft proposes a new SIP
> > >>  > header to carry such a value: Session-ID.
> 
> Spencer Dawkins adds:
> 
> > I'm remembering that Hadriel had two drafts at about the same time - one
> was
> > a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot
> of
> > confusion during discussions.
> >
> > So I'm hoping that at least some of the objection was caused by
> confusion!
> >
> > https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and
> > https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just
> for
> > the record...
> 
> I agree with Hadriel that the 'secure call id' draft actually solves
> some different problems (and think that draft should certainly be
> progressed - we've already started implementing the ideas in it in some
> of our user agents).
> 
> The problem of correlation across middleboxes of various kinds is
> certainly an important one, and deserving of attention.
> 
> I'd like to point out that there is another draft that helps with some
> of the other more complex scenarios in which one is attempting to
> determine the relationship between different sessions:
> 
>         http://tools.ietf.org/html/draft-worley-references
>         The References Header for SIP
> 
> we've also been using this in our products and found it very useful.
> 
> With respect to what to do about the session-id proposal: I think that
> in some perfect world that we don't live in, it would be better to adopt
> the secure-call-id proposal and also make the rule that such ids MUST
> NOT be changed when passing through a B2BUA; the call-id would then have
> the characteristics that the session-id needs.  I accept, however, that
> this big a change to the handling of call-id by existing products is
> unlikely.
> 
> It seems to me that session-id as proposed is valuable iff we can reach
> a consensus that existing non-proxy middleboxes (whether they are called
> SBCs or Application Servers or whatever) will pass these through
> unmodified, or at least that in some reasonable time they can be
> convinced to start doing so.  Based on the discussion to date, I'm not
> yet convinced of that...
> 
> I wonder whether or not it's time that we bit the bullet and try to
> actually comprehensively write down what the correct and harmful
> behaviors for non-proxy middleboxes are?
> 
>