Subject: [siprec] #38: Clarification on interaction with a conference focus needed

From: "siprec issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 16:14:48 -0000

#38: Clarification on interaction with a conference focus needed
--------------------------------------------------+-------------------------
 Reporter:  andrew.hutton@…                       |       Owner:  andrew.hutton@…                     
     Type:  enhancement                           |      Status:  new                                 
 Priority:  minor                                 |   Milestone:                                      
Component:  Architecture                          |     Version:                                      
 Severity:  -                                     |    Keywords:                                      
--------------------------------------------------+-------------------------
 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

 > -----Original Message-----
 > From: Deepanshu Gautam [mailto:[email-masked]]
 > Sent: 13 July 2010 05:12
 > To: Hutton, Andrew; 'Paul Kyzivat'
 > Cc: [email-masked]
 > Subject: RE: [siprec] FW:
 > I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
 >
 >
 > 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:
 > I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
 >
 > 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
 >
 >
 > > -----Original Message-----
 > > From: [email-masked]
 > > [mailto:[email-masked]] On Behalf Of Deepanshu Gautam
 > > Sent: 06 July 2010 04:03
 > > To: 'Paul Kyzivat'
 > > Cc: [email-masked]
 > > Subject: Re: [siprec] FW:
 > > I-DAction:draft-hutton-siprec-session-recording-arch-01.txt
 > >
 > >
 > > 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
 > > >>>
 > > >
 > > >
 > >
 > > _______________________________________________
 > > siprec mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/siprec
 > > =
 >
 >
 _______________________________________________
 siprec mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/siprec

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/38>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 16:16:21 -0000

#38: Clarification on interaction with a conference focus needed
--------------------------------------------------+-------------------------
 Reporter:  andrew.hutton@…                       |       Owner:  andrew.hutton@…                     
     Type:  enhancement                           |      Status:  assigned                            
 Priority:  minor                                 |   Milestone:                                      
Component:  Architecture                          |     Version:                                      
 Severity:  -                                     |    Keywords:                                      
--------------------------------------------------+-------------------------
Changes (by andrew.hutton@…):

  * status:  new => assigned

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/38#comment:1>
siprec <http://tools.ietf.org/siprec/>