Subject: [Insipid] Revised requirements document

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 29 May 2012 15:45:39 -0400

Folks,

As requested, I posted a revised version of the INSIPID requirements
document, taking into consideration the discussions from the call today.
Here's the text:

http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01

Note that Requirement 1a needs to be completed.  I'd be delighted if someone
could propose some wording for that.

As discussed on the call, the meaning of requirement 6 was changed quite
substantially in meaning from the -00 draft.  We need to decide exactly what
meaning we want or introduce a new requirement if we want to both hide
information and also not reveal that an SBC, for example, might have changed
any of that information.

Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 30 May 2012 08:53:31 +0000

Hi,

Yesterday in the call we did not discuss the use cases at all which I think we need to do as these are from what the requirements are derived.

I think it is important to understand what use cases are within scope of INSIPID I would like to see the document restructured to describe real use cases and the derived use cases. I think the RTCWEB use case and requirements draft is a good example of how such requirements drafts should look like. See http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-07. 

The current draft currently contains the following use cases to which I have some comments.

     * End-to-end identification of a communication session

This is the basic case and as long as we all agree what is meant by a "Communication Session" then it is ok however I would like to see it reworded in to the form of a real use case.

     * Association of session signaling and media flows, made possible
       by including the session identifier in media-related messages
       (e.g., RSVP or RTCP)

I don't think that this use case is within scope of INSIPID which is limited to association at the signaling level. Association of media streams should probably done at the SDP level if needed. We could within INSIPID try to make sure that any new identifier is in a suitable format to be carried in other protocols but I don't think we want to specify procedures for including it in for example RTCP.

     * Identification of devices taking part in the same multipoint
       conference

Should this be "Association of sessions taking part in the same multipoint conference"? However I think it should be reworked in to a use case.

     * Tracking sessions transferred from one endpoint to another

Does this need rewording in the form of a use case? I think we will need a few transfer / redirection use cases to really flesh out the requirements.

     * Facilitate the recording of SIP sessions and correlating those
       Sessions

This is not a use case and does not add any new requirements over the 1st basic end to end identification case.

     * Logging for the purposes of accounting, billing, debugging,
       communication tracking (such as for security purposes in case of
       theft of service), etc.

Again these are not use cases from which specific requirements can be derived.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul E. Jones
> Sent: 29 May 2012 20:46
> To: [email-masked]
> Subject: [Insipid] Revised requirements document
> 
> Folks,
> 
> document, taking into consideration the discussions from the call
> today.  Here's the text:
> Note that Requirement 1a needs to be completed.  I'd be delighted if
> someone could propose some wording for that.
> 
> As discussed on the call, the meaning of requirement 6 was changed
> quite substantially in meaning from the -00 draft.  We need to decide
> exactly what meaning we want or introduce a new requirement if we want
> to both hide information and also not reveal that an SBC, for example,
> might have changed any of that information.
> 
> Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 30 May 2012 09:58:27 +0000

Paul,

IMO, REQ-5 and REQ-6 shall be merged together to indicate that "session-id mechanism MUST not reveal any form of identity in REQ-5 and any form of SIP messages in REQ-6".

REQ-6 is important because it provides confidence to the operator/admin that session-id is safe to be passed across in SBC/PBX. In case it is possible to use any of the existing SIP headers/body, IMO there is no need to new session-id itself. AFAIK, there is no SIP headers/body exists which qualify for session-id as of now.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, May 30, 2012 1:16 AM
To: [email-masked]
Subject: [Insipid] Revised requirements document

Folks,

As requested, I posted a revised version of the INSIPID requirements document, taking into consideration the discussions from the call today.  Here's the text:
http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts-01

Note that Requirement 1a needs to be completed.  I'd be delighted if someone could propose some wording for that.

As discussed on the call, the meaning of requirement 6 was changed quite substantially in meaning from the -00 draft.  We need to decide exactly what meaning we want or introduce a new requirement if we want to both hide information and also not reveal that an SBC, for example, might have changed any of that information.

Paul

---

From: Laura Liess <[email-masked]>
Date: Thu, 31 May 2012 10:35:46 +0200

Partha,

2012/5/30 Ravindran, Parthasarathi <[email-masked]>:

>
> and any form of SIP messages in REQ-6.

I think you meant here "any parts of the SIP message (header, body)" .
Is this correct or did you thought of something else?

If this is what you mean, I am OK with it.

Kind regards
Laura

>
>
>
> REQ-6 is important because it provides confidence to the operator/admin that
> session-id is safe to be passed across in SBC/PBX. In case it is possible to
> use any of the existing SIP headers/body, IMO there is no need to new
> session-id itself. AFAIK, there is no SIP headers/body exists which qualify
> for session-id as of now.
>
>
>
> Thanks
>
> Partha
>
>
>
> Here’s the text:
> Note that Requirement 1a needs to be completed.  I’d be delighted if someone
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 31 May 2012 08:38:36 +0000

Laura,

It is good to hear that we are in the same page about REQ-6 that "any parts of the SIP message (header, body)"

Thanks
Partha

>From: Laura Liess [mailto:[email-masked]]
>Sent: Thursday, May 31, 2012 2:06 PM
>To: Ravindran, Parthasarathi
>Cc: [email-masked]; Paul E. Jones
>Subject: Re: [Insipid] Revised requirements document
>
>Partha,
>
>> REQ-6 is important because it provides confidence to the
>> operator/admin that session-id is safe to be passed across in SBC/PBX.
>> In case it is possible to use any of the existing SIP headers/body,
>> IMO there is no need to new session-id itself. AFAIK, there is no SIP
>> headers/body exists which qualify for session-id as of now.
>>
>>
>>
>> Thanks
>>
>> Partha
>>
>>
>>
>today.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 31 May 2012 09:49:55 -0400

> I think it is important to understand what use cases are within scope of
> INSIPID I would like to see the document restructured to describe real use
> cases and the derived use cases. I think the RTCWEB use case and
> requirements draft is a good example of how such requirements drafts
> should look like. See http://tools.ietf.org/html/draft-ietf-rtcweb-use-
> cases-and-requirements-07.

Agreed, that's a nice format.  Input solicited :-)

> This is the basic case and as long as we all agree what is meant by a
> "Communication Session" then it is ok however I would like to see it
> reworded in to the form of a real use case.

Can someone provide the text?  I'll put it in.

> I don't think that this use case is within scope of INSIPID which is
> limited to association at the signaling level. Association of media
> streams should probably done at the SDP level if needed. We could within
> INSIPID try to make sure that any new identifier is in a suitable format
> to be carried in other protocols but I don't think we want to specify
> procedures for including it in for example RTCP.

You're correct, though I still think it is important that we do not use
something that does not lend itself to signaling and media correlation.
That might be outside the charter, but it ought not be outside our thinking
of the problem.  If we actually did use this value to correlate signaling
and media, it would be in a different draft. So, yes, outside of INSPID.  I
just don't want to see us do something that would preclude this possibility,
though I fully agree it's not a primary objective.

> Should this be "Association of sessions taking part in the same multipoint
> conference"? However I think it should be reworked in to a use case.

Yes, that would be a better word to use.
 
> Does this need rewording in the form of a use case? I think we will need a
> few transfer / redirection use cases to really flesh out the requirements.

An expanded use case, as with others, might be useful.

> basic end to end identification case.

This came from the SIPREC work.  Somebody working in that area might have a
say here.

> Again these are not use cases from which specific requirements can be

Requirements can be derived.  For example, this requirement might result in
the construction of an ID suitable for logging.  I'm sure we would have done
that, anyway, but there are logging challenges with one solution versus
another.  For example, in the solution we propose, there Alice and Bob have
UUIDs.  If Alice wants to log the initial INVITE she sends, it would not be
a complete Session-ID, but only her UUID.  We need to consider message flows
and logging.

Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 31 May 2012 15:46:30 +0000

Andy,

<snip>
>> This is not a use case and does not add any new requirements over the
>> 1st basic end to end identification case.
>
>This came from the SIPREC work.  Somebody working in that area might
>have a say here.
</snip>

I have requested to add this usecase as session in INSIPID context shall be mapped to Communication Session(CS) in terms of SIPREC. 
	
Thanks
Partha

>Sent: Thursday, May 31, 2012 7:20 PM
>To: 'Hutton, Andrew'; [email-masked]
>> I think it is important to understand what use cases are within scope
>> of INSIPID I would like to see the document restructured to describe
>> real use cases and the derived use cases. I think the RTCWEB use case
>> and requirements draft is a good example of how such requirements
>> drafts should look like. See
>> http://tools.ietf.org/html/draft-ietf-rtcweb-use-
>> streams should probably done at the SDP level if needed. We could
>> within INSIPID try to make sure that any new identifier is in a
>> suitable format to be carried in other protocols but I don't think we
>> want to specify procedures for including it in for example RTCP.
>
>That might be outside the charter, but it ought not be outside our
>thinking of the problem.  If we actually did use this value to correlate
>signaling and media, it would be in a different draft. So, yes, outside
>of INSPID.  I just don't want to see us do something that would preclude
>this possibility, though I fully agree it's not a primary objective.
>
>> Should this be "Association of sessions taking part in the same
>> multipoint conference"? However I think it should be reworked in to a
>use case.
>
>> Does this need rewording in the form of a use case? I think we will
>> need a few transfer / redirection use cases to really flesh out the
>requirements.
>
>> This is not a use case and does not add any new requirements over the
>> 1st basic end to end identification case.
>
>This came from the SIPREC work.  Somebody working in that area might
>have a say here.
>
>Requirements can be derived.  For example, this requirement might result
>in the construction of an ID suitable for logging.  I'm sure we would
>have done that, anyway, but there are logging challenges with one
>solution versus another.  For example, in the solution we propose, there
>Alice and Bob have UUIDs.  If Alice wants to log the initial INVITE she
>sends, it would not be a complete Session-ID, but only her UUID.  We
>need to consider message flows and logging.
>
>Paul
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 31 May 2012 16:08:58 +0000

Hi Partha,

Understood but it needed to be worded as a use case.

The use case could be something like this.

A SIP Session is established between UA-A and UA-B with a SIP B2BUA acting as a middlebox. Both UA-A and UA-B establish a recording session with a session recording server (SRS) using the SIPREC protocol. The SRS needs to be able to determine from the metadata provided by UA-A and UA-B that the media streams are associated with the same communication session (CS).

The assumption is that the SIPREC metadata from both UA-A and UA-B would include the session identifier for the CS.

Regards
Andy

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 31 May 2012 16:47
> To: Paul E. Jones; Hutton, Andrew; [email-masked]
> Subject: RE: [Insipid] Revised requirements document
> 
> Andy,
> 
> <snip>
> I have requested to add this usecase as session in INSIPID context
> shall be mapped to Communication Session(CS) in terms of SIPREC.
> 
> Thanks
> Partha
> 
> >> The current draft currently contains the following use cases to
> which
> >> I have some comments.
> >>
> >> Again these are not use cases from which specific requirements can
> be
> >> derived.
> >

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 31 May 2012 16:49:29 +0000

Hi Andy,

Your below mentioned usecase is one of the usecase related to SIPREC. Another two SIPREC usecase comes to my mind immediately are

1) B2BUA+SRC could include session-identifier in the SIPREC metadata which helps SRS to retrieve non-SIPREC(Call Centre specific) metadata. Even though this usecase is complicated, I'm seeing most of the deployment depends upon the proprietary IP PBX vendor's session-id to make this happen as of now.

2) SRS could send session-identifier as part of SRS-initiated session wherein SRC shall start recording the corresponding (communication) session.  Your SIPREC mail (http://www.ietf.org/mail-archive/web/siprec/current/msg03192.html) :-)

As long as session-id meets one of the SIPREC usecase, it shall be used in other use cases as well. So, I agree with your wordings.

Thanks
Partha

>From: Hutton, Andrew [mailto:[email-masked]]
>Sent: Thursday, May 31, 2012 9:39 PM
>To: Ravindran, Parthasarathi; Paul E. Jones; [email-masked]
>A SIP Session is established between UA-A and UA-B with a SIP B2BUA
>acting as a middlebox. Both UA-A and UA-B establish a recording session
>with a session recording server (SRS) using the SIPREC protocol. The SRS
>needs to be able to determine from the metadata provided by UA-A and UA-
>B that the media streams are associated with the same communication
>session (CS).
>
>The assumption is that the SIPREC metadata from both UA-A and UA-B would
>include the session identifier for the CS.
>
>Regards
>Andy
>
>
>
>
>
>> >> of INSIPID I would like to see the document restructured to
>> >> describe real use cases and the derived use cases. I think the
>> >> RTCWEB use
>> case
>> >> "Communication Session" then it is ok however I would like to see
>> >> it reworded in to the form of a real use case.
>> >
>> >> I don't think that this use case is within scope of INSIPID which
>> >> is limited to association at the signaling level. Association of
>> >> media streams should probably done at the SDP level if needed. We
>> >> could within INSIPID try to make sure that any new identifier is in
>> >> a suitable format to be carried in other protocols but I don't
>> >> think
>> we
>> >>        communication tracking (such as for security purposes in
>> >> case
>> >of
>> >>        theft of service), etc.
>> >>