Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

From: "Dale Worley" <[email-masked]>
Date: Wed, 03 Dec 2008 12:40:26 -0500

From: Hadriel Kaplan <[email-masked]>
        
        Note the "adversary" so to speak is just that a downstream node
        can get a Call-ID and must not be able to tell from the Call-ID
        it got, what the Session-ID should be, so they can't tell the
        Call-ID was changed by a b2bua.  Of course an upstream node
        would be able to tell - for example the UAC would if it received
        a subscribe for the dialog-event that had a session-id it
        created, with a call-id+tags it didn't.  But then one of the
        main points of this exercise is to make those cases work.  I
        can't guarantee that all operators would want it to work in such
        cases, but for those that don't want it to, nothing will help us
        make it work.
        
There's something I don't understand here.  You mention "received a
SUBSCRIBE for the dialog-event that had a session-id it created, etc."
What does that mean?  I assume you mean that the UAS of the original
call (or something in its near network vicinity) wanted to subscribe to
the dialog events of the UAC, filtering for the one dialog it knows of.
That would be:

	SUBSCRIBE [contact taken from INVITE seen at UAS] SIP/2.0
	Call-Id: [something new]
	Session-Id: [something new]
	Event: dialog;session-id=[session-id of INVITE]

That would go back through the B2BUA (or one of its brethren) because
the Contact as seen at the UAS was munged as necessary by the B2BUA to
ensure that that would happen.  The B2BUA would change the Call-ID, but
it would leave the Session-Id and the Event session-id parameter
unchanged.

But there would be nothing to compare the Event session-id parameter
*to*.  And the Session-Id would have no apparent relationship to the
Call-Id or tags of the SUBSCRIBE as seen at the original UAC (the UAS of
the SUBSCRIBE).

Dale

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 14:31:32 -0500

The idea (and it may well be a half-baked idea) was to add the Session-ID value into the dialog-event package body (the dialog-info XML doc schema in urn:ietf:params:xml:ns:dialog-info namespace) as another XML element.  In other words, to add a "session-id" element wherever a "call-id" element can also be, such that a consumer of that received XML doc, if it understands that element, could try to match its value to one of its known session-id values for its known dialogs, if and only if the "call-id" one failed to match a call-id.  Likewise for other package XML docs that have "call-id".

For the Replaces/Target-Dialog/etc. SIP headers, one idea would be to add another param similar to the call-id param, for session-id.  But that's just one option.  Option 2 was to in fact keep the Session-ID header itself the same for that out-of-dialog INVITE created by a Refer-To, by embedding the Session-ID header in Refer-To.  There's pro's/con's to either approach, and I don't have an opinion on which is right/wrong/better/worse.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Wednesday, December 03, 2008 12:40 PM
>

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 04 Dec 2008 22:18:27 -0500

On Wed, 2008-12-03 at 14:31 -0500, Hadriel Kaplan wrote:
> The idea (and it may well be a half-baked idea) was to add the
> Session-ID value into the dialog-event package body (the dialog-info
> XML doc schema in urn:ietf:params:xml:ns:dialog-info namespace) as
> another XML element.

That's clear and unambiguous, since we assume that each dialog will have
only one session-id associated with it.

> For the Replaces/Target-Dialog/etc. SIP headers, one idea would be to
> add another param similar to the call-id param, for session-id.  But
> that's just one option.  Option 2 was to in fact keep the Session-ID
> header itself the same for that out-of-dialog INVITE created by a
> Refer-To, by embedding the Session-ID header in Refer-To.  There's
> pro's/con's to either approach, and I don't have an opinion on which
> is right/wrong/better/worse.

I think you're getting into a lot of trouble with this.  For one thing,
if a request forks, it creates multiple dialogs.  If the UAC inserted a
session-id, all those dialogs share the same session-id.  Previously,
that situation is disambiguated by identifying a dialog by giving
call-id/from-tag/to-tag.  But session-id alone is ambiguous, so it can't
be used to replace the current dialog identifiers.  And since we assume
that the tags will be changed by B2BUAs, session-id/from-tag/to-tag
won't work at all.

Even worse, at any B2BUA in a dialog, there are multiple dialogs that
share the session-id.  So an incoming INVITE/Replaces specifying a given
session-id is ambiguous unless the dialog-id is provided also.  This
means that if we allow INVITE/Replaces to specify a dialog only with
session-id (or if we allow Replaces to match if the session-id's match
but call-id's don't) we need to allow the recipient of INVITE/Replaces
to respond "matches more than one dialog here".

Here's another nasty case.  Reusing Paul's diagram:

                 |------ C
                 |
        A ------ B
                 |
                 |------ D

Let us suppose that A calls C, establishing two dialogs (A-B and B-C)
that share a session-id.  Now suppose that D executes a "call pickup"
operation by determining the dialog identifiers of the B-C leg and
sending an INVITE/Replaces toward A, or actually, A's avatar on the
interface of B that faces D.

If B passes the INVITE through to A, the Replaces is executed on A, and
nothing particularly strange happens.

But if B decides to short-circuit the INVITE/Replaces by continuing the
A-B dialog and reconnecting it with the new D-B dialog, what happens to
the session-id's?  A-B remains using the session-id sent by A in the
original INVITE, but B-D must continue using the session-id sent by D in
the INVITE/Replaces.  So the two "legs" of the A-D logical dialog will
be using different session-id's, contrary to the declared point of
session-id's.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 13:43:59 -0500

> From: Dale Worley [mailto:[email-masked]]
> Sent: Thursday, December 04, 2008 10:18 PM
>

No - read the (latest) draft.  The to-tag is in fact also used, to dis-ambiguate these things.  And I note that this would mean it can't be changed.  I'm on the fence whether to create a surrogate for that as well. (ugh)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 14:04:45 -0500

> be using different session-id's, contrary to the declared point of

Right, and this is why I said this is not some panacea solve-world-hunger thing.  And in fact why the Session-ID draft has language like "with as high a probability as possible".  I know it's not comfortable language for engineers.  But I am pretty sure there is no solution to this problem space that does not have corner cases. (well... unless you require changing all SIP devices everywhere, which for me is an unacceptable prerequisite)

But anyway, yes B-D has a different Session-ID from A-B, and that's ok.  Had D's INVITE/Replaces gone all the way back to A, then A-D would have ALSO been a new Session-ID.  B is acting as a stand-alone UA with respect to the new Session, and thus follows what I described previously in another email to Paul:
    "Basically, my assertion is that if you receive a SIP request from A as a UAS, and route or fork it to one or more targets (B/C/D) as a UAC, you have created a single dialog-set.  Let's assume it establishes with B.  IF you receive an in-dialog or dialog-referential request from A or B, and act upon that request as the UA without forwarding it back to A or B and the action creates another dialog, (e.g., you create a new INVITE), then I'd argue you're probably creating a new dialog-set; because that's what should have been created had it actually gone back to A or B and they'd created a new dialog.  But really I'd defer to other people's opinions on that."

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Sun, 07 Dec 2008 11:12:34 -0500

On Fri, 2008-12-05 at 13:43 -0500, Hadriel Kaplan wrote:
> No - read the (latest) draft.  The to-tag is in fact also used, to
> dis-ambiguate these things.  And I note that this would mean it can't
> be changed.  I'm on the fence whether to create a surrogate for that
> as well. (ugh)

But B2BUAs now change to-tags, so we don't have the "works in most
current deployments" condition.  Also, to-tags may have the same problem
as call-ids, namely that they reveal the manufacturer of the originating
UA.  I think the mechanism needs to be revised to deal with this.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Sun, 07 Dec 2008 11:18:02 -0500

On Fri, 2008-12-05 at 14:04 -0500, Hadriel Kaplan wrote:
> Right, and this is why I said this is not some panacea
> solve-world-hunger thing.  And in fact why the Session-ID draft has
> language like "with as high a probability as possible".  I know it's
> not comfortable language for engineers.  But I am pretty sure there is
> no solution to this problem space that does not have corner cases.
> (well... unless you require changing all SIP devices everywhere, which
> for me is an unacceptable prerequisite)

I'm losing track of what problem you're attempting to solve.  I thought
the problem was to identify the dialog-sets that are created by "B2BUA
pass-through".  But now it seems that the mechanism only identifies some
of these dialog-sets and doesn't identify others, because any
short-circuiting of INVITE/Replaces (and possibly other call-control
operations) defeats the mechanism.  There's also a problem with using
Session-Id to identify dialogs, as to-tag mangling is not compensated
for.

It seems that the only case that is well-handled is the simplest
PSTN-like call:  A UAC sends an INVITE that does not fork through a
B2BUA to a UAS.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 22:44:35 -0500

> Sent: Sunday, December 07, 2008 11:18 AM
>

On the contrary - it handles forks just fine.  The cases it doesn't "handle" are of two types: (1) not all parties which need to support Session-ID in a given scenario do in fact support it, and (2) when a new dialog is created such that it would have used a new Call-ID even if everything was a proxy and there were only a UAC and UAS.

I would argue case (1) is true for any mechanism we define.  I have yet to see a proposal that does not require more than one party supporting the new mechanism for it to work in all scenarios.  And I'm arguing THAT'S OK.  It's perfectly reasonable that whatever mechanism gets used only works if the parties that need to support it do.  What's important, for me at least, is that when the mechanism doesn't work it doesn't make things worse - i.e., it doesn't cause a failure when previously just Call-ID+tags would have succeeded.  I say that because, at least for me, the idea that we can get all devices to upgrade to whatever mechanism we pick on a flag-day is laughable.  It ain't gonna happen.  So we have to play the cards we're dealt.

For case (2), the gist of it is that Session-ID is essentially a new surrogate for Call-ID.  So if a UAC creates an out-of-dialog request, it would create a new Session-ID, just as it would create a new Call-ID.  When a B2BUA acts on behalf of a UA, such that it creates an out-of-dialog request which that UA would have itself created had the B2BUA not intercepted a message bound for that UA, then the Session-ID it creates would be a new one - again, because the Call-ID itself would have been a new one had the B2BUA not been involved.  For example, if the UAS sends an in-dialog REFER to the B2BUA, and the B2BUA "short-circuits" it and processes it on behalf of the UAC, and creates a brand new INVITE to the referred-to party, then it gets a new Session-ID, because if it had let that REFER go back to the UAC that's exactly what the UAC would have done.  I'm perfectly fine with that.  The original "session" is over, and a new one has been created.  That B2BUA is acting as more than a "dialog-proxy" at that instant.

But if you and others feel that it in fact needs to remain the same contiguous "session" even in that case, I'll change it.  I think it adds complexity, and more devices would have to support the mechanism than otherwise, but that's ok.  Though I still don't think we'd need to support a conference scenario (a scenario where multiple UAC's connect to a conference bridge).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 23:06:58 -0500

> Sent: Sunday, December 07, 2008 11:13 AM
>

Yeah, I've been on the fence about that as I said.  I loathe adding complexity, but I admit it is probably justified for tags.

I wonder if we really need the from-tag at all for this type of thing.  Forget for the moment about any of this and just think of the current Call-ID and tags, and assume there were no B2BUA's.  Is there ever a case where a UAC would generate a request with the same Call-ID as a previous request, but a different from-tag?  The to-tag we needed to identify forked responders generating unique early-dialogs with a common Call-ID, but why did we need the UAC to generate a from-tag? (I'm feeling dumb that I can't figure out the answer)

-hadriel

---

From: Michael Procter <[email-masked]>
Date: Tue, 09 Dec 2008 10:04:21 +0000

Hadriel Kaplan wrote:
> I wonder if we really need the from-tag at all for this type of thing.  Forget for the moment about any of this and just think of the current Call-ID and tags, and assume there were no B2BUA's.  Is there ever a case where a UAC would generate a request with the same Call-ID as a previous request, but a different from-tag?

Registration, but I think that is probably out of scope for what you are
considering!

>   The to-tag we needed to identify forked responders generating unique early-dialogs with a common Call-ID, but why did we need the UAC to generate a from-tag? (I'm feeling dumb that I can't figure out the answer)
>   

In the reverse direction, the presence of a to-tag in a request
indicates an in-dialog request.  Therefore, requiring a from-tag ensures
that requests in the reverse direction can have a to-tag, and thus be
correctly treated as in-dialog.

> -hadriel

Michael

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 15 Dec 2008 11:18:50 -0500

On Tue, 2008-12-09 at 10:04 +0000, Michael Procter wrote:
> >   The to-tag we needed to identify forked responders generating
> unique early-dialogs with a common Call-ID, but why did we need the
> UAC to generate a from-tag? (I'm feeling dumb that I can't figure out
> the answer)
> >   
> 

I'm looking at the code in sipX that works with tags to determine the
status of a SIP message, and though the from-tag is not logically
necessary, it does make the code simpler, as the To and From URIs are
handled more symmetrically.

In addition, it allows the SIP element to extract and compare only the
tags, rather than having to compare the To/From URIs (as is required in
RFC 2543), which is always fraught with problems.

Dale

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Dec 2008 15:00:35 -0600

From tags exist because we put the response-to-forked-request  
disambiguator in the To-tag and needed
to be able later to send a request in the other direction - and we  
needed to do this in a way that was backward
compatible with the 2543 (and a few slightly pre-2543) things around  
at the time.

If I remember things correctly, there was a rev of bis briefly that  
defined to-tags but didn't have from-tags in it at all.
And I _vaguely_ remember discussing the alternative of putting this  
info on the Call-ID in the response instead of To,
but that fell away to some backwards-compatibility problems (but I  
could be misremembering).

RjS