Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and persistent recording?

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 1 Jul 2010 08:55:24 -0400

Hi Paul,

> Jain, Rajnish wrote:
> > While theoretically SIP dialogs created through INVITE or SUBSCRIBE
> should be equivalent in terms of SRS and SRC UA scalability, the
> reality is that most implementations reserve RTP channels for INVITEs.
> Mechanims have been designed to avoid that (e.g. black-holed SDP or
> setting m= line port number to zero), but I think most implementations
> are not interoperable in that respect.
>
> Do you have data to back this up?

Not something that I can report here. SDP interop has always been a pain-point IMHO and when we get to these subtle details, the SDP interop becomes even tougher.

> Note that discussion seems to be going in the direction of multiple
> m-lines (to deal with independent streams for participants and media),
> with the number of such m-lines being variable. Under such an approach
> the recording server must assign ports dynamically based on the m-lines
> received. In that environment, what would be the reason to reserve
> ports
> for m-lines that don't exist, have been rejected, or that are black-
> holed.

That sounds fine. I think newer implementations (especially the ones that claim to be SIPREC-aware should be able to handle this.

Thanks,
Raj

>
>       Thanks,
>       Paul
>
> > REFER or redirection (302) are probably acceptable solutions to this.
> >
> > Raj
> > ________________________________________
> > From: [email-masked] [[email-masked]] On Behalf Of
> Henry Lum [[email-masked]]
> > Sent: Friday, June 25, 2010 12:59 PM
> > To: Leon Portman; Brian Rosen
> > Cc: [email-masked]
> > Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and
> persistent      recording?
> >
> > Wouldn't SIP subscriptions have the same problem as a SIP dialog with
> > maintaining the state if you want to replicate with a backup
> instance?
> >
> > I do understand from implementation point of view that INVITE
> sessions
> > can potentially cost more to maintain especially if the recorder
> > reserves media for each SIP dialog even if no media is required. If
> an
> > SRS sits on reserved media resources but no recording is happening
> then
> > it can be costly to deploy. However, I think implementations can
> avoid
> > this problem for dynamic recording by using mechanisms like REFER to
> > send the RS to an actual recorder instance with media resources.
> >
> > Henry
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Leon Portman
> >> Sent: June-24-10 9:06 AM
> >> To: Brian Rosen
> >> Cc: [email-masked]
> >> Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and
> >> persistent recording?
> >>
> >> I agree from the pure SIP point of view, however from the actual
> >> implementation point of view, where these SIP sessions are supposed
> to
> >> be handled by resilient SIP Proxies with state replication (because
> > the
> >> need to hide the actual topology of SRS recording servers) and do
> some
> >> kind of REFERs or SDP updates to actual recording boxes, it became
> > very
> >> heavy and resource intensive. In addition, at least for our SIP
> stack
> >> implementation, handling of new INVITE is much heavier task then
> >> receiving notify event as part of the established SIP session.
> >>
> >> Leon
> >>
> >> -----Original Message-----
> >> From: Brian Rosen [mailto:[email-masked]]
> >> Sent: Thursday, June 24, 2010 3:50 PM
> >> To: Leon Portman
> >> Cc: Elwell, John; [email-masked]
> >> Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and
> >> persistent recording?
> >>
> >> Where is it written that it's harder to maintain 10,000 SIP sessions
> > vs
> >> 10,000 SIP subscriptions?
> >> It is easy enough to keep a SIP session, especially if media is
> >> disabled, open to each phone.  You wouldn't "allocate a recording
> >> channel" for each of these, but you could pass metadata within the
> >> session, and activate the media whenever you needed to.  Of course,
> >> activating the media is a complete SIP transaction.
> >>
> >> Brian
> >>
> >> On Jun 24, 2010, at 8:24 AM, Leon Portman wrote:
> >>
> >>> I want to present two typical recording use cases.
> >>>
> >>> Use Case 1: Large financial institute with 10,000 phones in the
> Back
> >> Office. Only specific calls/part of the calls supposed to be
> recorded
> >> (where some financial advice is given by back office expert). It is
> > not
> >> feasible for each and every call, PBX (SRC) to try to create a SIP
> >> session with recording system (SRS) or even more, just keep
> recording
> >> channel allocated (persistent use case) for each phone. It is more
> >> elegant, just to have one open SIP SUBSCRIBE session between SRC and
> >> SRS and report metadata for all calls and initiate RS only when
> >> required.
> >>> Important clarification: even if calls are not recorded , recording
> >> system usually is required to store metadata.
> >>> Use Case 2: Same financial institute, 2000 seats Contact Center.
> All
> >> calls must be recorded. In such case, obviously, the best solution
> >> where PBX (SRC) for each and every call for these agents, will send
> >> INVITE to the recording system (SRS) with the metadata and it will
> get
> >> recorded. Or even, better, RS will be initiated upon agent login to
> > the
> >> phone - persistent use case.
> >>> My personal opinion, that we should for the first phase focus on
> > SRC-
> >>> SRC direction with metadata as part of the INVITE + INFO package,
> and
> >> defer other options to later stages.
> >>> Leon
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Elwell, John
> >>> Sent: Thursday, June 24, 2010 2:11 PM
> >>> To: [email-masked]
> >>> Subject: [siprec] Do we need both SRS-to-SRC establishment and
> >> persistent recording?
> >>> (as individual)
> >>> From the related thread on session establishment SRS to SRC, I seem
> >> to be picking up conflicting information.
> >>> On the one hand, I am hearing the message that persistent recording
> >> is required (and moreover an RTP stream needs to be kept open
> >> permanently) because there is no time for a re-INVITE on the RS (let
> >> alone a new INVITE to establish an RS) when the CS starts. This is
> to
> >> avoid clipping.
> >>> On the other hand, I am hearing that the SRS needs to receive
> >> "metadata" about a CS that is starting up, apply its own filtering
> >> rules to decide whether to record, and then establish an RS from SRS
> > to
> >> SRC. But surely this is going to be time consuming and very likely
> to
> >> involve clipping?
> >>> These seem to be in conflict. Perhaps it is possible to find a
> >> solution that satisfies both concerns. For example, we could have a
> >> persistent session that keeps open the RTP stream. When a CS starts
> > and
> >> the SRS receives the "metadata", it can decide whether to record
> >> content from the received RTP packets or throw them away. It could
> > also
> >> do a re-INVITE to set the stream to 'inactive' if it doesn't want to
> >> record, although that might be problematic if it suddenly decides,
> >> e.g., through receipt of fresh metadata, that it does want to
> record.
> >> So I am not sure we can satisfy both requirements (SRS choosing
> > whether
> >> to record versus avoiding clipping), unless we accept the bandwidth
> >> penalty of sending RTP that will be thrown away. Perhaps we need
> fresh
> >> proposals.
> >>>
> >>> Alternatively, it could be that for any given deployment you have
> to
> >> adopt one or the other model and accept its limitations. This means
> we
> >> would be specifying two solutions, which sounds like a bad thing.
> >>> (as chair)
> >>> We urgently need some clarification in this area, so please
> continue
> >> discussion. I don't feel I am able to even open a sensible ticket on
> >> the tracker without some further clarification of what the issue
> > really
> >> is.
> >>> John
> >>> _______________________________________________
> >>> 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
> >
> >
> > ---------------------------------------------------------------------
> ----------------------------------------------
> > 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.
> >
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> > DISCLAIMER: This e-mail may contain information that is confidential,
> privileged or otherwise protected from disclosure. If you are not an
> intended recipient of this e-mail, do not duplicate or redistribute it
> by any means. Please delete it and any attachments and notify the
> sender that you have received it in error. Unintended recipients are
> prohibited from taking action on the basis of information in this e-
> mail.E-mail messages may contain computer viruses or other defects, may
> not be accurately replicated on other systems, or may be intercepted,
> deleted or interfered with without the knowledge of the sender or the
> intended recipient. If you are not comfortable with the risks
> associated with e-mail messages, you may decide not to use e-mail to
> communicate with IPC. IPC reserves the right, to the extent and under
> circumstances permitted by applicable law, to retain, monitor and
> intercept e-mail messages to and from its systems.
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> >

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.