Subject: Re: [Insipid] Is session ID in conference in scope of the WG

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 4 Aug 2012 20:12:18 +0200

(As WG cochair)

I have been asked about the third-party call controller cases.

They have to fall for the same reason as the conference case. 

The only use case that survives on the one in / one out case where the To/From header fields could have been preserved.

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith)
> Sent: 03 August 2012 19:00
> To: [email-masked]
> Subject: Is session ID in conference in scope of the WG
> 
> [As WG cochair]
> 
> The chairs and the associated AD (Gonzalo) discussed this and came to the
> conclusion that creation of an identifier that is preserved across
> conferences is out of scope according to the INSIPID working group charter.
> 
> The reasoning for this is that the charter is bound to problem space for
> which a common To/From header field is used.
> 
> We will therefore not include a conferencing use case, or attempt to
> derive requirements from one.
> 
> By the same argument, transfers are also out of scope at first sight, but
> the To and From headers are preserved in the Refer so it can be argued
> from that perspective that it is in scope.
> 
> So we will continue to include the transfer use case.
> 
> Obviously discussion of this is allowed, but please remember that any such
> discussion is likely to a rechartering discussion (with consequent delay)
> rather than a discussion on the contents of the requirements document.
> 
> Regards
> 
> Keith

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 5 Aug 2012 21:22:23 +0300

Hi,

people may want to re-read the discussions we had about the scope of
this WG when we were working on the charter (e.g., the thread with
subject "[dispatch] new charter version for Session-id" on the DISPATCH
mailing list) in order to get some background on what was discussed at
that point.

Cheers,

Gonzalo

On 04/08/2012 9:12 PM, DRAGE, Keith (Keith) wrote:
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
> 
>

---

From: James Polk <[email-masked]>
Date: Mon, 06 Aug 2012 18:17:21 -0500

>mailing list) in order to get some background on what was discussed at

I don't remember 3PCC ever being discussed then, therefore it would 
be out fo scope implicitly (but I have come to believe this is a good 
use-case we should include), but transfer was always talked about as 
something we include, now it's on the bubble and I can't understand why...?

James

> > The only use case that survives on the one in / one out case 
> where the To/From header fields could have been preserved.
> >
> > Regards
> >
> > Keith
> >
> >

---

From: James Polk <[email-masked]>
Date: Mon, 06 Aug 2012 18:19:11 -0500

At 01:12 PM 8/4/2012, DRAGE, Keith (Keith) wrote:
>The only use case that survives on the one in / one out case where 
>the To/From header fields could have been preserved.

Keith

I'm not fully following your "one in / one out case". Is it Figure 
1's call flow from RFC 3725?

James

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 7 Aug 2012 13:41:37 +0000

Hi,

I looked back through the thread and found this discussion which related to 3PCC http://www.ietf.org/mail-archive/web/dispatch/current/msg03950.html. 

In this discussion it is my interpretation that 3PCC is consider in scope. The the following snippet is taken from this thread.

Paul Kyzivat asks the question.

>> How do you feel about a 3PCC controller? Is it a B2BUA? If it does a
>> transfer then it goes through stages when it has two dialogs, then
>> three, then two. From past discussions, I think you expect there will be
>> more than one session-id covering that.

The response from Paul Jones.

>A PBX-type device would be a B2BUA in my mind and, yes, there would be
>different Session-IDs since there would be different devices end-to-end.  In
>this case, the B2BUA truly is just an intermediary device, not a terminating
>device.

My interpretation is this discussion is that 3PCC is within scope as the 3PCC controller is "just an intermediary device" it is just confirmation that a 3PCC transfer results in a new session identifier as per the basic endpoint initiated case.

In any case in the basic 3PCC call flow the result following the initial dialog establishment is a simple 2 party call which is no different to the case when the flow was initiated by an endpoint (i.e. 2 dialogs with a B2BUA in the middle which mangles the dialog identifiers) so I don't understand why it would be considered out of scope.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James Polk
> Sent: 07 August 2012 00:17
> To: Gonzalo Camarillo; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Insipid] Is session ID in conference in scope of the WG
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Aug 2012 16:38:52 +0000

I didn't get that view from re-reading that thread.

But anyway just because it's out of scope doesn't mean a proposed solution can't cover it - if even by accident/coincidence of its solution design.
It just means we can't have requirements to cover it, and proposed solutions don't need to address it.  Both draft-jones and draft-kaplan models happen to address the "simple" 3PCC case, and the draft-jones might try to address the more complicated cases (I think).

-hadriel

---

From: Brett Tate <[email-masked]>
Date: Tue, 21 Aug 2012 03:14:23 -0700

Hi,

Since the topic of changing Session-ID within a dialog is still being raised, I thought that I'd ask again about such requirements/use-cases since it doesn't appear to meet the criteria for the "one in / one out case where the To/From header fields could have been preserved" situation.

Is the Session-ID allowed to change within a dialog?  More specifically (as discussed within the following threads) if a B2BUA connects two existing dialogs which have different Session-ID values, is the Session-ID required to be renegotiated and/or changed?

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

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

Thanks,
Brett

> Behalf Of DRAGE, Keith (Keith)
> Sent: Saturday, August 04, 2012 2:12 PM
> To: [email-masked]
> The only use case that survives on the one in / one out case where the
> To/From header fields could have been preserved.
> 
> Regards
> 
> Keith
> 
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Aug 2012 11:28:51 +0000

I agree that it might be that the solution accidently is able to handle the 3PCC case but I was rather hoping that it we could explicitly state this as a requirement.

It seems strange to me that the issue of 3PCC is not explicitly covered in a working group established because of B2BUA behavior. 3PCC is a very common function of a SIP B2BUA and so should be covered in my opinion and I thought that was the opinion of the working group at IETF84.

Regards
Andy

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 17 August 2012 17:39
> To: Hutton, Andrew
> Cc: James Polk; Gonzalo Camarillo; DRAGE, Keith (Keith);
> [email-masked]
> But anyway just because it's out of scope doesn't mean a proposed
> solution can't cover it - if even by accident/coincidence of its
> solution design.
> It just means we can't have requirements to cover it, and proposed
> solutions don't need to address it.  Both draft-jones and draft-kaplan
> models happen to address the "simple" 3PCC case, and the draft-jones
> might try to address the more complicated cases (I think).
> 
> -hadriel
> 
> 
> > I looked back through the thread and found this discussion which
> related to 3PCC http://www.ietf.org/mail-
> archive/web/dispatch/current/msg03950.html.
> >
> > In this discussion it is my interpretation that 3PCC is consider in
> scope. The the following snippet is taken from this thread.
> >
> > My interpretation is this discussion is that 3PCC is within scope as
> the 3PCC controller is "just an intermediary device" it is just
> confirmation that a 3PCC transfer results in a new session identifier
> as per the basic endpoint initiated case.
> >
> > In any case in the basic 3PCC call flow the result following the
> initial dialog establishment is a simple 2 party call which is no
> different to the case when the flow was initiated by an endpoint (i.e.
> 2 dialogs with a B2BUA in the middle which mangles the dialog
> identifiers) so I don't understand why it would be considered out of
> scope.
> >
> > Regards
> > Andy
> >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Aug 2012 11:38:02 +0000

Hi All,

Due to the discussion on the scope of the INSIPID work I asked the SIPREC working group what requirements and/or dependencies that SIPREC work has on the INSIPID session identifier.

The consensus of the SIPREC group appears to be that there is no dependency on INSIPID and that any end to end session identifier would simple be a nice to have for SIPREC and would could be made use of using the SIPREC metadata extension mechanism.

Regards
Andy (SIPREC Co-Chair).

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 21 Aug 2012 09:41:11 -0400

Andy - 

Morbidly curious as to whether the lack of dependency is a result of concerns with the session ID delivery timeline or potential concerns with Session ID construction?

Cheers,

Gonzalo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Aug 2012 13:53:07 +0000

Hi Gonzalo,

Neither really it is simply that it is desirable in SIPREC to have an end to end session identifier so that recordings that relate to the same communication session can be correlated but it is not essential to the recording mechanism.

Therefore if INSIPID is successful we can use the resulting session identifier and place it in the SIPREC metadata but the basic metadata model is not dependant on this.

Regards
Andy

> From: Gonzalo Salgueiro [mailto:[email-masked]]
> Sent: 21 August 2012 14:41
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [Insipid] SIPREC and the INISIPID SessionID.
> 
> Andy -
> 
> Morbidly curious as to whether the lack of dependency is a result of
> concerns with the session ID delivery timeline or potential concerns
> with Session ID construction?
> 
> Cheers,
> 
> Gonzalo
> 
> > Due to the discussion on the scope of the INSIPID work I asked the
> SIPREC working group what requirements and/or dependencies that SIPREC
> work has on the INSIPID session identifier.
> >
> > The consensus of the SIPREC group appears to be that there is no
> dependency on INSIPID and that any end to end session identifier would
> simple be a nice to have for SIPREC and would could be made use of
> using the SIPREC metadata extension mechanism.
> >
> > Regards
> > Andy (SIPREC Co-Chair).