Subject: [siprec] SRS-initiated initial INVITE

From: "Feenstra, Friso" <[email-masked]>
Date: Tue, 20 Sep 2011 10:23:45 +0000

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.

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 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Sep 2011 09:53:43 -0400

Friso,

On 9/20/11 6:23 AM, Feenstra, Friso wrote:
> 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?

> available streams it would like for recording, either in an ACK response or

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.

> [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

---

From: "Feenstra, Friso" <[email-masked]>
Date: Tue, 20 Sep 2011 14:08:07 +0000

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,

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 20 Sep 2011 19:51:57 +0530

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

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Feenstra, Friso
>Sent: Tuesday, September 20, 2011 7:38 PM
>To: Paul Kyzivat; [email-masked]
>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.
>
>

---

From: Leon Portman <[email-masked]>
Date: Tue, 20 Sep 2011 17:36:11 +0300

Friso Hello

We had multiple discussions about SRS-initiated flows. And as you are stated below, the only way for SRS to know when to initiate RS is to have either another "CTI" link to get metadata or to receive Record On Demand request via some API. 
Each mode (SRS-initiated or SRC initiated) has cons and pros.

We can implement these flows by SRC-initiated recording as well by using following options:
1. SRS will invoke another non-SIP based API (CTI) to trigger RS from SRC to SRS
2. SRC will send RSs for all CSs and SRS will accept them with media inactive until it will decide to record

SRC initiated mode:
Pros:
	1. good for all calls recording, where no recording decision is done. Minimized media clipping
	2. can support flows where CS will be not established if no RS is established
                3. In general if recording policy is defined on SRC side - part of the device management
Cons:    
	1. not well suitable if recording decision on SRS side
	2. requires additional CTI leg for mode option 1 above
                3. wastes SIP sessions for option 2 above in case only small percentage of the call are recorded

In general, we had definition of Policy Manager that decides outside SRC and SRS what to record and instruct ether one for recording requests.

I am not opposing SRS-initiated flows, but only trying to explain the point that SRC initiated one is more generic solution.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Feenstra, Friso
Sent: Tuesday, September 20, 2011 5:08 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

-----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,

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?

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.

> 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.
>
>

---

From: "Feenstra, Friso" <[email-masked]>
Date: Tue, 20 Sep 2011 15:33:39 +0000

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

-----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,

Thanks
Partha

>Of Paul Kyzivat
>used

---

From: Leon Portman <[email-masked]>
Date: Tue, 20 Sep 2011 19:02:59 +0300

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 an individual,

Regards,

Friso

-----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,

Thanks
Partha

>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
>> We currently have a strong requirement for a ´intelligent´ SRS 
>> capable
>of
>>
>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 
>> 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

---

From: "Feenstra, Friso" <[email-masked]>
Date: Wed, 21 Sep 2011 07:30:37 +0000

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

-----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 

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,

As an individual,

Regards,

Friso

-----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,

Thanks
Partha

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Sep 2011 09:46:44 +0200

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.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Feenstra, Friso
> Sent: 21 September 2011 08:31
> To: Leon Portman; [email-masked]
> 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
> 
> 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.
> This flow will require definition additional interface for 
> step 3 and for softswitch to implement step 5
> Is it correct flow?
> 
> Regards
> 
> 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.
> 
> 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
> 
> >> business intelligence in the SRS, the SRS could then 
> accept which of
> >the
> >>
> 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.
> 
> 
> 
> 
> 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.
> 
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 22 Sep 2011 15:27:45 +0200

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: 22 September 2011 08:47
> To: Feenstra, Friso; Leon Portman; [email-masked]
> 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:
> 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
> > >> of what and when to record will be at the SRS, so the SRS should
> be
> > >capable
> > >>
> > >> describing the available sessions. With this knowledge and based
> on
> > >the
> > >>

---

From: Leon Portman <[email-masked]>
Date: Thu, 22 Sep 2011 17:04:13 +0300

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,

Andy (As individual).

Andrew Hutton

> 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.
>
> B2BUA. Although the UA case is also potentially of interest, that
> tends to have limited applicability for the following reasons:
> > 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
> >
> > 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.
> > 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
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
> > >Behalf Of Feenstra, Friso
> > >CS session is started. Based on the out-of-band provided
> > information
> > softswitch.
> > >Behalf Of Paul Kyzivat
> > >> subject to legal privilege. It should not be copied, disclosed
> > >> to, retained or
> > >used
> > >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
> > 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.
> >
> >
> >
> >
> > 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.
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2011 12:13:05 -0400

> Since SRS-initiated INVITEs do not require any new SIP mechanism, it seems quite reasonable to me to allow them.

If there is a particular call that is to be recorded, it might be 
reasonable to use INVITE/Join as a way to indicate the call to be 
recorded. The indication that the request comes from an SRS would then 
temper how the target sets up the resulting joined call - as a recording 
session rather than as a conference. Doing it with an offerless INVITE 
would permit the SRC to fill in the media that are available to be recorded.

This is all totally "permissible" usage within the scope of siprec as we 
are defining it. But because there is nothing normative about it, there 
is no reason to expect that the SRC would support it, except by mutual 
agreement. OTOH, if we were to call this behavior out normatively, then 
one could expect it to work except when forbidden by policy.

	Thanks,
	Paul

>> between softswitch&  SRS apart from SIPREC framework.
>>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 22 Sep 2011 23:13:24 +0530

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 ;-)

>Of Leon Portman
>Sent: Thursday, September 22, 2011 7:34 PM
>To: Hutton, Andrew; Elwell, John; Feenstra, Friso; [email-masked]
>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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 22 Sep 2011 22:06:53 +0200

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).

> Sent: 22 September 2011 18:43
> To: Leon Portman; Hutton, Andrew; Elwell, John; Feenstra, Friso;
> [email-masked]
> 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).
>
> 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 ;-)
>
> Behalf
> >> - 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.
> >>
> >> Registered office: Brickhill Street, Willen Lake, Milton Keynes,
> MK15
> >> 0DJ.
> proposed
> towards
> >> > >> promptly delete this e-mail and any attachment and all copies
> and
> >> > >inform
> >> > >> the sender. Thank you.
> >> > >>
> >> > >>
> >> > >should not be copied, disclosed to, retained or used by, any
> other
> >party.
> >> > If you are
> confidential
> confidential

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 23 Sep 2011 12:16:11 +0530

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

>Sent: Friday, September 23, 2011 1:37 AM
>To: Ravindran Parthasarathi; Leon Portman; Elwell, John; Feenstra,
>Friso; [email-masked]
>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).
>
>
>
>
>> >> Siemens Enterprise Communications Limited is a Trademark Licensee
>of
>> >> Siemens AG.
>> >>
>> >>
>> >> > sequence  for example as incoming call from UA A to UA B, where
>UA
>> B
>> >> > is SRC.
>> >> > SRS and like the softswitch (acting as a SIP proxy) is deployed
>on
>> a
>> >> > central location.
>(Policy
>> >> > As such I would appreciate the option of a SRS based Invite in
>the
>> >> > standards.
>> >> >
>> >> > As an individual,
>> >> >
>> >> > Regards,
>> >> >
>> >> > Friso
>> >> > >> available streams it would like for recording, either in an
>ACK
>> >> > >response or
>> >> > >>
>> >> > >> through a re-Invite.
>> >> > >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 10:03:31 +0200

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)

> Sent: 23 September 2011 07:46
> To: Hutton, Andrew; Leon Portman; Elwell, John; Feenstra,
> Friso; [email-masked]
> 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
>
>
> >> decomposed SRC media box. Please correct in case any other
> advantage
> >in
> >> >I also noticed a mistake in section 3.2.2 of the
> architecture draft
> >in
> >> >Registered office: Brickhill Street, Willen Lake, Milton
> Keynes, MK15
> >> >0DJ.
> >> >Siemens Enterprise Communications Limited is a Trademark
> Licensee of
> >> >Siemens AG.
> >> >
> >> >
> >> >
> [mailto:[email-masked]] On
> >> >> Behalf Of Elwell, John
> >> >> current CS of a particular user). Based on this it can
> construct a
> >> URI
> >> >> Since SRS-initiated INVITEs do not require any new SIP
> mechanism,
> >it
> >> >> > softswitch and SRS is out of scope for the SIPREC
> standard, but
> >> most
> >> >> > 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
> >> >> > calling UA B) 4. SRS decides to record and sends RS
> INVITE with
> >> SDP
> definitely
> >> >> > looking for a SIPREC solution where the SRC is
> implemented on the
> >> UA
> >> >> > (agent handset).
> >> >> >
> definition
> >is
> >> >> > Having all the agent handsets always start a RS
> session for each
> >> CS
> [mailto:[email-masked]]
> >On
> >> >> > >of-band information is the identification of the
> SRC. Based on
> >> this
> >> >> > information
> [mailto:[email-masked]]
> >On
> >> >> > >Behalf Of Paul Kyzivat
> >> >> > >> solution with agents dispersed around the globe.
> The business
> >> >> > >intelligence
> >> >> > >>
> >> >> > >> An option could be that the SRS sends an offerless
> invite, as
> >> >> > >currently
> >> >> > >>
> >> >> > >> contain proprietary material, confidential
> information and/or
> >> be
> >> >> > >confidential information and/or be subject to legal
> privilege.
> >It
> >> >> > information and/or be subject to legal privilege. It
> should not
> >be
> >> >> > information and/or be subject to legal privilege. It
> should not
> >be

---

From: "Feenstra, Friso" <[email-masked]>
Date: Fri, 23 Sep 2011 08:22:30 +0000

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

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 10:42:23 +0200

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

> Sent: 23 September 2011 09:23
> To: Elwell, John; Ravindran Parthasarathi; Hutton, Andrew;
> Leon Portman; [email-masked]
> 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)
>
> 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)
>
> > >> 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
> > >>
> > >> is interested for some specific callflow but I'm not
> interested to
> > >hear
> > >> >From: Hutton, Andrew
> [mailto:[email-masked]]
> > >> >Server" as this refers to the case when the SRS
> generates the SDP
> > >> offer.
> > >> >> > send to start the RS session, next the SRC will
> provide the CS
> > >> info
> > >> >> > The business intelligence (Policy Manager) in our
> case is with
> > >the
> > >> >> > Manager) and softswitch (CTI based API) and between
> softswitch
> > >and
> > >> >> > >information the SRS determines that RS is needed.
> Part of the
> > >> out-
> > >> >> > >is on a per-agent basis? Or does an SRC cover many
> agents and
> > >> many
> > >> >> > >concurrent calls?
> > >> >> > >
> > >> >> > >> describing the available sessions. With this
> knowledge and
> > >> based
> > >> >> on
> > >> >> > >the
> > >> >> > >>
> > >> >> > >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
> > >> >> > >> is for authorised use by the intended
> recipient(s) only. It
> > >may
> > >> >> > copied, disclosed to, retained or used by, any
> other party. If
> > >you
> > >> >> > copied, disclosed to, retained or used by, any
> other party. If
> > >you

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 23 Sep 2011 11:13:28 +0200

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.

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

> From: Elwell, John
> Sent: 23 September 2011 09:42
> To: Feenstra, Friso; Ravindran Parthasarathi; Hutton, Andrew; Leon
> Portman; [email-masked]
> 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
>
>
> > > >> >something that we intended to cover in SIPREC hence the
> existing
> > > >> section
> > > >> >start recording this could be via CTI, SIP Dialog Events or
> many
> > > >> others
> > > >> >> > 1. UA A sends CS INVITE to softswitch 2. softswitch sends
> CS
> > > >> INVITE
> > > >> >> > softswitch is involved as SIP-proxy in all session setup
> and
> > > >since
> > > >> >> > >> of what and when to record will be at the SRS, so the
> SRS
> > > >> should
> > > >> >> be
> > > >> >> > >capable
> > > >> >> > >>
> > > >> >> > >> by, any other party. If you are not an intended
> recipient
> > > >> >> > then please

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 12:03:37 +0200

> Sent: 23 September 2011 10:13
> To: Elwell, John; Feenstra, Friso; Ravindran Parthasarathi;
[JRE] Yes, I misread Friso's email.

>
> 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.
[JRE] Yes, we might want to specify the response code to be used, e.g., 403.

>
> 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.
[JRE] Possibly "siprec" or "session-recording" would be appropriate.

John

> > > > >> 1) There is no need of extra CTI or equivalent
> channel between
> > > > >> softswitch & SRS.
> > > > >> >What I think we do need to do is tidy up the
> architecture draft
> > > > >> (Section
> > > > >> >> > in the OK with SDP and Metadata and the SRS
> will select the
> > > > >> correct
> > > > >> >> > long back. The mentioned callflow is not good
> design in my
> > > > >opinion
> > > > >> >> > >> As a new participant I would like to make
> the following
> > > > >remark.
> > > > >> >> > >>
> > > > >> >> > >> starting and stopping RS sessions. We want
> to deploy a
> > > > >> >> > contact centre
> > > > >> >> > >>
> > > > >> >> > >And what is the granularity of the SRC? Are
> you imagining
> > > > >> >> > that the SRC
> > > > >> >> > >> 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
> > > > >> >> > >>
> > > > >> >> > >a facility, then it wouldn't scale reasonably,
> because the
> > > > >> >> > offer would
> > > > >> >> > >> Think green - keep it on the screen. This
> e-mail and any
> > > > >> >> > attachment
> > > > >> >> > >not an intended recipient then please promptly
> delete this
> > > > >> >> > e-mail and

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 26 Sep 2011 08:28:14 -0700

By specifying a reject response code, are we putting extra normative statements about whether an SRC would support SRS-initiated dialogs? In other words, the SRC has the option to not support such dialogs?

Henry 

> Sent: September-23-11 6:04 AM
> To: Hutton, Andrew; Feenstra, Friso; Ravindran Parthasarathi; Leon
> Portman; [email-masked]
> > > > > >> >the 4th bullet "Session Recording Client" should be
> "Session
> > > > > >Recording
> > > > > >> >> > >> determining what's to be recorded and of starting
> the
> > > RS.
> > > > > >> >> > >
> > > > > >> >> > >This e-mail and any attachment is for authorised use
> by
> > > the
> > > > > >> >> > >intended

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Sep 2011 18:40:02 +0200

Henry,

I don't really mind whether we specify the response code or not, but clearly, if an SRC implementation chooses not to support this, it would need to reject the INVITE request somehow, and I felt we might give guidance by specifying (or perhaps just suggesting) a response code.

John

> From: Henry Lum [mailto:[email-masked]]
> Sent: 26 September 2011 16:28
> To: Elwell, John; Hutton, Andrew; Feenstra, Friso; Ravindran
> Parthasarathi; Leon Portman; [email-masked]
> By specifying a reject response code, are we putting extra
> normative statements about whether an SRC would support
> SRS-initiated dialogs? In other words, the SRC has the option
> to not support such dialogs?
>
> Henry
>
> > [JRE] Yes, we might want to specify the response code to be
> used, e.g.,
> > 403.
> >
> > >
> > > > > > >INVITE's from the SRS is an implementation option
> if it does
> > > > > > not the SRC
> > > > > > >> solution. I look at Friso recording topology as
> decomposed
> > > > > > SRC to SRS
> > > > > > >> 2) Softswitch communicates with SRS in the
> standard SIPREC
> > > > > > RS session
> > > > > > >> 3) Based on SRS negotiation, softswitch
> indicates to agent
> > > > > > phone using
> > > > > > >> there is no difference for agent-phone between
> SRS-initiated
> > > > and
> > > > > > >> >3.2.2) which covers this use SRS initiated
> recording.  We
> > > > > > need to say
> > > > > > >> >> Basically the SRS knows, through some
> out-of-band means
> > > > > > (e.g., CTI,
> > > > > > >> >> > c. I anticipate that the forwarding by the
> softswitch
> > > > > > of Invite
> > > > > > >> >> > Another reason why this is not a good idea,
> is that an
> > > > extra
> > > > > > >> >> > not needed and only minimal changes are
> needed on the
> > > > > > softswitch
> > > > > > >> >> > acting as a SIP proxy.
> > > > > > >> >> >
> > > > > > >> >> > SRS with CS id.  Please let me know the
> issue in this
> > > > > > approach.
> > > > > > >> >> >
> > > > > > >> >> > Thanks
> > > > > > >> >> > Partha
> > > > > > >> >> >
> > > > > > >> >> > >Business intelligence is in the SRS. SRS
> is informed
> > > > > > >> >> > out-of-band that
> > > > > > >> >> > >Could you explain more about how the
> intelligence is
> > > > > > >distributed?
> > > > > > >> >> > >> promptly delete this e-mail and any
> attachment and
> > > > > > all copies
> > > > > > >> and
> > > > > > >> >> > >inform
> > > > > > >> >> > >> the sender. Thank you.
> > > > > > >> >> > >>
> > > > > > >> >> > >>
> > > > > > >> >> > >any attachment and all copies and inform
> the sender.
> > > > > > Thank you.
> > > > > > >> >> > >
> > > > > > >> >> > >
> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached
> may contain confidential and proprietary information of
> Alcatel-Lucent and/or its affiliated entities. Access by the
> intended recipient only is authorized. Any liability arising
> from any party acting, or refraining from acting, on any
> information contained in this e-mail is hereby excluded. If
> you are not the intended recipient, please notify the sender
> immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other
> person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 26 Sep 2011 23:10:32 +0530

Henry,

I wish to have SRC implementation which does not support these SRS 
initiated dialogs. The reason for such SRC implementation is that 
SRC has no need to implement SIP "join" operation or other 
SRS-initiated mechanism to compliance with SIPREC specification.

IMO, It is more appropriate to spell out the exact response
code by SRC which helps for SRS to find other fallback options.

Thanks
Partha

>Sent: Monday, September 26, 2011 10:10 PM
>To: Henry Lum; Hutton, Andrew; Feenstra, Friso; Ravindran Parthasarathi;
>I don't really mind whether we specify the response code or not, but
>clearly, if an SRC implementation chooses not to support this, it would
>need to reject the INVITE request somehow, and I felt we might give
>guidance by specifying (or perhaps just suggesting) a response code.
>
>John
>
>