Subject: Re: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 2 May 2011 23:52:14 +0530

As part of the discussion about Metadata and RTP model with lot of
folks, I realized that it is better to show "UA instance" which is
associated with SRC to create RS as a separate instance. Fig 4 in the
draft shall be updated as 

                                        Session Recording Server (SRS)
                                                    +----------+
                 (Recording Session)                |          |
           +-----------SIP------------------------->|   UA-A   |
           |                                        |   (SRS)  |
           |                                        +----------+
           |  Session Recording Client (SRC)           |
    +----------------------------------------+         |
    |  +-----------+                         |         |
    |  |  Session  |          +------------+ |         |
    |  | Recording |          |            | |         |    +---------+
    |  |   UA      |          |   Media    | | <--RTP--+    |         |
    |  +-----------+          |            | |              |         |
    |        ^                |            | |              |         |
    |        |                |            | |              |         |

    |        V                |            | |              |         |
    |  +-----------+          |   Server   | |              |  UA-B   |
    |  | MediaCtrl |MEDIACTRL |            |<-----RTP------>|         |
    |  |Application|<-------->|            | |              +---------+
    |  |  Server   |          +------------+ |                   ^
    |  +-----------+                         |                   |
    +--------^-------------------------------+                   |
             |                                                   |
             +-----------------------SIP-------------------------+
                              (Communication Session)

           Figure 4: Example of Session Recording Client using MEDIACTRL

Here in the above figure, session recording UA is a separate UA instance
apart from CS  creating UA (Mediactrl application server) instance.
Cooridination between Session Recording UA and Mediactrl application
server is outside the scope of SIPREC. The same logical figure shall be
extended to other SRC architecture figure by which the importance of SIP
based RS UA with non-sip CS is clear. Please let me know opinion on the
same.

Thanks
Partha  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, April 13, 2011 7:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the SIP Recording Working Group of the
IETF.

	Title           : An Architecture for Media Recording using the
Session Initiation Protocol
	Author(s)       : A. Hutton, et al.
	Filename        : draft-ietf-siprec-architecture-02.txt
	Pages           : 16
	Date            : 2011-04-13

Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons.  Recording of a session is
typically performed by sending a copy of a media stream to a recording
device.  This document describes architectures for deploying session
recording solutions in an environment which is based on the Session
Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-02.tx
t

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 May 2011 16:10:57 +0200

Hi Partha,

I don't understand the need for showing the decomposition of the SRC in this way. The current figures in the architecture document are there to help explain the relationship to Mediactrl but I don't see the value in this change.

It also appears to incorrectly show the SIP based Communication Session terminating at the MediaCtrl application server.

Maybe we could discuss why you think we need this in the interim next week.

Regards
Andy   

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 02 May 2011 19:22
> To: [email-masked]
> Subject: Re: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt
> 
>     |  +-----------+          |            | |              | 
>         |
>     |        ^                |            | |              | 
>         |
>     |        |                |            | |              | 
>         |
>     |        V                |            | |              | 
>         |
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 5 May 2011 22:35:42 +0530

Hi Andy,

Let me explain with simple SRC examples for the need of this
decomposition. 

SRC is non-SIP entity namely H.323 gateway which has SIP UA for
recording purpose only. CS of SRC is H.323 session whereas RS is SIP
session. In these scenario, the architecture has to mention both H.323
gateway, SIP UA combination as SRC instead of mere H.323 gateway as SRC.

In case you foresee more discussion required, let us discuss on interim
meeting.

Thanks
Partha 

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 7:41 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt

Hi Partha,

I don't understand the need for showing the decomposition of the SRC in
this way. The current figures in the architecture document are there to
help explain the relationship to Mediactrl but I don't see the value in
this change.

It also appears to incorrectly show the SIP based Communication Session
terminating at the MediaCtrl application server.

Maybe we could discuss why you think we need this in the interim next
week.

Regards
Andy   

> Here in the above figure, session recording UA is a separate UA 
> instance apart from CS  creating UA (Mediactrl application server) 
> instance.
> server is outside the scope of SIPREC. The same logical figure shall 
> be extended to other SRC architecture figure by which the importance 
> of SIP based RS UA with non-sip CS is clear. Please let me know 
> opinion on the same.
> 
> Thanks
> Partha
> 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> compliance, and consumer protection reasons.  Recording of a session 
> is typically performed by sending a copy of a media stream to a 
> recording device.  This document describes architectures for deploying

> session recording solutions in an environment which is based on the 
> Session Initiation Protocol (SIP).
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 May 2011 20:08:31 +0200

Hi Partha,

Of course it could be that the SRC is recording something other than a SIP session and using SIPREC with the SRS. However for the purposes of SIPREC the definiton of the CS is as follows:

"Communication Session (CS):  A SIP session created between two or more UA's for the purpose of communication which may be recorded."

Therefore I believe your scenario is out of scope and should not be covered in the architecture draft.

I noticed a slight difference between the architecture and requirements draft on the definition but it is only in the wording and both state that it is a SIP session.

Regards
Andy

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 05 May 2011 18:06
> To: Hutton, Andrew; [email-masked]
> > Subject: Re: [siprec] I-D 
> Action:draft-ietf-siprec-architecture-02.txt
> >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 9 May 2011 09:15:11 +0530

Andy,

I wrongly thought of CS may be any signaling protocol (Jingle, PSTN)
based on earlier mailer discussion and provided the example which is
outside the scope of SIPREC. I'll provide the use case which is within
SIPREC now:

        A + SRC--------------B
           |
            -----------------SRS

In the above topology, A & B are acting as UA. The scenario is as
follows:

1) B starts INVITE (CS) towards A by acting as "uac"
2) A receives INVITE (CS) and act as "uas"
3) A sends response towards B which is a normal SIP UA behavior and
apart from this, A (SRC) has to send INVITE (RS) towards SRS by acting
as "uac". My point here is that A acts as kind of B2BUA rather than
simple UA but current architecture depicts as UA.

By introducing the decomposition within SRC, it will be clear that A
acts as uas towards B and A acts as uac towards SRS and two instance of
UA involved in each SRC session. Let us discuss in detail during today's
meeting.

Thanks
Partha

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 11:39 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] I-D Action:draft-ietf-siprec-architecture-02.txt

Hi Partha,

Of course it could be that the SRC is recording something other than a
SIP session and using SIPREC with the SRS. However for the purposes of
SIPREC the definiton of the CS is as follows:

"Communication Session (CS):  A SIP session created between two or more
UA's for the purpose of communication which may be recorded."

Therefore I believe your scenario is out of scope and should not be
covered in the architecture draft.

I noticed a slight difference between the architecture and requirements
draft on the definition but it is only in the wording and both state
that it is a SIP session.

Regards
Andy

> In case you foresee more discussion required, let us discuss on 
> interim meeting.
> 
> Thanks
> Partha
> 
> I don't understand the need for showing the decomposition of the SRC 
> in this way. The current figures in the architecture document are 
> there to help explain the relationship to Mediactrl but I don't see 
> the value in this change.
> 
> It also appears to incorrectly show the SIP based Communication 
> Session terminating at the MediaCtrl application server.
>