Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02

From: Peter Musgrave <[email-masked]>
Date: Tue, 20 Jul 2010 06:18:53 -0400

Hi Hadriel,

Overall I think the draft is in good shape.

I think the work is useful (in fact it's already in my code).

I have an observation about 5.3

Let me restate the example:

Bob calls Alice (sessionID=AB)

Bob calls Charlie (sessionID=BC)

Bob REFERs Alice to Charlie (ReferTo: sessionID=BC)

>From Alice's perspective the call to C is a continuation of the call to B -
so I would have expected sessionID=AB for the new call. (From C's
perspective it get s a new INVITE which replaces a previous one - but this
is not as strong a connection in my mind as the call coupling at A).

I think using the AB session ID in the Refer may have more value in
following a REFER chain.

8 Examples:

I think a REFER example would be valuable. Both a Refer-To URI example and
an INVITE with Replaces example which makes concrete the case in 5.3.

Nits:

(Abstract) s/Troubleshooting/troubleshooting/

3. I prefer "dialog-creating" to "out-of-dialog" (but I can live with
out-of-dialog)

Now to go and sip some Scotch….

Peter Musgrave

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 14:38:04 +0200

Peter,

But what if we use Join rather than Replaces, to join rather than replace session BC? There is certainly a strong argument that Alice's leg would be part of session ID BC, rather than AB, in this case. Any opinions whether we should treat Join and Replaces the same or differently?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Musgrave
> Sent: 20 July 2010 11:19
> To: Hadriel Kaplan; dispatch mailing list
> Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02
> 
> Hi Hadriel, 
> 
> 
> 
> 
> From Alice's perspective the call to C is a continuation of 
> the call to B - so I would have expected sessionID=AB for the 
> new call. (From C's perspective it get s a new INVITE which 
> replaces a previous one - but this is not as strong a 
> connection in my mind as the call coupling at A). 
> 
> 
> 
> 
> I think using the AB session ID in the Refer may have more 
> value in following a REFER chain. 
> 
> 
> 
> 
> 8 Examples:
> 
> I think a REFER example would be valuable. Both a Refer-To 
> URI example and an INVITE with Replaces example which makes 
> concrete the case in 5.3. 
> 
> 
> 
> 
> Nits:
> 
> 3. I prefer "dialog-creating" to "out-of-dialog" (but I can 
> live with out-of-dialog)
> 
> 
> 
> 
> Now to go and sip some Scotch....
> 
> 
> 
> 
> Peter Musgrave
> 
> 
> 
> 
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 20 Jul 2010 09:15:47 -0400

Hi John,

Based on quick re-read of RFC3911 I see two cases:
1) a Join in an INVITE generated due to a REFER
2) a Join in an INVITE in which the dialog info is conveyed out-of-band

I think in (1) it's to some degree a matter of taste as to which sessionID
is preferred. It depends on whether you're following logs at C or A. My
opinion is that in the case of Join id=BC makes sense - but for a REFER
without a Join I prefer AB.

For (2) the session ID should match the dialog info and also presumably has
to be conveyed out-of-band.

Peter Musgrave

On Tue, Jul 20, 2010 at 8:38 AM, Elwell, John <
[email-masked]> wrote:

> Peter,
>
> But what if we use Join rather than Replaces, to join rather than replace
> session BC? There is certainly a strong argument that Alice's leg would be
> part of session ID BC, rather than AB, in this case. Any opinions whether we
> should treat Join and Replaces the same or differently?
>
> John
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 10:53:22 -0400

> But what if we use Join rather than Replaces, to join rather than replace session BC? There is certainly a strong argument that Alice's leg would be part of session ID BC, rather than AB, in this c…

IMO there is no *right* answer to this - it all depends on your intended 
use of the session id. I think you have to recognize that a choice must 
be made, and doing so will bias the uses to which the id will be helpful.

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Jul 2010 13:39:06 -0400

Hey Peter,
Comments inline...

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Tuesday, July 20, 2010 6:19 AM
> From Alice's perspective the call to C is a continuation of the call to B
> - so I would have expected sessionID=AB for the new call. (From C's

It's arguable either way I think, without any "right" way.  What I tried to do was make it such that it would be easier to "trace" the messages in logs, to troubleshoot problems.  So for the Bob-Alice leg, when Bob sends a REFER to Alice, the REFER's Session-ID header *is* AB, but the Refer-To URI has sessionID=BC; so that REFER message helps Alice figure out what the session-id trace is across the two dialogs in her logs.  Charlie gets Session-ID header of BC, so it's traced for him as well in his logs.  In other words the logs on Alice and Charlie each individually trace the session-id migration/move, without needing to see the other's logs.

If the Refer-To used sessionID=AB, and Alice thus used Session-ID header of AB in the INVITE w/replaces to Charlie, the logs on Alice would be clean, but Charlie's would only correlate them using the Call-ID/tags - if those match then all's well - but since the point is to troubleshoot when things _don't_ work, then if they don't match nothing else in the message helps Charlie figure out what went wrong.

Make sense?

Also, as a side note, the REFER from Bob to Alice doesn't actually move Bob's dialog to Alice (AB) - there's at least the implicit Subscription dialog usage of that still alive.  Whereas the INVITE w/replaces does replace the BC dialog.  So from that perspective it seemed right to me to make the new Alice-Charlie dialog the replaced BC one.

> an INVITE with Replaces example which makes concrete the case in 5.3.

Definitely.  I was thinking of doing it for this rev, but then I figured the odds of it changing would be high so I didn't want to have to redo the example until it settled down.  (i.e., I'm lazy)

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 20 Jul 2010 14:09:29 -0400

Hi Hadrial,

I agree it's arguable - and since you're the one doing the work I'm happy to
live with the way you see it.

I see your point about the examples. My counter-point is I'm lazy too and
since there were no examples I had to actually read the text closely.
Perhaps all part of your nefarious plan thinly disguised as lazyness?

Peter Musgrave

On Tue, Jul 20, 2010 at 1:39 PM, Hadriel Kaplan <[email-masked]>wrote:

> It's arguable either way I think, without any "right" way.  What I tried to
> do was make it such that it would be easier to "trace" the messages in logs,
> to troubleshoot problems.  So for the Bob-Alice leg, when Bob sends a REFER
> to Alice, the REFER's Session-ID header *is* AB, but the Refer-To URI has
> sessionID=BC; so that REFER message helps Alice figure out what the
> session-id trace is across the two dialogs in her logs.  Charlie gets
> Session-ID header of BC, so it's traced for him as well in his logs.  In
> other words the logs on Alice and Charlie each individually trace the
> session-id migration/move, without needing to see the other's logs.
>
> If the Refer-To used sessionID=AB, and Alice thus used Session-ID header of
> AB in the INVITE w/replaces to Charlie, the logs on Alice would be clean,
> but Charlie's would only correlate them using the Call-ID/tags - if those
> match then all's well - but since the point is to troubleshoot when things
> _don't_ work, then if they don't match nothing else in the message helps
> Charlie figure out what went wrong.
>
> Make sense?
>
> Also, as a side note, the REFER from Bob to Alice doesn't actually move
> Bob's dialog to Alice (AB) - there's at least the implicit Subscription
> dialog usage of that still alive.  Whereas the INVITE w/replaces does
> replace the BC dialog.  So from that perspective it seemed right to me to
> make the new Alice-Charlie dialog the replaced BC one.
>
>
> > 8 Examples:
> Definitely.  I was thinking of doing it for this rev, but then I figured
> the odds of it changing would be high so I didn't want to have to redo the
> example until it settled down.  (i.e., I'm lazy)
>
> -hadriel
>