Subject: Re: [siprec] FW: I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 06 Jul 2010 11:02:45 +0800

Andrew,

May I request you to add some text in the ARC draft mentioning that in some
cases SRC can just be bystander to CS establishment i.e will not be one of
the participant in CS untill the CS is decided to be recorded.

This was discussed in the below thread..

Regards
Deepanshu

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2010年6月25日 21:00
To: Deepanshu Gautam
Cc: 'Elwell, John'; [email-masked]
Subject: Re: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

Deepanshu Gautam wrote:
> Well, the arch document tends to specify the location of SRC, I 
> understand it may not be exhaustive, but, *if* in the process of ARC 
> development we came across a possible different (not covered) scenario 
> then I don't think it hurts to spell it out and possibly pointing out 
> that *bag* of SIP which could be used to satisfy that.

I think its fine to document *examples* of all sorts of things.
Exactly what document they end up in can be resolved later.

	Thanks,
	Paul

> Regards
> Deepanshu
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 2010年6月24日 22:29
> To: Elwell, John
> Cc: Deepanshu Gautam; [email-masked]
> Subject: Re: [siprec] FW:
> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
> 
> 
> 
> Elwell, John wrote:
>>  
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Deepanshu Gautam
>>> Sent: 24 June 2010 03:25
>>> To: 'Paul Kyzivat'
>>> Cc: [email-masked]
>>> Subject: Re: [siprec] FW: 
>>> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
>>>
>>>  
>>> Paul,
>>>
>>> I agree. So, now I think its OK to keep the statement "...or may 
>>> limit what it includes in the offer on the CS...." in the section 
>>> provided it is with *may*.
>>>
>>> But, do we need another architecture (another location for SRC) to 
>>> accommodate the case when SRC is just a bystander to the CS 
>>> establishment?
>> [JRE] This sounds like physical separation between the SRC and the SIP
UA.
> Could this left out of scope, possibly to be covered by MEDIACTRL?
> 
> I don't think anything needs to be said.
> Its a fact of life in this situation.
> The SRC can use any of the sip bag of tricks to deal with it.
> 
> 	Thanks,
> 	Paul
> 
>> John
>>
>>
>>> Regards
>>> Deepanshu
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[email-masked]]
>>> Sent: 2010年6月23日 22:26
>>> To: Deepanshu Gautam
>>> Cc: 'Hutton, Andrew'; [email-masked]
>>> Subject: Re: [siprec] FW:
>>> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
>>>
>>> Deepanshu,
>>>
>>> I guess there are cases where the SRC is influential in the 
>>> establishment of the CS, and other cases where it is not.
>>>
>>> When it is, it could potentially limit the formats it offers or 
>>> accepts to those it knows to be supported by the SRS.
>>>
>>> When its just a bystander to the CS establishment then it can't do 
>>> that, and so must hope the SRS can handle what is negotiated, or 
>>> must find a transcoder to help, or must forgo recording in that 
>>> case, or must block the CS in that case.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> Deepanshu Gautam wrote:
>>>> I have a question about the new section called "Media Transcoding". 
>>>> The section states "......it may be limit the media formats in the 
>>>> offer to the SRS depending on what media is negotiated on the CS or 
>>>> may limit what it includes in the offer on the CS.......". I can 
>>>> undersatnd the first part of it where SRC limit the media format in 
>>>> its offer to SRS (it *may* know the CS negotiations from
>>> metadata) but
>>>> for the second part (...may limit what it includes in the
>>> offer on the
>>>> CS...), are we assuming that SRC will always be induldge in CS 
>>>> negotiation/establishment? or SRC can change the previously
>>> negotiated
>>>> media for CS? There may be scenarios where SRC will not
>>> come it picture
>>> untill the CS is established/negotiated and went on for some time.
>>>> For e.g consider a supervisor terminal (SRC) in a call center which 
>>>> randomly picks a communication session between one of his/her 
>>>> subordinate and customer, to record, for purpose of agent
>>> performance
>>>> check. This perhaps, can be done by SRC joining the pre-established 
>>>> CS, making it a conference and start sending replicated
>>> media to SRS.  
>>>> In this case, SRC will not be among the communicating
>>> parties of CS, I
>>>> mean it may join the CS later but was not there when it was 
>>>> negotiated/established and neither it wants to change the
>>> negotiated media
>>> for CS (perhaps for privacy resons).
>>>> Having said this, I'm not sure what is the motivation
>>> behind  "...may
>>>> limit what it includes in the offer on the CS...". Further, we may 
>>>> think of a additioanl ARC model where SRC can be a SIP entity which 
>>>> does not participate in CS negotiation/establishment and
>>> has no idea
>>>> about the media format negotiated for CS. I'm not sure if we can 
>>>> consider this aspect being covered by B2BUA model.
>>>>
>>>> Regards
>>>> Deepanshu
>>>>
>>>>
>>>>  
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Hutton, Andrew
>>>> Sent: 2010年6月19日 0:33
>>>> To: [email-masked]
>>>> Subject: [siprec] FW:
>>>> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
>>>>
>>>>  
>>>> From: [email-masked] 
>>>> [mailto:[email-masked]]
>>>> On Behalf Of [email-masked]
>>>> Sent: 18 June 2010 17:30
>>>> To: [email-masked]
>>>> Subject: I-D
>>> Action:draft-hutton-siprec-session-recording-arch-01.txt
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>>
>>>> 	Title           : An Architecture for Media Recording using the
>>>> Session Initiation Protocol
>>>> 	Author(s)       : A. Hutton, et al.
>>>> 	Filename        : 
>>> draft-hutton-siprec-session-recording-arch-01.txt
>>>> 	Pages           : 15
>>>> 	Date            : 2010-06-18
>>>>
>>>> Session recording is a critical requirement in many communications 
>>>> environments such as call centers and financial trading.
>>> In some of
>>>> these environments, all calls must be recorded for regulatory, 
>>>> compliance, and consumer protection reasons.  Recording of
>>> a session
>>>> is typically performed by sending a copy of a media stream to a 
>>>> recording device.  This document describes architectures
>>> for deploying
>>>> session recording solutions in an environment which is based on the
>>> Session Initiation Protocol (SIP).
>>>> A URL for this Internet-Draft is:
>>>>
>>> http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-reco
>>> r
>>> d
>>>> ing-ar
>>>> ch-01.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader 
>>>> implementation to automatically retrieve the ASCII version of the 
>>>> Internet-Draft.
>>>>
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
> 
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 12 Jul 2010 12:37:43 +0200

Hi Deepanshu,

I am still a little confused as to what exactly you are requesting me to include.

In your scenario I assume the SRC is still a SIP UA in it's own right and does not have any association with any of the UA's in the CS. Therefore to participate in the CS it has to be able to be able to obtain the dialog identifiers and probably use the join header.  Once it has joined the CS then I guess it can become an SRC for that CS because it has access to the media.

There are many ways in which the CS may get established before recording is initiated so I am not sure what is special about this case.

Maybe if you could provide a diagram showing the relationship between the SIP UA's, SRC and SRS then that would help and I could include it in the draft as another example.

Regards
Andy

> Sent: 06 July 2010 04:03
> [mailto:[email-masked]] On 
> >>>> Behalf Of Hutton, Andrew
> >>>> Sent: 2010年6月19日 0:33
> >>>> To: [email-masked]
> >>>> Subject: [siprec] FW:

---

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 13 Jul 2010 12:11:31 +0800

Andrew,

I don't think there is much to put in the diagram here, but I would give it
a try as attached (can't put it here, its getting grabled).

The main point is SRC may be joining (anyhow) the CS at some future point of
time (probably, making it a multimarty conference) in the CS lifecycle. I'm
not sure whether this can be covered by current two ARC model. In this case
SRC will neither be among the original CS participants nor the B2BUA
influential in the CS establishment. May be it won't require any explict
work in terms of specification but it’s a valid ARC/deployment model.

The usecase for this (as I mentioned before) may include "The Agent
Performance Monitoring Service.

Regards
Deepanshu

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]]
Sent: 2010年7月12日 18:38
To: Deepanshu Gautam; 'Paul Kyzivat'
Cc: [email-masked]
Subject: RE: [siprec] FW:

Hi Deepanshu,

I am still a little confused as to what exactly you are requesting me to
include.

In your scenario I assume the SRC is still a SIP UA in it's own right and
does not have any association with any of the UA's in the CS. Therefore to
participate in the CS it has to be able to be able to obtain the dialog
identifiers and probably use the join header.  Once it has joined the CS
then I guess it can become an SRC for that CS because it has access to the
media.

There are many ways in which the CS may get established before recording is
initiated so I am not sure what is special about this case.

Maybe if you could provide a diagram showing the relationship between the
SIP UA's, SRC and SRS then that would help and I could include it in the
draft as another example.

Regards
Andy

> May I request you to add some text in the ARC draft mentioning that in
> some cases SRC can just be bystander to CS establishment i.e will not
> be one of the participant in CS untill the CS is decided to be
> recorded.
>
> =

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 13 Jul 2010 11:41:05 +0200

Hi Deepanshu,

Thanks for the diagram.

I don't see anything special about this case as once the conference focus has joined the session it is just a normal SRC and I had a go at explaining this in section 4.1.4 of the existing draft (http://tools.ietf.org/html/draft-ietf-siprec-architecture-00#section-4.1.4).

I think maybe this section could do with a bit more text and I can include something about your scenario in the next update.

Regards
Andy

> From: Deepanshu Gautam [mailto:[email-masked]] 
> Sent: 13 July 2010 05:12
> To: Hutton, Andrew; 'Paul Kyzivat'
> Cc: [email-masked]