Subject: [siprec] Updated architecture draft after WGLC comments

From: Leon Portman <[email-masked]>
Date: Wed, 30 May 2012 15:38:46 +0300

Hello

I just published updated draft after WGLC comments.

Main changes:

1.       Ram's comments: aligning definitions and terms with requirements and metadata drafts, figures fixing, references updates

2.       Charles comments:

a.       Fixing  B2BUA honoring statements (also was comment from Ram). Next text:
The B2BUA/SRC is responsible for complying with requests from recording aware UAs or through some configured policies indicating that the communication session should not be recorded.

b.      Terms fixing and spelling mistakes

c.       Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5.

d.      IANA reference to the protocol draft

e.      Updates in the security section

3.       IETF 83 meeting minutes
Leon

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 31 May 2012 19:16:44 +0000

Hi Leon,

I'm not very clear about the following text in Sec 3.2.2

"   o  Identify the session that is to be recorded.  The actual mechanism
      of the identification depends on SRC policy."

I agree with you in case of SIP UA acts as SRC, the local policy will serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the local policy may not be sufficient as some indication required to which session has to be indicated by SRS as the number of recording session or number of CS within the single RS will vary drastically from 1 session to 1000+ session at a given time. The issue based on local policy over protocol mechanism is that (B2BUA+) SRC  MUST depend on proprietary session-id from SRS in the actual deployment.

I'm writing the following solution to explain the issue in the above text.  As per http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html thread, I understand that session-id may not be generic enough solution as it is not applicable to persistent usecase wherein session-id does not exist when RS is established. So, I thought of proposing a solution based on new header namely "recording-join" header which shall have
Information about:

1)      Communication session-id

2)      Participant id

3)      Communication session group id

4)      Stream id ???

5)      Dialog (Normal Join)

The header format shall be "Recording-join: id; type=CS/Participant/CSG/stream/dialog".

Please let me know your opinion on this approach.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Wednesday, May 30, 2012 6:09 PM
To: [email-masked]
Subject: [siprec] Updated architecture draft after WGLC comments

Hello

Main changes:

2.       Charles comments:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 15:44:33 -0400

I thought the definition of a mechanism for the SRS to indicate what to 
record to an SRC had been declared out of scope for our current effort.

	Thanks,
	Paul

On 5/31/12 3:16 PM, Ravindran, Parthasarathi wrote:
> Hi Leon,
>
> I’m not very clear about the following text in Sec 3.2.2
>
> “o Identify the session that is to be recorded. The actual mechanism
>
> of the identification depends on SRC policy.”
>
> I agree with you in case of SIP UA acts as SRC, the local policy will
> serve the purpose. In case of SIP B2BUA (SBC/IP PBX) acts as SRC, the
> local policy may not be sufficient as some indication required to which
> session has to be indicated by SRS as the number of recording session or
> number of CS within the single RS will vary drastically from 1 session
> to 1000+ session at a given time. The issue based on local policy over
> protocol mechanism is that (B2BUA+) SRC MUST depend on proprietary
> session-id from SRS in the actual deployment.
>
> I’m writing the following solution to explain the issue in the above
> text. As per
> http://www.ietf.org/mail-archive/web/siprec/current/msg03198.html
> thread, I understand that session-id may not be generic enough solution
> as it is not applicable to persistent usecase wherein session-id does
> not exist when RS is established. So, I thought of proposing a solution
> based on new header namely “recording-join” header which shall have
>
> Information about:
>
> 1)Communication session-id
>
> 2)Participant id
>
> 3)Communication session group id
>
> 4)Stream id ???
>
> 5)Dialog (Normal Join)
>
> The header format shall be“Recording-join: id;
> type=CS/Participant/CSG/stream/dialog”.
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Leon Portman
> *Sent:* Wednesday, May 30, 2012 6:09 PM
> *To:* [email-masked]
> *Subject:* [siprec] Updated architecture draft after WGLC comments
>
> Hello
>
> 1.Ram's comments: aligning definitions and terms with requirements and
> metadata drafts, figures fixing, references updates
>
> 2.Charles comments:
>
> a.Fixing B2BUA honoring statements (also was comment from Ram). Next text:
>
> The B2BUA/SRC is responsible for complying with requests from recording
> aware UAs or through some configured policies indicating that the
> communication session should not be recorded.
>
> b.Terms fixing and spelling mistakes
>
> c.Rephrasing in section 3.1.4, 3.2, 32.2., 3.2.5.
>
> d.IANA reference to the protocol draft
>
> e.Updates in the security section
>
> 3.IETF 83 meeting minutes
>
> Leon
>
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 1 Jun 2012 02:17:20 +0000

Paul,

Sorry in case I'm reopening the discussion as the current proposed 
mechanism proposes for the usage of proprietary vendor specific id 
in the B2BUA+SRC deployment. 

Some of the deployment uses SBC (B2BUA) as SRC, IP PBX 
provides vendor specific CS id to SBC as well as to SRS and SRS 
request for selective CS to be recorded using SRS initiated 
recording mechanism. The point to be noted is that SBC has number 
of CS simultaneously and not all the sessions are requested by SRS 
to record (Selective recording). Here, SRC configuration (local policy)
will not serve the purpose. 

Of course, this issue is not applicable for SRC initiated sessions 
as SRS shall reject selectively when RS INVITE is received.

Thanks
Partha 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Paul Kyzivat
>Sent: Friday, June 01, 2012 1:15 AM
>To: [email-masked]
>Subject: Re: [siprec] Updated architecture draft after WGLC comments
>
>> "o Identify the session that is to be recorded. The actual mechanism
>>
>> local policy may not be sufficient as some indication required to
>> which session has to be indicated by SRS as the number of recording
>> session or number of CS within the single RS will vary drastically
>> from 1 session to 1000+ session at a given time. The issue based on
>> local policy over protocol mechanism is that (B2BUA+) SRC MUST depend
>> on proprietary session-id from SRS in the actual deployment.
>>
>> I'm writing the following solution to explain the issue in the above
>> text. As per
>> thread, I understand that session-id may not be generic enough
>> solution as it is not applicable to persistent usecase wherein
>> session-id does not exist when RS is established. So, I thought of
>> proposing a solution based on new header namely "recording-join"
>> header which shall have
>>
>> Information about:
>>
>> The header format shall be"Recording-join: id;
>> type=CS/Participant/CSG/stream/dialog".
>>
>> The B2BUA/SRC is responsible for complying with requests from
>> recording aware UAs or through some configured policies indicating
>> that the communication session should not be recorded.
>>