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

> -----Original Message-----
> From: Dale Worley [mailto:[email protected]]
> Sent: Thursday, December 04, 2008 10:18 PM
>
> 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.

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
_______________________________________________
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