Subject: [siprec] SDP recording attribute usages

From: "Henry Lum" <[email-masked]>
Date: Tue, 28 Jun 2011 18:34:05 -0700

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.

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.

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.

I think these two scenarios should cover the main cases.

Regards,

Henry

-------------------------------------------------------------------------------------------------------------------
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.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Jun 2011 18:42:09 +0200

> -----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.
> 
>  
> 
> 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 
> 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.
[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.

John

> 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. 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jun 2011 15:06:30 -0400

inline

>> 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.

>> 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.

>> 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…

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.

	Thanks,
	Paul