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

[Paul Kyzivat <[e-mail]>]

Elwell, John wrote:
>  
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Deepanshu Gautam
>> Sent: 24 June 2010 03:25
>> To: 'Paul Kyzivat'
>> Cc: [e-mail]
>> 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:[e-mail]] 
>> Sent: 2010年6月23日 22:26
>> To: Deepanshu Gautam
>> Cc: 'Hutton, Andrew'; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On 
>>> Behalf Of Hutton, Andrew
>>> Sent: 2010年6月19日 0:33
>>> To: [e-mail]
>>> Subject: [siprec] FW:
>>> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
>>>
>>>  
>>> From: [e-mail] 
>>> [mailto:[e-mail]]
>>> On Behalf Of [e-mail]
>>> Sent: 18 June 2010 17:30
>>> To: [e-mail]
>>> 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-record
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>>