Subject: Re: [siprec] SDP recording attribute usages

From: "Elwell, John" <[email-masked]>
Date: Fri, 1 Jul 2011 10:14:56 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 29 June 2011 20:06
> To: [email-masked]
> Subject: Re: [siprec] SDP recording attribute usages
> 
> inline
> 
> On 6/29/2011 12:42 PM, Elwell, John wrote:
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Henry Lum
> >> Sent: 29 June 2011 02:34
> >> To: [email-masked]
> >> Subject: [siprec] SDP recording attribute usages
> >>
> >> Hi,
> >>
> >> I want to explain how I see the a=record SDP attribute to be
> >> used to indicate recording.
> >>
> >> I see two main scenarios with party A and B where the SRC is
> >> one of the parties or the SRC is a B2BUA:
> >>
> >> 1)      party A is the SRC
> >>
> >> When party A as UAC is sending an offer, party A may indicate
> >> that recording is enabled and provide a=record:on in the SDP
> >> offer. Party B sees that Party A is declaring the media
> >> stream is being recorded. Party B is not an SRC and will not
> >> be recording so it sends an SDP answer with a=record:off. The
> >> SDP answer is telling party A that party B is not recording
> >> even though party A as an SRC will record.
> >>
> >> When a reINVITE is sent by party A or B, the offer/answer
> >> should indicate which party is continuing recording. For
> >> example, party B sends reINVITE for whatever reason, party B
> >> sends offer with a=record:off; when party A answers, party A
> >> will send a=record:on to indicate that recording is still 
> in progress.
> 
> As a continuation to the scenario, where B is not an SRC, 
> this seems fine.
> 
> It gets tricky if B is also capable of being an SRC. It might 
> want to do 
> its own recording, rather than relying on the recording A is 
> doing. Or 
> it might not. Does it respond based on whether it decides to 
> record? Or 
> based on whether it *could* record?
> 
> Assume it responds based on whether it does record. Then at the 
> reinvite, does it respond with a=record:no on the assumption 
> that A will 
> continue recording? It has no way to know that.
> 
> This seems similar to the issues around o/a for comedia.
> 
> 
> >> 2)      SRC is a B2BUA between party A and B
> >>
> >> This is similar to the above scenario, except that when party
> >> A is sending an SDP offer, party A sets a=record:off since
> >> party A is not recording. When the B2BUA gets the request and
> >> forwards to party B, the B2BUA is also trying to record as an
> >> SRC, the B2BUA rewrites the offer with a=record:on towards
> >> party B. Party B sees that the media stream is being recorded
> >> and sends SDP answer with a=record:off since party B is not
> >> recording. The B2BUA then passes the SDP answer but rewrites
> >> a=record:on to indicate to party A that the call is being recorded.
> 
> Do we also have the possibility of a b2bua that *isn't* an SRC, but 
> wants recording??? If so then we can get into situations more 
> like what 
> is done for session timer.
> 
> >> When the B2BUA needs to perform some 3rd party call control,
> >> B2BUA initiates a reINVITE to party A with no offer. Party A
> >> sends 200 OK answer with a=record:off to B2BUA. B2BUA sends
> >> reINVITE SDP offer to party B and sets a=record:on to
> >> indicate that the recording is still in progress. Party B
> >> responds 200 OK with SDP answer a=record:off. B2BUA rewrites
> >> the answer with a=record:on as ACK to party A.
> 
> This works ok as long as the b2bua is an src, and neither A nor B are.
> 
> If either A or B is a recorder, does the b2bua continue to record? Or 
> does it adjust its behavior? If it wants to adjust its behavior, how 
> does it get enough info to know that the recording being done by A 
> and/or B is sufficient?
> 
> > [JRE] There is another use case. The B2BUA turns recording 
> on or off for some reason during the course of the CS. 
> Presumably it would do similar to above, i.e., issue an 
> offerless INVITE request to one of the parties.
> 
> I don't think this last case adds anything fundamentally new to the 
> conveyance of the record flag.
> 
> *If* the goal of this attribute is just to ensure that all are aware 
> recording is proceeding, and not *who* is doing the 
> recording, and not 
> *negotiating* who is doing the recording, then something like 
> the above 
> is about right.
> 
> I think that must be the goal. If we want to introduce 
> negotiation over 
> who will do recording, things will be much more complex.
[JRE] If different SRCs on the path all have the potential to record, I would suggest that the fact that one is recording should not cause others not to record. The recording policy of each SRC should be independent of other SRCs. The 'recording' attribute does not indicate anything about the recording destination, so the assumption has to be that all the SRCs are sending to different SRSs. In many cases these will be in different domains (e.g., different enterprises). Even if two SRCs send recordings to the same SRS, they might need to be treated as different recordings (e.g., with different 'owners', different retention policy, etc.). I don't think we should attempt to cater for any optimisations for the special case where two SRCs are sending recordings to the same SRS for treatment as the same recording. So I think we are in agreement.

John (as individual)

> 
> 	Thanks,
> 	Paul
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 1 Jul 2011 10:11:48 -0700

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Friday, July 01, 2011 1:15 AM
> To: Paul Kyzivat (pkyzivat); [email-masked]
> [JRE] If different SRCs on the path all have the potential to record,
I would suggest that the fact
> that one is recording should not cause others not to record. The
recording policy of each SRC should
> be independent of other SRCs. The 'recording' attribute does not
indicate anything about the recording
> destination, so the assumption has to be that all the SRCs are sending
to different SRSs. In many
> cases these will be in different domains (e.g., different
enterprises). Even if two SRCs send
> recordings to the same SRS, they might need to be treated as different
recordings (e.g., with
> different 'owners', different retention policy, etc.). I don't think
we should attempt to cater for
> any optimisations for the special case where two SRCs are sending
recordings to the same SRS for
> treatment as the same recording. So I think we are in agreement.
> 
> John (as individual)

This was a use case I suggested previously, but it was deemed out of
scope, so I agree with John that this should not be an issue given our
limited scope of a SIPREC recording being limited to a single SRC and a
single SRS.

Cheers,
Charles

---

From: Leon Portman <[email-masked]>
Date: Sun, 3 Jul 2011 13:36:35 +0300

Hello

I agree with the logic below. Recording flag is only indication and not negotiation of who will do recording. 

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Friday, July 01, 2011 8:12 PM
To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] SDP recording attribute usages

Behalf Of Elwell, John
> > >> I want to explain how I see the a=record SDP attribute to be used 
> > >> to indicate recording.
> > >>
> > >> I see two main scenarios with party A and B where the SRC is one 
> > >> of the parties or the SRC is a B2BUA:
> > >>
> > >> 1)      party A is the SRC
> > >>
> > >> offer. Party B sees that Party A is declaring the media stream is 
> > >> being recorded. Party B is not an SRC and will not be recording 
> > >> so it sends an SDP answer with a=record:off. The SDP answer is 
> > >> telling party A that party B is not recording even though party A 
> > >> as an SRC will record.
> > >>
> > >> When a reINVITE is sent by party A or B, the offer/answer should 
> > >> indicate which party is continuing recording. For example, party 
> > >> B sends reINVITE for whatever reason, party B sends offer with 
> > >> a=record:off; when party A answers, party A will send a=record:on 
> > >> to indicate that recording is still
> > in progress.
> >
> > As a continuation to the scenario, where B is not an SRC, this seems 
> > fine.
> >
> > It gets tricky if B is also capable of being an SRC. It might want 
> > to do its own recording, rather than relying on the recording A is 
> > doing. Or it might not. Does it respond based on whether it decides 
> > to record? Or based on whether it *could* record?
> >
> > reinvite, does it respond with a=record:no on the assumption that A 
> > will continue recording? It has no way to know that.
> >
> > >> This is similar to the above scenario, except that when party A 
> > >> is sending an SDP offer, party A sets a=record:off since party A 
> > >> is not recording. When the B2BUA gets the request and forwards to 
> > >> party B, the B2BUA is also trying to record as an SRC, the B2BUA 
> > >> rewrites the offer with a=record:on towards party B. Party B sees 
> > >> that the media stream is being recorded and sends SDP answer with 
> > >> a=record:off since party B is not recording. The B2BUA then 
> > >> passes the SDP answer but rewrites a=record:on to indicate to 
> > >> party A that the call is being
recorded.
> > wants recording??? If so then we can get into situations more like 
> > what is done for session timer.
> >
> > >> reINVITE SDP offer to party B and sets a=record:on to indicate 
> > >> that the recording is still in progress. Party B responds 200 OK 
> > >> with SDP answer a=record:off. B2BUA rewrites the answer with 
> > >> a=record:on as ACK to party A.
> >
> > Presumably it would do similar to above, i.e., issue an offerless 
> > INVITE request to one of the parties.
> >
> > recording is proceeding, and not *who* is doing the recording, and 
> > not
> > *negotiating* who is doing the recording, then something like the 
> > above is about right.
> >
> > I think that must be the goal. If we want to introduce negotiation 
> > over who will do recording, things will be much more complex.
recordings (e.g., with
> treatment as the same recording. So I think we are in agreement.

This was a use case I suggested previously, but it was deemed out of scope, so I agree with John that this should not be an issue given our limited scope of a SIPREC recording being limited to a single SRC and a single SRS.

Cheers,
Charles