Re: [dispatch] Comments on draft-jain-dispatch-session-recording-protocol-req-00

["Doken, Serhad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Leon Portman
> Sent: Saturday, July 25, 2009 7:10 PM
> To: Alan Johnston; [e-mail]
> Subject: Re: [dispatch] Comments on draft-jain-dispatch-session-
> recording-protocol-req-00
> 
> Alan, Hi
> 
> Thanks for the comments.
> 
> Please see below my answers
> 
> Regards
> 
> Leon
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Alan Johnston
> Sent: Friday, July 24, 2009 9:29 PM
> To: [e-mail]
> Subject: [dispatch] Comments on draft-jain-dispatch-session-recording-
> protocol-req-00
> 
> Here are my comments on this draft.
> 
> Overall, I think this draft is an excellent start at the requirements
> for this important topic.  I look forward to future discussions of
> charter text so we can get started on the work.
> 
> Section 2:
> 
> "  Another, related IETF draft is draft-wing-sipping-srtp-key
>    [I-D.wing-sipping-srtp-key], which describes an approach for
>    providing SRTP session keys to a recorder-type server.  That draft
>    focuses on the mechanism to provide the SRTP session key, rather
> than
>    the mechanism to invoke and sustain recording sessions themselves."
> 
> draft-wing-sipping-srtp-key actually has a lot of discussion, including
> call flows showing how recording sessions can be established.  Also,
> this document has four recording modes discussed, which I think should
> be discussed in this document.  Two are mentioned without really
> explaining them, and two others are implied by various requirements.
> 
> [LeonP] Yes, for the protocol draft, we will need to combine all of the
> approaches and make sure that we covered all use cases
> 
> Section 3:
> 
> " Recording Session: The session created between an RC and RS for the
>    purpose of recording a Recorded Session.  The Recorded Session may
>    itself be based on SIP, but it is a separate session from the
>    Recording Session.
> 
>    Recorded Session: A session created between a UAC and UAS that is
>    recorded by the RC and RS systems."
> 
> 
> These two terms only differ by their tense, yet I think one refers to a
> signaling session and the other refers to a media session.  If so,
> better terms and definitions are needed.  If not, we need a term for
> the
> actual recorded media.  Also, there are (at least) two sessions here -
> the one between the UAs and the Recording Session - in a few places I
> suspect the two are being confused.
> 
> [LeonP] Actually Recording Session relates to both SIP and Media that
> is forked to the recording server and Recorded Session is actually the
> original conversation between two UAs. These two are exactly the two
> sessions that you are describing.
> 
> "  Dynamic Recording: Dynamic recording is a mode of recording where
> the
>    recording sessions are established on an as needed basis.  The
> length
>    of these sessions is typically same as the length of the actual
> media
>    sessions.
> 
>    Persistent Recording: Persistent recording is a mode of recording
>    where the recording sessions are established at system start-up and
>    kept-alive from that point on.  The length of these sessions is
>    independent from the length of the actual recorded media sessions.
>    Persistent recording sessions avoid issues such as media clipping
>    that can occur due to delays in recording session establishment."
> 
> These terms need more explanation as I can think of multiple things
> they
> might mean.  For example, when you say "session" do you mean a
> signaling
> session or media session?  When you talk about avoiding media clipping,
> do you mean that media is always sent by the RC to the RS regardless of
> whether there is any media?
> 
> [LeonP] Yes, by session we mean both legs: signaling and media. And in
> Persistent Recording mode, the Recording SIP session supposed to stay
> connected even there is not actual connected sessions for the specific
> recorded UA.
> 
> Figures could use Figure numbers and labels.  Also, it would be worth
> showing which is the RC and which is the RS in them.
> 
> Section 5
> 
> "   o REQ-001 The mechanism MUST support the ability to perform
>    persistent (always-on) or dynamic (on-demand) Recording Sessions."
> 
> I'm not sure that the Persistent and Dynamic Recording as defined above
> correspond to the Always On and On Demand modes defined in
> http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-4.
> 
> [LeonP] It is different in the way that the Recording Session is
> established only once during initialization (or login events) and then
> only media is forwarded per each call in order to minimize the
> clipping.

I see the "Always On" Recording as a separate third mode of Recording where for a particular one or set of devices(possibly set via provisioning), all calls are recorded from start to end(by setting up recording sessions) and no persistent recording sessions are kept for them.

> 
> "   o REQ-002 The mechanism MUST support the ability to perform
>    persistent Recording Sessions, such that the connection and
>    attributes of media in the Recording Session are not dynamically
>    signaled for each Recorded Session before it can be recorded.  Call
>    details and metadata will still be signaled, but can be post-
>    correlated to the recorded media.  There will still need to be a
>    means of correlating the recorded media connection/packets to the
>    Recorded Session, however this may be on a permanent filter-type
>    basis, such as based on a SIP AoR of an agent that is always
>    recorded, or based on identifiers in the recorded media itself."
> 
> 
> Without fully understanding Persistent Recording, I can't evaluate this
> requirement.
> 
> "   o REQ-009 The mechanism MUST support the ability to deliver mixed
>    media streams to the RS.  The RS MAY be informed about the
>    composition of the mixed streams through session metadata.
> 
>    Note: A mixed media stream is where several recorded sessions are
>    carried in a single recording session.  A mixed media stream is
>    typically produced by a mixer function."
> 
> 
> I'm not clear what mixed media means here - does it mean a mix of media
> types - synchronized audio and video from the same session, or do you
> mean multiple media streams from different sessions?  The note seems to
> indicate that this relates only to a conference call where multiple
> sources (SSRCs) have been combined into a single RTP session.
> 
>  [LeonP] It is specific trading floor environment requirements where
> multiple handset and speakers for specific turrets will be mixed on the
> turret level for recording by one recording channel.
> 
> 
> "   o REQ-013 The mechanism MUST support the ability to inject tones
> into
>    the Recorded Session either from the RS or from the RC."
> 
> Recorded Session seems to be defined as the media between the RC and
> RS.  Is that where the injected tones should be?  Or should then be
> mixed in the media between the two UAs?
> [LeonP] we have multiple options here. Preferable solution that one of
> the UAs will inject them (triggered by policy or parameters in SRP),
> but there are also configuration where RS will be required to create
> them and send back to RC (like talking clock for example)
> 
> "   o REQ-021 The mechanism MUST support the ability for the RC to only
>    perform media replication to the RS, without needing to decode or
> mix
>    audio/video/etc., and without needing to be an RTP agent.  This will
>    allow the RC to replicate media at layers below RTP.  Clearly, such
>    an RC mode would not be able to provide transcoding, or media
>    injection from the RS back into the Recorded Session."
> 
> Does this mean that you think that RTP is unsuitable for transporting
> media between the RS and RC?  Clearly it isn't for IM, but I would
> think
> that many of the functions of RTP are needed for audio and video media.
> To understand this requirement will take more discussion.
> 
> [LeonP] Actually it was Hadriel requirement. I believe it only means
> that RC does not required to implement RTP stack, it can just fork RTP
> packets on the network level (by hardware)

Most such middlebox media forkers will have RTP stack implemented anyway. Though packet replication can be done at a lower layer, it'd probably still need the smarts to know the replicated packet is actually a RTP packet to determine which packet to replicate.

> 
> Thanks,
> Alan
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch