Subject: Re: [siprec] Updated architecture draft after WGLC comments

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 1 Jun 2012 15:51:18 +0000

Hi,

I believe we did agree to leave this out of scope for the moment maybe it is a possible future work item.

Regards
Andy (SIPREC Co-Chair).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ravindran, Parthasarathi
> Sent: 01 June 2012 03:17
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [siprec] Updated architecture draft after WGLC comments
> 
> 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
> >
> >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".
> >>
> >> 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
> >>
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 2 Jun 2012 01:46:29 +0000

Hi Andy,

I agree with you that The initial focus of SIPREC was based on SRC-initiated callflow and SRS-initiated callflow is added based on SIP UA+SRC. In the current mechanism SRS-initiated callflow is followed for B2BUA+SRC, It will be become three stage migration for the products which supports proprietary SRS initiated callflow with more interop issue in the deployment as follows:

1) Proprietary SRS initiated callflow with proprietary correlation-id
2) SIPREC SRS initiated callflow with proprietary correlation-id
3) SIPREC SRS initiated callflow with standard correlation-id

I'm fine in case SRS initiated callflow is completely outside the scope of SIPRECv1.0 as it is not fully analyzed. But unfortunately we are making the middle stance wherein defining the behavior based on SRC local policy (configuration) and it works only for SIP UA+SRC solutions and not for B2BUA+SRC. 

In case there is strong support for SRS initiated callflow within SIPREC, let us work for SRS initiated protocol mechanism as a separate work item and the architecture document will not propose the exact mechanism (like local policy) but only mention the support for SIPREC SRS-initiated callflow. Please let me know your opinion on this.

Thanks
Partha

>From: Hutton, Andrew [mailto:[email-masked]]
>Sent: Friday, June 01, 2012 9:21 PM
>To: Ravindran, Parthasarathi; Paul Kyzivat; [email-masked]
>Subject: RE: [siprec] Updated architecture draft after WGLC comments
>
>Hi,
>
>> 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
>>
>> >> I'm writing the following solution to explain the issue in the
>> >> above text. As per