Subject: [siprec] *draft* draft-ietf-siprec-req-01.txt

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 22 Jul 2010 01:20:20 -0700

I've reviewed the comments posted to the mailing list about the
requirements document and addressed them in a working draft of what will
become the -01 version.  See
http://kenrehor.com/ietf/siprec/draft-ietf-siprec-req-01.txt

Ken

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Jul 2010 15:18:03 +0200

Ken,

Thanks. As a result you should be able to close some of the tickets on the tracker, e.g., #28, #30, #32 and #33 at least. Please do so as appropriate.

We still have lots of open tickets - clearly we can't discuss them all in Maastricht, so please try to drive some of them forward on the list. Also would others please help by kicking off discussion again on some of these issues, some of which have been around for a couple of months or so?

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ken Rehor (krehor)
> Sent: 22 July 2010 09:20
> To: [email-masked]
> Subject: [siprec] *draft* draft-ietf-siprec-req-01.txt
> 
> I've reviewed the comments posted to the mailing list about 
> the requirements document and addressed them in a working 
> draft of what will become the -01 version.  See

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2010 11:06:15 -0400

Ken,

I think this is good. Some odds and ends of comments on this version:

* I'm trying to reconcile what is written in this document with what I 
have observed discussed on this mailing list.

One potential disconnect is around the relationship between CS and RS. 
Reading your document, I would conclude that once a CS is associated 
with an RS it will be recorded, unless the recording is paused. Yet I 
still see people who have in mind that the CS might be bound to an RS 
with the expectation that the SRS will subsequently decide (possibly 
with the help of a policy server) whether to record or not.

If that disconnect really exists, then it needs to be settled one way or 
the other.

* As I mentioned in another thread, I think we still lack clarity about 
what a CS is once you get beyond a single point-to-point call. I think 
it will actually be difficult to nail down a sufficiently precise 
definition. (Perhaps we will have to live with vagueness in the 
requirements and postpone the precise definition to the architecture 
document.)

* Maybe I'm reading in more than is intended, but Use Case 4 leaves me 
thinking the expectation is that the RS will have only one (sometimes 
mixed) media stream per media type, rather than potentially having a 
separate media stream feed for each CS and perhaps for each participant 
in a CS. AFAIK that is not intended, though it might be a possible way 
to *use* the mechanisms to implement this use case.

* In the following note:

    o REQ-012 The mechanism MUST support the ability for an SRC to
    deliver mixed audio streams from multiple Communication Sessions to
    an SRS.

    Note: A mixed audio stream is where several Communication Sessions
    are carried in a single Recording Session.  A mixed media stream is
    typically produced by a mixer function.  The RS MAY be informed about
    the composition of the mixed streams through session metadata.

I don't think the def of a mixed audio stream is quite right, though it 
depends a bit on the detailed def of CS. (Its only the Note I'm 
questioning, not the actual REQ-012 text.) Specifically, if we have a 
simple CS with two participants (REQ-12bis), then A single media stream 
including the audio from both of those participants is already a mixed 
stream even though only one CS is involved. The following change might 
address this concern:

    Note: A mixed audio stream is where the media from several
    Communication Session participants has been combined (mixed)
    into a single media stream delivered to the SRS.  A mixed media
    stream is typically produced by a mixer function.  The RS MAY be
    informed about the composition of the mixed streams through session
    metadata.

	Thanks,
	Paul

Ken Rehor (krehor) wrote:
> I’ve reviewed the comments posted to the mailing list about the 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Jul 2010 13:19:49 -0400

Could I ask Ken to propose resolution to the issues we won't discuss at the meeting?  That gives the rest of us a straw man to agree or disagree with.

Brian

---

From: Deepanshu <[email-masked]>
Date: Fri, 23 Jul 2010 11:11:12 +0800

Sorry to say!! But I don't think its time to close 30, especially when
REQ-33 is getting deleted due to that.

Refer: http://www.ietf.org/mail-archive/web/siprec/current/msg00473.html

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Thursday, July 22, 2010 9:18 PM
To: Ken Rehor (krehor); [email-masked]
Subject: Re: [siprec] *draft* draft-ietf-siprec-req-01.txt

Ken,

Thanks. As a result you should be able to close some of the tickets on the
tracker, e.g., #28, #30, #32 and #33 at least. Please do so as appropriate.

We still have lots of open tickets - clearly we can't discuss them all in
Maastricht, so please try to drive some of them forward on the list. Also
would others please help by kicking off discussion again on some of these
issues, some of which have been around for a couple of months or so?

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Jul 2010 08:26:20 +0200

Deepanshu,

I still believe ticket #30 is fixed and should be closed, because REQ-017 and REQ-018 have been clarified. However, if the deletion of REQ-033 is problematic, you should open a new ticket for that. Furthermore, if the new wording of REQ-017 and REQ-018 is not satisfactory, you could open a new ticket or tickets for that too.

John

> From: Deepanshu [mailto:[email-masked]] 
> Sent: 23 July 2010 04:11
> To: Elwell, John; 'Ken Rehor (krehor)'; [email-masked]
> Subject: RE: [siprec] *draft* draft-ietf-siprec-req-01.txt
> 
> Refer: 
> http://www.ietf.org/mail-archive/web/siprec/current/msg00473.html
> 
> Regards
> Deepanshu
> 
> 
> [mailto:[email-masked]] On Behalf Of
> Elwell, John

---

From: Deepanshu <[email-masked]>
Date: Fri, 23 Jul 2010 14:53:18 +0800

Ken,

Some comments as follows...

I'm confused with this correlation thing. I don't quit understand REQ-18
itself, and especially when it replaces REQ-33. I think the only requirement
is to relate one RS with many CSs (persistent recording) and one CS with
many RSs (dynamic recording), that what REQ-33 is saying *very clearly* and
this new REQ-018 is not saying at all. It is saying relating RS media with
CS media described in metadata, what is media? Is it session identities or
participant's identities or real RTP packets? (Note: we don't know yet, it
has to be decided as part of Data Model discussions) Probably the intention
is to relate media in order to relate RS(s) with CS(s), in this case I think
its better (from requirements perspective) just to say the relation needs to
be done, how it will be done using what is not to be written in
requirements. Moreover, the current REQ-18 is about request-to-record
identifying the CS to be recorded. Which I think is getting lost (AFAICT) in
this new REQ-18. Is that something which we don't need? I doubt it.

With respect to REQ-12 and 12bis, I think the term *mixed* should be
clarified that, it is about two media streams becoming one media stream, not
something else (two m lines).

Having defined *mixed*, REQ-14 must explicitly call out itself being
*un-mixed*, which I think is the intention.

Regards

Deepanshu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ken Rehor (krehor)
Sent: Thursday, July 22, 2010 4:20 PM
To: [email-masked]
Subject: [siprec] *draft* draft-ietf-siprec-req-01.txt

I've reviewed the comments posted to the mailing list about the requirements
document and addressed them in a working draft of what will become the -01
version.  See http://kenrehor.com/ietf/siprec/draft-ietf-siprec-req-01.txt

Ken

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 27 Jul 2010 05:56:15 -0700

>  requirements and postpone the precise definition to the architecture 

I want to echo on Paul's comment here about the problem of the vagueness of the definition of a CS, and I agree this is something we should address in the architectural draft rather than in the requirements draft. The architectural draft describes an SRC as a SIP B2BUA, and it is unclear to me whether a CS through a B2BUA means a single SIP dialog, meaning a call with 2 participants is a set of 2 CSes, or is this a single CS with 2 participants?

>From the contact center perspective, it is an important use case for a contact center to record a customer interaction as a complete call record. This can mean the customer call can be transferred to different agents and even across multiple sites. If we treat a CS as a single SIP dialog, then we have the issue of requiring a way to tie or connect multiple CSes together as a full call in the metadata model. However, I also struggle trying to define a single CS as a collection of SIP dialogs that are related, since I don't believe this working group would be interested in defining all possible transfer operations from a B2BUA perspective and how the transfer opertions relates to the participants in a CS. In a way the SRC ultimately understands the relationship of a call between the participants so I think it should be the responsibility of the SRC to define the relationship in the metadata model. The *real* question is how much should we mandate in terms of the realtionships in the CS in this working group.

I would like to hear what others think about this problem.

Regards,
Henry

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Jul 2010 15:29:37 +0200

I tend to agree that the responsibility should be with the SRC to decide what constitutes a CS. In the simple B2BUA case, it might be the concatenation of two SIP dialogs and their associated media. In situations involving conference, transfer, etc., different considerations might apply, but the SRC should know best.

John (as individual) 

> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 27 July 2010 13:56
> To: Paul Kyzivat; Ken Rehor (krehor)
> Cc: [email-masked]
> I want to echo on Paul's comment here about the problem of 
> the vagueness of the definition of a CS, and I agree this is 
> something we should address in the architectural draft rather 
> than in the requirements draft. The architectural draft 
> describes an SRC as a SIP B2BUA, and it is unclear to me 
> whether a CS through a B2BUA means a single SIP dialog, 
> meaning a call with 2 participants is a set of 2 CSes, or is 
> this a single CS with 2 participants?
> 
> From the contact center perspective, it is an important use 
> case for a contact center to record a customer interaction as 
> a complete call record. This can mean the customer call can 
> be transferred to different agents and even across multiple 
> sites. If we treat a CS as a single SIP dialog, then we have 
> the issue of requiring a way to tie or connect multiple CSes 
> together as a full call in the metadata model. However, I 
> also struggle trying to define a single CS as a collection of 
> SIP dialogs that are related, since I don't believe this 
> working group would be interested in defining all possible 
> transfer operations from a B2BUA perspective and how the 
> transfer opertions relates to the participants in a CS. In a 
> way the SRC ultimately understands the relationship of a call 
> between the participants so I think it should be the 
> responsibility of the SRC to define the relationship in the 
> metadata model. The *real* question is how much should we 
> mandate in terms of the realtionships i
>  n the CS in this working group.
> 
> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Jul 2010 17:46:10 +0200

Hi All,

I don't understand the need for REQ-013 which implies that we MUST specify the use of multiple INVITE initiated dialogs for delivering each media stream to the SRS for a single communication session that is being recorded.

If we did this then I think we would need to specify mechanisms for correlating the recording sessions and handling the metadata which REQ-19 states must be provided in the INVITE dialog so we have problems if there is more than one.

Can we remove this requirement or clarify why it is needed.

REQ-013 The mechanism MUST support the ability to deliver multiple
   media streams for a given Communication Session over separate
   Recording Sessions to the SRS.

Regards
Andy

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Rehor (krehor)
Sent: 22 July 2010 10:20
To: [email-masked]
Subject: [siprec] *draft* draft-ietf-siprec-req-01.txt

I've reviewed the comments posted to the mailing list about the requirements document and addressed them in a working draft of what will become the -01 version.  See http://kenrehor.com/ietf/siprec/draft-ietf-siprec-req-01.txt

Ken

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 27 Jul 2010 09:05:58 -0700

Hi Andy,

This question is actually related to my question about what is a CS that I sent previously. Without using the CS terminology, there is a need to use a recording session per participant since there is a simple way to map the SDP from the participant to the recording session. But of course a call usually have 2 participants so you then have 2 recording sessions each describing the SDP of each participant. Now if you try to tie the two participants as a single CS then you can see why REQ-013 is needed. Since the metadata model needs to describe the overall picture that ties the RS and CS together anyways, I don't think there is a need to remove this requirement.

Regards,
Henry

-----Original Message-----
From: [email-masked] on behalf of Hutton, Andrew
Sent: Tue 7/27/2010 11:46 AM
To: Ken Rehor (krehor); [email-masked]
Subject: [siprec] REQ-013 Multiple RS's per CS.
 
Hi All,

Regards
Andy

Ken

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 28 Jul 2010 00:11:06 +0800

Inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: 2010年7月27日 21:30
To: Henry Lum; Paul Kyzivat; Ken Rehor (krehor)
Cc: [email-masked]
Subject: Re: [siprec] *draft* draft-ietf-siprec-req-01.txt

I tend to agree that the responsibility should be with the SRC to decide
what constitutes a CS. In the simple B2BUA case, it might be the
concatenation of two SIP dialogs and their associated media. In situations
involving conference, transfer, etc., different considerations might apply,
but the SRC should know best.

John (as individual) 

> this a single CS with 2 participants?
It would be the later one, i.e 2 participant of a single CS. I think we have
to define a way to relate RS(s) with CS(s) in anyway, now whether it’s a
B2BUA case or it’s the other one (in terms of conference). Metadata is
something which we have for this purpose

---

From: Leon Portman <[email-masked]>
Date: Tue, 27 Jul 2010 19:30:09 +0300

Actually REQ-13 is not directly related for two participants with different CSs but just for two media directions for the same recorded participant (RX and TX).

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Tuesday, July 27, 2010 7:06 PM
To: Hutton, Andrew; Ken Rehor (krehor); [email-masked]
Subject: Re: [siprec] REQ-013 Multiple RS's per CS.

Hi Andy,

Regards,
Henry

-----Original Message-----
From: [email-masked] on behalf of Hutton, Andrew
Sent: Tue 7/27/2010 11:46 AM
To: Ken Rehor (krehor); [email-masked]
Subject: [siprec] REQ-013 Multiple RS's per CS.
 
Hi All,

Regards
Andy

Ken

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Jul 2010 16:08:49 +0200

There is no difference. Two streams, one for each direction, is equivalent to one stream per transmitting party.

John (as individual) 

> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 27 July 2010 17:30
> To: Henry Lum; Hutton, Andrew; Ken Rehor (krehor); [email-masked]
> Actually REQ-13 is not directly related for two participants 
> with different CSs but just for two media directions for the 
> same recorded participant (RX and TX).
> 
> Leon
> 
> This question is actually related to my question about what 
> is a CS that I sent previously. Without using the CS 
> terminology, there is a need to use a recording session per 
> participant since there is a simple way to map the SDP from 
> the participant to the recording session. But of course a 
> call usually have 2 participants so you then have 2 recording 
> sessions each describing the SDP of each participant. Now if 
> you try to tie the two participants as a single CS then you 
> can see why REQ-013 is needed. Since the metadata model needs 
> to describe the overall picture that ties the RS and CS 
> together anyways, I don't think there is a need to remove 
> this requirement.
> 
> Regards,
> Henry
> 
> I don't understand the need for REQ-013 which implies that we 
> MUST specify the use of multiple INVITE initiated dialogs for 
> delivering each media stream to the SRS for a single 
> communication session that is being recorded.
> 
> If we did this then I think we would need to specify 
> mechanisms for correlating the recording sessions and 
> handling the metadata which REQ-19 states must be provided in 
> the INVITE dialog so we have problems if there is more than one.
>

---

From: DeepanshuGautam 57531 <[email-masked]>
Date: Wed, 28 Jul 2010 16:27:11 +0200

may be its about sending same media to two different srs using two different rs, for failover purpose

Br
Deepanshu
Senior Engineer, Service Standards
Nanjing, China-210012
M:+86-13585147627

----- Original Message -----
From: "Elwell, John" <[email-masked]>
Date: Wednesday, July 28, 2010 4:09 pm
Subject: Re: [siprec] REQ-013 Multiple RS's per CS.
To: Leon Portman <[email-masked]>, Henry Lum <[email-masked]>, "Hutton, Andrew" <[email-masked]>, "Ken Rehor (krehor)" <[email-masked]>, "[email-masked]" <[email-masked]>

> There is no difference. Two streams, one for each direction, is 
> equivalent to one stream per transmitting party.
> 
> John (as individual) 
> 
> > attachments belongs to Alcatel-Lucent and/or its affiliated 
> entities.>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 29 Jul 2010 11:43:31 +0530

Deepanshu,

I'm seeing failover as one of the application of basic framework. With
the basic framework of single RS per CS, it must be possible to achieve
failover(High Availability) by the application logic. 

In case of failover is required, SRC and SRS must aware that failover
has to be taken care for  the specific call. IIUC, The protocol
mechanism between SRC and SRS to make the failover application is
currently outside scope of SIPREC. Please let me know your opinion on
the same. We will discuss in detail at MECC today if required.  

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DeepanshuGautam 57531
Sent: Wednesday, July 28, 2010 7:57 PM
To: Elwell, John
Cc: [email-masked]; Leon Portman; Henry Lum
Subject: Re: [siprec] REQ-013 Multiple RS's per CS.

may be its about sending same media to two different srs using two
different rs, for failover purpose

Br
Deepanshu

----- Original Message -----
From: "Elwell, John" <[email-masked]>
Date: Wednesday, July 28, 2010 4:09 pm
Subject: Re: [siprec] REQ-013 Multiple RS's per CS.
To: Leon Portman <[email-masked]>, Henry Lum
<[email-masked]>, "Hutton, Andrew"
<[email-masked]>, "Ken Rehor (krehor)"
<[email-masked]>, "[email-masked]" <[email-masked]>

> > Actually REQ-13 is not directly related for two participants with 
> > different CSs but just for two media directions for the same 
> > recorded participant (RX and TX).
> > 
> > Leon
> > 
> > This question is actually related to my question about what is a CS 
> > that I sent previously. Without using the CS terminology, there is a

> > need to use a recording session per participant since there is a 
> > simple way to map the SDP from the participant to the recording 
> > session. But of course a call usually have 2 participants so you 
> > then have 2 recording sessions each describing the SDP of each 
> > participant. Now if you try to tie the two participants as a single 
> > CS then you can see why REQ-013 is needed. Since the metadata model 
> > needs to describe the overall picture that ties the RS and CS 
> > together anyways, I don't think there is a need to remove this 
> > requirement.
> > 
> > Regards,
> > Henry
> > 
> > I don't understand the need for REQ-013 which implies that we MUST 
> > specify the use of multiple INVITE initiated dialogs for delivering 
> > each media stream to the SRS for a single communication session that

> > is being recorded.
> > 
> > If we did this then I think we would need to specify mechanisms for 
> > correlating the recording sessions and handling the metadata which 
> > REQ-19 states must be provided in the INVITE dialog so we have 
> > problems if there is more than one.
> > 
> > requirements document and addressed them in a working draft of what 
> > will become the -01 version.  See 
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may 
> > contain confidential and proprietary information of Alcatel-Lucent 
> > and/or its affiliated entities. Access by the intended recipient 
> > only is authorized. Any liability arising from any party acting, or 
> > refraining from acting, on any information contained in this e-mail 
> > is hereby excluded. If you are not the intended recipient, please 
> > notify the sender immediately, destroy the original transmission and

> > its attachments and do not disclose the contents to any other 
> > person, use it for any purpose, or store or copy the information in 
> > any medium. Copyright in this e-mail and any attachments belongs to 
> > Alcatel-Lucent and/or its affiliated
> entities.>