Subject: [Insipid] REQ10: evaluation

From: James Polk <[email-masked]>
Date: Mon, 27 Aug 2012 18:28:58 -0500

INSIPID

Here is the set of use-cases and requirements discussed in Vancouver. 
We are to come to consensus on each of these (or not), and if we 
agree the use-case or requirement should be in the document, we need 
to determine acceptable wording for each. The Subject: line will 
contain the specific topic (which use-case or requirement) for this 
thread. PLEASE do not cross contaminate the threads. Any new topic 
SHOULD have its own Subject line. The chairs will monitor and call 
for consensus on each use-case and requirement (and wording of each).

Please make constructive suggestions regarding each you care about.

The Section numbers will be reordered once consensus has been reached 
on all items we're covering, so don't worry about that part.

REQ10: It must be possible to correlate two end-to-end sessions when 
the sessions are created by a third party controller using 3PCC 
procedures as described  shown in Figure 1, as described in RFC 3725.

---

From: Brett Tate <[email-masked]>
Date: Tue, 28 Aug 2012 06:19:52 -0700

> REQ10: It must be possible to correlate two end-to-end 
> sessions when the sessions are created by a third party 
> controller using 3PCC procedures as described shown in 
> Figure 1, as described in RFC 3725.

As far as I know, this requirement should not be added since it does not meet the "one in / one out case where the To/From header fields could have been preserved" situation (unless the requirement can be met without informing A of the B's Session-ID fragment).  Thus I think that the requirement should not be included within draft.

If such 3PCC specific requirements are actually within scope for insipid, the requirement should clarify if implying that a Session-ID can change within a dialog.  REQ10 should also clarify if only applicable to specific 3PCC procedure shown within figure 1 or also applicable to all of the other 3PCC procedures and call flows (such as Figure 13 or reconnecting two existing dialogs which have different existing Session-ID values).

Thanks,
Brett

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 00:03:10 -0400

Brett,

I've said many times that I believe it's absolutely a requirement that
session IDs change in a dialog.  This would be true of 3PCC cases where a
device initiates a call between two people.  It would also be the case where
a PBX joins to call legs together.  Not to be confused with the "join"
header in SIP, what I'm referring to is the case where Alice calls Bob, Bob
calls Carol, and Bob transfers the call to Carol.  The PBX sends an INVITE
to Alice and Sue (in whatever order) to get the two communicating.

So, whereas we had (A || B) as a call then then (B || C) as a call, but then
after the transfer, we have (A || C) as the only call.

We need this kind of behavior (where the Session-ID changes) since we want
to be able to identify a session end-to-end and those ends might move around
mid-call.

What we do not want, I would hope, is that we end up with a solution where
we have two values (A || B) and (B || C) when B isn't even in the call.  It
very much defeats the purpose of having an end-to-end identifier, as it does
not go end-to-end.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brett Tate
> Sent: Tuesday, August 28, 2012 9:20 AM
> To: [email-masked]
> Subject: Re: [Insipid] REQ10: evaluation
> 
> As far as I know, this requirement should not be added since it does not
> meet the "one in / one out case where the To/From header fields could have
> been preserved" situation (unless the requirement can be met without
> informing A of the B's Session-ID fragment).  Thus I think that the
> requirement should not be included within draft.
> 
> If such 3PCC specific requirements are actually within scope for insipid,
> the requirement should clarify if implying that a Session-ID can change
> within a dialog.  REQ10 should also clarify if only applicable to specific
> 3PCC procedure shown within figure 1 or also applicable to all of the
> other 3PCC procedures and call flows (such as Figure 13 or reconnecting
> two existing dialogs which have different existing Session-ID values).
> 
> Thanks,
> Brett
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Brett Tate <[email-masked]>
Date: Wed, 29 Aug 2012 04:09:04 -0700

Hi Paul,

> I've said many times that I believe it's absolutely a 
> requirement that session IDs change in a dialog.  

Since allowing the session ID to change appears (per Keith's email) to require changing the insipid charter, should the request to change the charter occur now or during the WGLC of draft-ietf-insipid-session-id-reqts and draft-ietf-insipid-session-id?  More specifically, I'm wondering if insipid should continue working on the drafts as though it won't subsequently have any problems changing the charter to accommodate the requirements and solution.

http://www.ietf.org/mail-archive/web/insipid/current/msg00255.html

Thanks,
Brett

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 12:13:38 -0400

Brett,

If changing the charter is what it take, yes.  But is it necessary?  The
charter says we want to have an identifier that identifies a "session from
the point of origin ... to the ultimate point of termination."  There are a
few points I'd like to make on that sentence:

1) If Alice calls Bob and the call passes through a forking proxy, would we
not like to have separate ID for B1, B2, B3 (i.e., A || B1, A || B2, A ||
B3)?  I would, because each of those are pending sessions.  We do not know
which Bob will answer, but we would like to trace signaling messages
end-to-end for each.

2) If a call is transferred mid-call without REFER, I assume service
providers would like to be able to know that a call coming into the
enterprise and then back out to a different endpoint is actually the same
call.  (This was the main reason we propose using two UUIDs in the first
place, allowing those to change mid-call.)

3) If a call is transferred using REFER, I would still like to be able to
associate Alice's UUID with the original call.  Thus, when Alice sends an
INVITE in response to REFER, she would continue to use the same UUID.

I'm not opposed to the wording in that sentence, as changing it to consider
forked cases would make it overly complex.  Perhaps the one thing we need to
add is that we have to recognize the fact that a call does not stay
permanently fixed at a point of termination.  For that matter, the point of
origin is not necessarily fixed. Since either Alice or Bob can be exchanged
for a different endpoint (or multiple endpoints), we need a mechanism that
is flexible enough to accommodate those changes.  That's what our proposal
was about from the start, but somehow the charter is interpreted more
strictly and, as such, does not consider pre-answer situations or mid-call
interactions.

Paul

> From: Brett Tate [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2012 7:09 AM
> To: Paul E. Jones; [email-masked]
> Subject: RE: [Insipid] REQ10: evaluation
> 
> Hi Paul,
> 
> > session IDs change in a dialog.
> 
> Since allowing the session ID to change appears (per Keith's email) to
> require changing the insipid charter, should the request to change the
> charter occur now or during the WGLC of draft-ietf-insipid-session-id-
> reqts and draft-ietf-insipid-session-id?  More specifically, I'm wondering
> if insipid should continue working on the drafts as though it won't
> subsequently have any problems changing the charter to accommodate the
> requirements and solution.
>