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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]] 
> Sent: 2010年6月24日 22:29
> To: Elwell, John
> Cc: Deepanshu Gautam; [e-mail]
> Subject: Re: [siprec] FW:
> I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
> 
> 
> 
> 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-recor
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>>
> 
>