Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

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


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