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
