Subject: Re: [siprec] SRS-initiated initial INVITE

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 1 Nov 2011 18:02:47 +0100

Hi,

On 02 October 2011 at 23:35 Kyzivat Paul wrote:

> I think there are a couple of choices here:
> - we can require that an SRC and an SRS have a unique URI, that behaves
>    only as an SRC/SRS, never any other way. And only when addressed by
>    such a URI does it support the siprec option and advertise support
> for
>    the corresponding capability/feature-tag.
>

I don't think we want to require a SRC or SRS to have a unique URI for this purpose this would really increase complexity of deploying and provisioning the solution especially if we have lots of SRC's located in endpoints for example.

> - we can permit the same URI to be used for an RS or a CS. In this case
>    it can support siprec all the time, and announce an SRC or SRS
> feature
>    tag all the time. But then we need something to indicate "behave as
>    an SRC" or "behave as an SRS".

I had previously envisaged that the UA would only include the "src" or "srs" feature tag in the Contact during the establishment of a RS this is how it is currently described in for example section 5.1 of the protocol draft.  That is except for possible use in a REGISTER.

So if this is the case then if this is combined with the use of the "siprec" option tag in Require then I would not thought it to be too big a stretch to say that the siprec aware UAS receiving an INVITE it knows to be from an SRC MUST assume the role of SRS or reject the INVITE. Do we really need something else?

Regards
Andy (as an individual).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 02 October 2011 23:35
> To: [email-masked]
> Subject: Re: [siprec] SRS-initiated initial INVITE
>
> On 9/23/11 5:13 AM, Hutton, Andrew wrote:
> > Hi,
> >
> > I think Friso is correct this is covered in the protocol draft and it
> works like this.
> >
> > 1. The SRS includes a Require header field with the option tag
> "recording-session". This means that the UAS that receives the INVITE
> has to understand SIPREC or it will reject the INVITE.
> >
> > 2. The SRS also includes the feature tag "SRS" in the contact so that
> the UAS that receives it knows that it is an SRS that initiated the
> INVITE for the purpose of creating a recording session so it has to
> become the SRC. Therefore if the UAS is an SRC that does not handle SRS
> initiated INVITE's it should reject the INVITE at this point. Maybe we
> could say something about this in the protocol draft.
>
> IMO this isn't sufficient. SIP feature tags in Contact encode "callee
> capabilities". They don't say anything about what the recipient should
> do.
>
> I think there are a couple of choices here:
> - we can require that an SRC and an SRS have a unique URI, that behaves
>    only as an SRC/SRS, never any other way. And only when addressed by
>    such a URI does it support the siprec option and advertise support
> for
>    the corresponding capability/feature-tag.
>
> - we can permit the same URI to be used for an RS or a CS. In this case
>    it can support siprec all the time, and announce an SRC or SRS
> feature
>    tag all the time. But then we need something to indicate "behave as
>    an SRC" or "behave as an SRS".
>
>       Thanks,
>       Paul
>
> > The only issue I see is possible in the naming of the "recording-
> session" option tag as this should not be used as an indication that
> this is a recording session it is only used to indicate to the UAS that
> it should reject the INVITE if it does not understand SIPREC
> extensions. However this is just a naming issue.
> >
> > Regards
> > Andy
> >
> >
> >> -----Original Message-----
> >> From: Elwell, John
> >> Sent: 23 September 2011 09:42
> >> To: Feenstra, Friso; Ravindran Parthasarathi; Hutton, Andrew; Leon
> >> Portman; [email-masked]
> >> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>
> >> Friso,
> >>
> >> Quite right, it is not yet covered, and the whole purpose of this
> >> thread is to discuss whether something needs to go into the protocol
> >> draft to cover the SRS-initiated case, to align with the
> architecture
> >> draft.
> >>
> >> John
> >>
> >>
> >>> -----Original Message-----
> >>> From: Feenstra, Friso [mailto:[email-masked]]
> >>> Sent: 23 September 2011 09:23
> >>> To: Elwell, John; Ravindran Parthasarathi; Hutton, Andrew;
> >>> Leon Portman; [email-masked]
> >>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>
> >>> Hi John,
> >>>
> >>> Please excuse me as being relative new to this, but is this
> >>> not covered by the current description in Session Recording
> >>> Protocol draft-ietf-siprec-protocol-00 paragraph 5.1 and 5.2?
> >>>
> >>> Friso ( as individual)
> >>>
> >>> -----Original Message-----
> >>> From: Elwell, John [mailto:[email-masked]]
> >>> Sent: vrijdag 23 september 2011 10:04
> >>> To: Ravindran Parthasarathi; Hutton, Andrew; Leon Portman;
> >>> Feenstra, Friso; [email-masked]
> >>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>
> >>> I think we need to avoid violating the semantics of Require.
> >>> The Require header field just means reject the request if you
> >>> don't understand this extension. If you want a
> >>> SIPREC-compliant UAS to act as an SRC, I think you also need
> >>> to put something in the INVITE request to this effect. This
> >>> could simply be the srs feature tag. So we could specify that
> >>> if an entity receives an INVITE request with an srs feature
> >>> tag this is to be interpreted as a request to become an SRC.
> >>> If the UAS is not prepared to do this it can reject it
> >>> somehow (e.g., 403 Forbidden).
> >>>
> >>> John (as individual)
> >>>
> >>>> -----Original Message-----
> >>>> From: Ravindran Parthasarathi [mailto:[email-masked]]
> >>>> Sent: 23 September 2011 07:46
> >>>> To: Hutton, Andrew; Leon Portman; Elwell, John; Feenstra,
> >>>> Friso; [email-masked]
> >>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>
> >>>> Hi Andrew,
> >>>>
> >>>> Thanks for correction. I assumed that softswitch as B2BUA.
> >>>> So, the scenario is that SIP proxy which does not want to
> >>>> push the intelligence to its UA but push it to some-other server.
> >>>>
> >>>> I'm fine as long as there is no extra normative statement for
> >>>> SRC. Let us also spell out the error-code for recording
> >>>> request rejection by SRC in case of INVITE without offer.
> >>>>
> >>>> Thanks
> >>>> Partha
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-
> enterprise.com]
> >>>>> Sent: Friday, September 23, 2011 1:37 AM
> >>>>> To: Ravindran Parthasarathi; Leon Portman; Elwell, John;
> Feenstra,
> >>>>> Friso; [email-masked]
> >>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>
> >>>>> Hi Partha,
> >>>>>
> >>>>> But in Friso's scenario the "softswitch" is really acting
> >>> just a SIP
> >>>>> Proxy so it cannot be the case that the SIP Proxy and the
> >>> SIP UA are
> >>>>> acting as a kind of decomposed SRC.
> >>>>>
> >>>>> Of course whether a given SRC implements the capability to
> receive
> >>>>> INVITE's from the SRS is an implementation option if it does
> >>>> not the SRC
> >>>>> will reject the INVITE due to the recording-session option
> >>> tag in the
> >>>>> Require header.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Andy (As an individual).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ravindran Parthasarathi [mailto:[email-masked]]
> >>>>>> Sent: 22 September 2011 18:43
> >>>>>> To: Leon Portman; Hutton, Andrew; Elwell, John; Feenstra, Friso;
> >>>>>> [email-masked]
> >>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>>
> >>>>>>
> >>>>>> I have earlier mentioned as a not good design because better
> >>>>>> alternative exists for the same recording topology within SIPREC
> >>>>>> solution. I look at Friso recording topology as decomposed
> >>>> SRC to SRS
> >>>>>> network topology and details are as follows:
> >>>>>>
> >>>>>> 1) Softswitch&  Agent phone act as SRC wherein Softswitch is a
> >>>>>> signaling Entity (SIP) and Agent phone as media entity (RTP).
> >>>>>> 2) Softswitch communicates with SRS in the standard SIPREC
> >>>> RS session
> >>>>>> establishment (with extension data) to SRS.
> >>>>>> 3) Based on SRS negotiation, softswitch indicates to agent
> >>>> phone using
> >>>>>> proprietary SDP extension with m-line addition (to start
> >>> recording
> >>>>>> towards SRS). Here, Agent phone forks the media towards
> >>> SRS. I have
> >>>>>> mentioned proprietary SDP extension because the
> >>> interaction between
> >>>>>> decomposed SRC is outside the scope of SIPREC. (I know of
> >>>> the working
> >>>>>> solution in the fashion for the call center).
> >>>>>>
> >>>>>> The advantages in this decomposed SRC solution are
> >>>>>> 1) There is no need of extra CTI or equivalent channel between
> >>>>>> softswitch&  SRS.
> >>>>>> 2) Agent phone has no need to handle multiple dialogs (CS&  RS).
> >>>>>> 3) It is easy for tracking the session from Softswitch
> >>> during agent
> >>>>>> transfer as it is acting as SRC.
> >>>>>> 4) No need to use "join" or some unique session-id
> >>> between all the
> >>>>>> entities
> >>>>>>
> >>>>>> Any recording entity has to support multiple m-lines in
> >>> SDP and so,
> >>>>>> there is no difference for agent-phone between SRS-initiated
> >> and
> >>>>>> decomposed SRC media box. Please correct in case any other
> >>>> advantage
> >>>>> in
> >>>>>> SRS-initiated solution compare to decomposed-SRC.
> >>>>>>
> >>>>>>
> >>>>>> Having said that, I'm fine with SRS-initiated INVITE in
> >>>> case everybody
> >>>>>> is interested for some specific callflow but I'm not
> >>> interested to
> >>>>> hear
> >>>>>> more mandate in SRC to handle this callflow.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Partha
> >>>>>>
> >>>>>> PS: The proposed decomposed SRC solution may work in
> >>>> RTCWeb recording
> >>>>>> solution between RTCWebserver&  browser ;-)
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: [email-masked]
> >>> [mailto:[email-masked]] On
> >>>>>> Behalf
> >>>>>>> Of Leon Portman
> >>>>>>> Sent: Thursday, September 22, 2011 7:34 PM
> >>>>>>> To: Hutton, Andrew; Elwell, John; Feenstra, Friso;
> >>> [email-masked]
> >>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE
> >>>>>>>
> >>>>>>> Andy Hi
> >>>>>>>
> >>>>>>> I will update the drafts with below. I agree on the flow
> >>>>>>>
> >>>>>>> Leon
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Hutton, Andrew
> >>> [mailto:[email-masked]]
> >>>>>>> Sent: Thursday, September 22, 2011 4:28 PM
> >>>>>>> To: Elwell, John; Feenstra, Friso; Leon Portman;
> >> [email-masked]
> >>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> I think what Friso describes is a perfectly valid use
> >>> case and is
> >>>>>>> something that we intended to cover in SIPREC hence the
> >> existing
> >>>>>> section
> >>>>>>> in the architecture draft.
> >>>>>>>
> >>>>>>> I don't think we need to be concerned with how the SRS
> >>>> knows when to
> >>>>>>> start recording this could be via CTI, SIP Dialog Events or
> >> many
> >>>>>> others
> >>>>>>> means. This is I think out of scope of SIPREC.
> >>>>>>>
> >>>>>>> What I think we do need to do is tidy up the architecture draft
> >>>>>> (Section
> >>>>>>> 3.2.2) which covers this use SRS initiated recording.  We
> >>>> need to say
> >>>>>>> more about how the CS that is to be recorded is
> >>>> identified. Currently
> >>>>>>> the arch draft says that one possibly way of doing this
> >>>> is using the
> >>>>>>> "Join" header which obviously only applies if the CS
> >>>> dialog already
> >>>>>>> exists and the SRS knows the dialog identifiers.
> >>>>>>>
> >>>>>>> Do people think that specifying the use of "Join" for
> >>>> this purpose is
> >>>>>>> useful or can we just say something generic about the
> >>> Request-URI
> >>>>>>> identifying what needs to be recorded?
> >>>>>>>
> >>>>>>> I also noticed a mistake in section 3.2.2 of the
> >>>> architecture draft
> >>>>> in
> >>>>>>> the 4th bullet "Session Recording Client" should be "Session
> >>>>> Recording
> >>>>>>> Server" as this refers to the case when the SRS
> >>> generates the SDP
> >>>>>> offer.
> >>>>>>> Leon as you have the pen can you fix this.
> >>>>>>>
> >>>>>>> Andy (As individual).
> >>>>>>>
> >>>>>>> Andrew Hutton
> >>>>>>> http://www.siemens-enterprise.com/uk/
> >>>>>>>
> >>>>>>> Siemens Enterprise Communications Limited.
> >>>>>>> Registered office: Brickhill Street, Willen Lake, Milton
> >>>> Keynes, MK15
> >>>>>>> 0DJ.
> >>>>>>> Registered No: 5903714, England.
> >>>>>>>
> >>>>>>> Siemens Enterprise Communications Limited is a Trademark
> >>>> Licensee of
> >>>>>>> Siemens AG.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [email-masked]
> >>>> [mailto:[email-masked]] On
> >>>>>>>> Behalf Of Elwell, John
> >>>>>>>> Sent: 22 September 2011 08:47
> >>>>>>>> To: Feenstra, Friso; Leon Portman; [email-masked]
> >>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE
> >>>>>>>>
> >>>>>>>> What Friso describes is fairly similar to what I had in mind.
> >>>>>>>> Basically the SRS knows, through some out-of-band means
> >>>> (e.g., CTI,
> >>>>>>>> human involvement), that it should record a CS or CSs (e.g.,
> >>>>>>>> persistent recording of CSs involving a given user,
> >>>> recording the
> >>>>>>>> current CS of a particular user). Based on this it can
> >>>> construct a
> >>>>>> URI
> >>>>>>>> that identifies the SRC and instructs it what to record.
> >>>>>>>>
> >>>>>>>> Personally I am more interested in the case where the
> >>>> SRS is at a
> >>>>>>>> B2BUA. Although the UA case is also potentially of
> >>>> interest, that
> >>>>>>>> tends to have limited applicability for the following
> >> reasons:
> >>>>>>>> - requires SRC support at all UAs that might be
> >>> involved, rather
> >>>>>> than
> >>>>>>>> just in one or a few network entities;
> >>>>>>>> - bandwidth limitations, particularly for mobile
> >>> users and users
> >>>>>> with
> >>>>>>>> limited uplink speeds.
> >>>>>>>>
> >>>>>>>> Since SRS-initiated INVITEs do not require any new SIP
> >>>> mechanism,
> >>>>> it
> >>>>>>>> seems quite reasonable to me to allow them.
> >>>>>>>>
> >>>>>>>> John (as individual)
> >>>>>>>>
> >>>>>>>> John Elwell
> >>>>>>>> Tel: +44 1908 817801 (office and mobile)
> >>>>>>>> Email: [email-masked]
> >>>>>>>> http://www.siemens-enterprise.com/uk/
> >>>>>>>>
> >>>>>>>> Siemens Enterprise Communications Limited.
> >>>>>>>> Registered office: Brickhill Street, Willen Lake,
> >>> Milton Keynes,
> >>>>>> MK15
> >>>>>>>> 0DJ.
> >>>>>>>> Registered No: 5903714, England.
> >>>>>>>>
> >>>>>>>> Siemens Enterprise Communications Limited is a
> >>>> Trademark Licensee
> >>>>> of
> >>>>>>>> Siemens AG.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: [email-masked]
> >>>>>>>>> [mailto:[email-masked]] On Behalf Of
> >>> Feenstra, Friso
> >>>>>>>>> Sent: 21 September 2011 08:31
> >>>>>>>>> To: Leon Portman; [email-masked]
> >>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>
> >>>>>>>>> Leon,
> >>>>>>>>>
> >>>>>>>>> Yes, this is correct and this is how I would like
> >>> it to work.
> >>>>>>>>>
> >>>>>>>>> A few additional notes.
> >>>>>>>>> a. The implementation details of the CTI signalling between
> >>>>>>>>> softswitch and SRS is out of scope for the SIPREC
> >>>> standard, but
> >>>>>> most
> >>>>>>>>> softswitches offer a form of CTI signalling that can
> >>>> be used for
> >>>>>>>>> this signalling.
> >>>>>>>>> b. It is not defined how much info is send with the
> >>>> SDP from the
> >>>>>> SRS
> >>>>>>>>> to the SRC (via the softswitch). Worse case an
> >>>> offerless invite
> >>>>> is
> >>>>>>>>> send to start the RS session, next the SRC will
> >>> provide the CS
> >>>>>> info
> >>>>>>>>> in the OK with SDP and Metadata and the SRS will select the
> >>>>>> correct
> >>>>>>>>> streams with the ACK or through a re-Invite.
> >>>>>>>>> c. I anticipate that the forwarding by the softswitch
> >>>> of Invite
> >>>>>>>>> messages (CS and RS) is a 'standard' feature for the
> >>>> softswitch
> >>>>>>>>> acting as a SIP proxy server and as such can be left
> >>>> outside the
> >>>>>>>>> scope of the SIPREC standard.
> >>>>>>>>>
> >>>>>>>>> As an individual,
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> Friso
> >>>>>>>>>
> >>>>>>>>> [email-masked]
> >>>>>>>>> +31 6 415 46 305
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Leon Portman [mailto:[email-masked]]
> >>>>>>>>> Sent: dinsdag 20 september 2011 18:03
> >>>>>>>>> To: Feenstra, Friso; [email-masked]
> >>>>>>>>> Cc: Ravindran Parthasarathi; Paul Kyzivat
> >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>
> >>>>>>>>> Friso
> >>>>>>>>>
> >>>>>>>>> It is a very good discussion. Let me try to understand the
> >>>>>> proposed
> >>>>>>>>> sequence  for example as incoming call from UA A to
> >>>> UA B, where
> >>>>> UA
> >>>>>> B
> >>>>>>>>> is SRC.
> >>>>>>>>> Actually UA B and softswitch are decomposed SRC.
> >>>>>>>>>
> >>>>>>>>> 1. UA A sends CS INVITE to softswitch 2. softswitch sends
> >> CS
> >>>>>> INVITE
> >>>>>>>>> to UA B (SRC) 3. softswitch reports via CTI to SRS
> >>>> about CS (UA A
> >>>>>>>>> calling UA B) 4. SRS decides to record and sends RS
> >>>> INVITE with
> >>>>>> SDP
> >>>>>>>>> to softswitch with some CS mapping info 5.
> >>> Softswitch sends RS
> >>>>>>>>> INVITE to UA B that acts as SRC 6. UA B send OK with
> >>>> its SDP via
> >>>>>>>>> softswitch to SRS
> >>>>>>>>>
> >>>>>>>>> This flow will require definition additional
> >>>> interface for step 3
> >>>>>>>>> and for softswitch to implement step 5 Is it correct flow?
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>>
> >>>>>>>>> Leon
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Feenstra, Friso [mailto:[email-masked]]
> >>>>>>>>> Sent: Tuesday, September 20, 2011 6:34 PM
> >>>>>>>>> To: [email-masked]
> >>>>>>>>> Cc: Leon Portman; Ravindran Parthasarathi; Paul Kyzivat
> >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>
> >>>>>>>>> Partha and Leon,
> >>>>>>>>>
> >>>>>>>>> The business intelligence (Policy Manager) in our
> >>> case is with
> >>>>> the
> >>>>>>>>> SRS and like the softswitch (acting as a SIP proxy)
> >>>> is deployed
> >>>>> on
> >>>>>> a
> >>>>>>>>> central location.
> >>>>>>>>> Agent handsets (UA's) are globally dispersed. So I am
> >>>> definitely
> >>>>>>>>> looking for a SIPREC solution where the SRC is
> >>>> implemented on the
> >>>>>> UA
> >>>>>>>>> (agent handset).
> >>>>>>>>>
> >>>>>>>>> When only the SRC can provide the RS Invite than additional
> >>>>>>>>> signalling is needed to initiate the recording between SRS
> >>>>> (Policy
> >>>>>>>>> Manager) and softswitch (CTI based API) and between
> >>> softswitch
> >>>>> and
> >>>>>>>>> agent handset (UA) (SIP?). So standards are needed for CTI
> >>>>>>>>> signalling from Policy Manager / SRS to softswitch and from
> >>>>>>>>> softswitch to the agent handset.
> >>>>>>>>>
> >>>>>>>>> Another reason why this is not a good idea, is that an
> >> extra
> >>>>>>>>> component (softswitch) is involved in the RS setup for the
> >>>>>>>>> conversion of the CTI message from the SRS into a SIP
> >>>>>>>>> message(?) towards the handset (SRC).
> >>>>>>>>>
> >>>>>>>>> With an SRS initiated flow the additional signalling
> >>>> definition
> >>>>> is
> >>>>>>>>> not needed and only minimal changes are needed on the
> >>>> softswitch
> >>>>>>>>> acting as a SIP proxy.
> >>>>>>>>>
> >>>>>>>>> Having all the agent handsets always start a RS
> >>>> session for each
> >>>>>> CS
> >>>>>>>>> would be quite a waste of SIP sessions,
> >>> specifically since the
> >>>>>>>>> softswitch is involved as SIP-proxy in all session setup
> >> and
> >>>>> since
> >>>>>>>>> only a limited number of sessions will need
> >>>>>>>> recording.
> >>>>>>>>>
> >>>>>>>>> As such I would appreciate the option of a SRS
> >>> based Invite in
> >>>>> the
> >>>>>>>>> standards.
> >>>>>>>>>
> >>>>>>>>> As an individual,
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> Friso
> >>>>>>>>> [email-masked]
> >>>>>>>>> +31 6 415 46 305
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Ravindran Parthasarathi
> >>> [mailto:[email-masked]]
> >>>>>>>>> Sent: dinsdag 20 september 2011 16:22
> >>>>>>>>> To: Feenstra, Friso; Paul Kyzivat; [email-masked]
> >>>>>>>>> Subject: RE: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>
> >>>>>>>>> Friso,
> >>>>>>>>>
> >>>>>>>>> In case I remember correctly, the same SRS callflow
> >>>> was discussed
> >>>>>>>>> long back. The mentioned callflow is not good design in my
> >>>>> opinion
> >>>>>>>>> because extra channel is required between softswitch
> >>>> &  SRS apart
> >>>>>>>>> from SIPREC framework.
> >>>>>>>>>
> >>>>>>>>> The alternative is to start the recording from agent
> >> handset
> >>>>>> towards
> >>>>>>>>> SRS with CS id.  Please let me know the issue in this
> >>>> approach.
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> Partha
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: [email-masked]
> >>>> [mailto:[email-masked]]
> >>>>> On
> >>>>>>>>>> Behalf Of Feenstra, Friso
> >>>>>>>>>> Sent: Tuesday, September 20, 2011 7:38 PM
> >>>>>>>>>> To: Paul Kyzivat; [email-masked]
> >>>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>>
> >>>>>>>>>> Paul,
> >>>>>>>>>>
> >>>>>>>>>> Business intelligence is in the SRS. SRS is informed
> >>>>>>>>> out-of-band that
> >>>>>>>>>> CS session is started. Based on the out-of-band provided
> >>>>>>>>>> information the SRS determines that RS is needed.
> >>> Part of the
> >>>>>> out-
> >>>>>>>>>> of-band information is the identification of the
> >>>> SRC. Based on
> >>>>>> this
> >>>>>>>>> information
> >>>>>>>>>> the (offerless) Invite is send to the SRC.
> >>>>>>>>>>
> >>>>>>>>>> The SRC intelligence is included in the UA (agent
> >>>> handset). This
> >>>>>>>>>> way only a limited implementation is needed on the
> >>>> controlling
> >>>>>>>>> softswitch.
> >>>>>>>>>> RS is managed between SRS recorder and agent handset.
> >>>>>>>>>>
> >>>>>>>>>> As an individual,
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Friso
> >>>>>>>>>> [email-masked]
> >>>>>>>>>> +31 6 415 46 305
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: [email-masked]
> >>>> [mailto:[email-masked]]
> >>>>> On
> >>>>>>>>>> Behalf Of Paul Kyzivat
> >>>>>>>>>> Sent: dinsdag 20 september 2011 15:54
> >>>>>>>>>> To: [email-masked]
> >>>>>>>>>> Subject: Re: [siprec] SRS-initiated initial INVITE
> >>>>>>>>>>
> >>>>>>>>>> Friso,
> >>>>>>>>>>
> >>>>>>>>>> On 9/20/11 6:23 AM, Feenstra, Friso wrote:
> >>>>>>>>>>> As a new participant I would like to make the following
> >>>>> remark.
> >>>>>>>>>>>
> >>>>>>>>>>> We currently have a strong requirement for a
> >>>> ´intelligent´ SRS
> >>>>>>>>>>> capable
> >>>>>>>>>> of
> >>>>>>>>>>>
> >>>>>>>>>>> starting and stopping RS sessions. We want to deploy a
> >>>>>>>>> contact centre
> >>>>>>>>>>>
> >>>>>>>>>>> solution with agents dispersed around the globe.
> >>>> The business
> >>>>>>>>>> intelligence
> >>>>>>>>>>>
> >>>>>>>>>>> of what and when to record will be at the SRS, so the
> >> SRS
> >>>>>> should
> >>>>>>>> be
> >>>>>>>>>> capable
> >>>>>>>>>>>
> >>>>>>>>>>> determining what's to be recorded and of starting the
> >> RS.
> >>>>>>>>>>
> >>>>>>>>>> Could you explain more about how the intelligence is
> >>>>> distributed?
> >>>>>>>>>> How much does the SRS know a priori about the calls?
> >>>>>>>>>> And what is the granularity of the SRC? Are you imagining
> >>>>>>>>> that the SRC
> >>>>>>>>>> is on a per-agent basis? Or does an SRC cover many
> >>> agents and
> >>>>>> many
> >>>>>>>>>> concurrent calls?
> >>>>>>>>>>
> >>>>>>>>>>> An option could be that the SRS sends an offerless
> >>>> invite, as
> >>>>>>>>>> currently
> >>>>>>>>>>>
> >>>>>>>>>>> defined in the architecture. Next the SRC could provide
> >>>>>>>>> based on its
> >>>>>>>>>>>
> >>>>>>>>>>> knowledge of the current CS send the 200 OK with the SDP
> >>>>>>>>> and metadata
> >>>>>>>>>>>
> >>>>>>>>>>> describing the available sessions. With this
> >>> knowledge and
> >>>>>> based
> >>>>>>>> on
> >>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>> business intelligence in the SRS, the SRS could then
> >>>>>>>>> accept which of
> >>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>> available streams it would like for recording,
> >>> either in an
> >>>>> ACK
> >>>>>>>>>> response or
> >>>>>>>>>>>
> >>>>>>>>>>> through a re-Invite.
> >>>>>>>>>>
> >>>>>>>>>> I can see how this could at least scale right if
> >>> the SRC was
> >>>>>>>>> per-agent.
> >>>>>>>>>> But if the SRC was something like a PBX that
> >>> covered all the
> >>>>>>>>> agents in
> >>>>>>>>>> a facility, then it wouldn't scale reasonably, because the
> >>>>>>>>> offer would
> >>>>>>>>>> then contain perhaps hundreds of media streams.
> >>>>>>>>>>
> >>>>>>>>>>> I hope there will be room for this use case in the RFC.
> >>>>>>>>>>>
> >>>>>>>>>>> As an individual,
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>>
> >>>>>>>>>>> Friso Feenstra
> >>>>>>>>>>>
> >>>>>>>>>>> [email-masked]
> >>>> <mailto:[email-masked]>
> >>>>>>>>>>>
> >>>>>>>>>>> +31 6 415 46 305
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Think green - keep it on the screen. This e-mail and any
> >>>>>>>>> attachment
> >>>>>>>>>>> is for authorised use by the intended
> >>> recipient(s) only. It
> >>>>> may
> >>>>>>>>>>> contain proprietary material, confidential
> >>>> information and/or
> >>>>>> be
> >>>>>>>>>>> subject to legal privilege. It should not be
> >>>> copied, disclosed
> >>>>>>>>>>> to, retained or
> >>>>>>>>>> used
> >>>>>>>>>>> by, any other party. If you are not an intended
> >> recipient
> >>>>>>>>> then please
> >>>>>>>>>>> promptly delete this e-mail and any attachment and
> >>>> all copies
> >>>>>> and
> >>>>>>>>>> inform
> >>>>>>>>>>> the sender. Thank you.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> siprec mailing list
> >>>>>>>>>>> [email-masked]
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> siprec mailing list
> >>>>>>>>>> [email-masked]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Think green - keep it on the screen.
> >>>>>>>>>>
> >>>>>>>>>> This e-mail and any attachment is for authorised use by
> >> the
> >>>>>>>>>> intended
> >>>>>>>>>> recipient(s) only. It may contain proprietary material,
> >>>>>>>>>> confidential information and/or be subject to legal
> >>>> privilege.
> >>>>> It
> >>>>>>>>>> should not be copied, disclosed to, retained or
> >>> used by, any
> >>>>>> other
> >>>>>>> party.
> >>>>>>>>> If you are
> >>>>>>>>>> not an intended recipient then please promptly delete this
> >>>>>>>>> e-mail and
> >>>>>>>>>> any attachment and all copies and inform the sender.
> >>>> Thank you.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> siprec mailing list
> >>>>>>>>>> [email-masked]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Think green - keep it on the screen.
> >>>>>>>>>
> >>>>>>>>> This e-mail and any attachment is for authorised use by the
> >>>>>> intended
> >>>>>>>>> recipient(s) only. It may contain proprietary material,
> >>>>>> confidential
> >>>>>>>>> information and/or be subject to legal privilege. It
> >>>> should not
> >>>>> be
> >>>>>>>>> copied, disclosed to, retained or used by, any
> >>> other party. If
> >>>>> you
> >>>>>>>>> are not an intended recipient then please promptly
> >>> delete this
> >>>>>>>>> e-mail and any attachment and all copies and inform
> >>>> the sender.
> >>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Think green - keep it on the screen.
> >>>>>>>>>
> >>>>>>>>> This e-mail and any attachment is for authorised use by the
> >>>>>> intended
> >>>>>>>>> recipient(s) only. It may contain proprietary material,
> >>>>>> confidential
> >>>>>>>>> information and/or be subject to legal privilege. It
> >>>> should not
> >>>>> be
> >>>>>>>>> copied, disclosed to, retained or used by, any
> >>> other party. If
> >>>>> you
> >>>>>>>>> are not an intended recipient then please promptly
> >>> delete this
> >>>>>>>>> e-mail and any attachment and all copies and inform
> >>>> the sender.
> >>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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
> >>>>
> >>>
> >>>
> >>> Think green - keep it on the screen.
> >>>
> >>> This e-mail and any attachment is for authorised use by the
> >>> intended recipient(s) only. It may contain proprietary
> >>> material, confidential information and/or be subject to legal
> >>> privilege. It should not be copied, disclosed to, retained or
> >>> used by, any other party. If you are not an intended
> >>> recipient then please promptly delete this e-mail and any
> >>> attachment and all copies and inform the sender. Thank you.
> >>>
> >>>
> >>>
> > _______________________________________________
> > 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: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 17:21:48 -0400

> I don't think we want to require a SRC or SRS to have a unique URI for this purpose this would really increase complexity of deploying and provisioning the solution especially if we have lots of SR…

I guess that makes sense, especially when addressing phones that can act 
as SRCs.

> I had previously envisaged that the UA would only include the "src" or "srs" feature tag in the Contact during the establishment of a RS this is how it is currently described in for example section…

The feature tag means "I have this capability" (similar to what 
Supported means).

ISTM its an abuse to treat it as meaning "I'm doing this".

> So if this is the case then if this is combined with the use of the "siprec" option tag in Require then I would not thought it to be too big a stretch to say that the siprec aware UAS receiving an…

I think so. It could be very simple.
The invite could include a snapshot request.

	Thanks,
	Paul