Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.txt

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 1 Jun 2012 11:53:37 +0000

Leon,

I read through the draft.
It is already well progressed, but I also have some questions and comments.

Regards
Thomas

4. Overview of operations
 
The architecture document draft-ietf-siprec-architecture-04 describes scenarios where either the SRC or the SRS can establish the recording session. However, section 4 of the protocol document has the focus on the case where the SRC initiates the RS and doesn't describe the other option.  Other section have similar issues as detailed further down.

5.1. Procedures at the SRC
...
   In addition, when an SRC sends a REGISTER request
   to a registrar, the SRC MUST include the '+sip.src' feature tag to
   indicate the that it is a SRC.
 
This would only be the case if the SRC is located in a SIP UA. A B2BUA would not register.
Section 5.1 does not specify behaviour of the SRC when it receives the initial INVITE from the SRS.
How should the SRC behave when the SRS establishes a "permanent" recording session, how when the recording session is established mid-call. 
Is there a difference?
Should the user get any hint on its UI when the session is recorded?  
I saw some text afterwards in section 10, but that is far away. Maybe a hint would help?
 
5.2. Procedures at the SRS
 
Section 5.2 does not specify behaviour of the SRS when it receives the initial INVITE from the SRC.
E.g. is it a failure case when the '+sip.srs' feature tag or the "siprec" option tag is missing in the INVITE from the SRC?  Other parts of the draft talk about SIPREC-unaware UAs, so it's probably not an error?
 
6. SDP Handling
 
Although it sounds trivial, should the draft mention that SRC and SRS MUST support SDP with multiple m-lines?
 
6.1. Procedures at the SRC
 
   Since the SRC does not expect to receive media from the SRS, the SRC
   typically sets each media stream of the SDP offer to only send media,
   by qualifying them with the a=sendonly attribute, according to the
   procedures in [RFC3264].
 
Consider the the SRC sending an SDP answer with the direction attribute set to a=sendonly.
 
6.2. Procedures at the SRS
 
   The SRS only receives RTP streams from the SRC, the SDP answer
   normally sets each media stream to receive media, by setting them
   with the a=recvonly attribute, according to the procedures of
   [RFC3264].
 
The text only talks about SDP answers. If the SRS initiates the recording session it would set the direction attribute to a=recvonly in the SDP _offer_ of the INVITE. Of course, the SRS could send an offerless INVITE, which would again result in the SRC being the offerer, but this is not detailed in the current text.
 
   ... When the SRS is ready to receive recorded streams, the
   SRS sends a new SDP offer and sets the media streams with a=recvonly
   attribute.
 
a=recvonly could also be in the initial offer.
 
9. Persistent Recording
 
The draft talks about using the direction attribute a=inactive in earlier section.
That results in RTCP still being sent for a persistent recording session, when there is nothing to record.
Is there anything to say about RTCP usage in this situation in more detail?

10.1. Procedures at the record-aware user agent

   A recording-aware UA SHOULD indicate that it can accept reporting of
   recording indication provided by the SRC.
At the risk of being ingnorant of previous discussions, why is this just a SHOULD?
Who would receive this indication? The B2BUA or the peer SIP UA? Both?
 
   A new option tag "record-
   aware" is introduced to indicate such awareness.  The recording-aware
   UA SHOULD include the "record-aware" option tag in the Supported
   header when initiating or establishing a CS.
Again why just SHOULD?
Who would receive this indication?
 
10.1.1. Recording preference

   A recording-aware UA involved in a CS MAY request the CS to be
   recorded or not recorded.  This indication of recording preference
   can be sent at session establishment time or during the session.
 
Does the UA request the recording? Or is it the user?
Who receives this request? Who sends the "indication of recording preference"?
I'd like to see some explicitly spelled out procedures here.
 
   A new SDP attribute "recordpref" is introduced.  The SDP attribute
   appears at the media level or session level and can appear in an SDP
   offer or answer.  The recording indication applies to the specified
   media stream only.
What does the session level attribute mean? Probably, all media streams are peferred to be recorded.
What are the rules when there are session and media level attributes?
Does a media level attribute override the session level?
Is a preference in an offer achknowledged in the answer?
If the attribute was omitted in the offer what does it mean when it is included in the answer?
 
      recordpref-attr = "a=recordpref:" pref
 
      pref = "on" / "off" / "pause" / "nopreference"
 
Do you want to make pref extensible by adding "/ token"? Just in case ...
 
   on Request for recording if it has not already been started.  If the
      recording is currently paused, request to resume recording.
   off  Request for no recording.  If recording has already been
      started, then this preference indicates a request to stop
      recording.
...
 
The section title and ABNF syntax say "preference", but the explanatory text talk about "requests".
What is it? A preference, an indication, a request, a ocmmand?
If it is a request, is there a response?
I haven't followed the SIPREC discussions closely, so apologies if this was already discussed, but
would SDP be the right protocol for sending requests/commands?
I would expect pushback from the SDP directorate.
If this is just an indication of a preference, I also think it is somewhat questionable, if SDP is the right place or if it would be better at the SIP level. As the latter would complicate things, I will sit on the fence.
 
10.2. Procedures at the SRC
 
   When a UA has indicated that it is recording-aware through the
   "record-aware" option tag, the SRC MUST provide recording indications
   in a new SDP attribute described in the following section.
I stumbled a little bit over this since the SRC could be located at the UA or at a B2BUA.
Who would get the recording indication? UA A, UA B, both?
 
   In the
   absence of the "record-aware" option tag, meaning that the UA is not
   recording-aware, an SRC MUST provide recording indications, where SRC
   is required to do so based on policies, through other means such as
   playing a tone inband.

10.2.1. Recording indication
   ...
   The 'record' SDP attribute appears at the media level or session
   level in either SDP offer or answer.
 
Similar  as above, what are the rules when there are session and media level attributes?
 
      attribute /= record-attr
      ; attribute defined in RFC 4566
      record-attr = "record:" indication
      indication = "on" / "off" / "paused"
 
Do you want to make indication extensible by adding "/ token"? Just in case ...
 
10.2.2. Recording preference

   When the SRC receives the a=recordpref SDP in an SDP offer or answer,
   the SRC chooses to honor such request to record the request based on
                                                          ^ session?
   local policy on the SRC.
Same issue with preference vs. request as above.
   When the SRC honors the request, the SRC
   MUST also update the recording indication to reflect the current
   state of the recording (on/off/paused).
                    ^ by sending to a=record:XX attribute?

Editorial nits
 
The documents talks regularly about SIP headers (e.g. Require header) when a SIP header field is meant. Although one could accuse me of nit-picking I would prefer the term header field (e.g. Require header field)
since a SIP message has just a single header, which consists of multiple header fields.
 
Reference to RFC3311 (UPDATE) is missing

4.2. Delivering recording metadata
...
This request allows both SRC and SRS to
   restart the states with a new metadata snapshot so that further
   metadata incremental updates will be based on the latest metadata
   snapshot.
 
Do you mean "synchronize the states" instead of "restart the states"?
 
7.1.1.2.  Transcoding Translator

   When acting as a transcoding translator, an SRC MAY perform
   transcoding (e.g., from one codec to another), and this may result in
   a different rate of packets between what the SRC receives and what
   the sends.
      ^ missing word SRC?

7.1.2. SRC acting as an RTP Mixer
...
   Optionally an SRC acting as a mixer can perform transcoding, and can
   even cope with different codings received from different UAs.
                               ^ Do you mean codecs?

7.7.  Keepalive

   It is anticipated that media streams in SIPREC may exist in inactive
   states for extended periods of times for an of a number of valid
   reasons.                                   ^ does not parse, missing word?

7.8.1. Full Intra Request
 
   A Full Intra Request (FIR) Command, when received by the designate
   media sender, ...                                             ^ designated

7.8.2.  Picture Loss Indicator
 
...
 
   FIR SHOULD be used only in situations where not
   sending a decoder refresh point would render the video usable for the
   users.                                                 ^ unusable?
 
7.8.3.1.  Renegotiation of SDP bandwidth attribute
...
   Therefore for SIPREC, implementations are
   RECOMMENDED to use TMMBR for temporary changes, and renegotiation of
   bandwidth via SDP offer/answer of more permanent changes.
                                  ^ suggest to replace with "of changes with a longer duration."
 
8.2.  Procedures at the SRS
...
  Certain errors, such syntax errors or ...
                      ^ as

10.2. Procedures at the SRC

   In the
   absence of the "record-aware" option tag, meaning that the UA is not
   recording-aware, an SRC MUST provide recording indications, where SRC
   is required to do so based on policies, through other means such as
   playing a tone inband.
 
Prefer to say
In the absence of the "record-aware" option tag, meaning that the UA is not
recording-aware, an SRC MUST provide recording indications through other
means such as playing a tone inband, if the SRC is required to do so e.g. based on policies.

 Figure 8: Recording indication example
 
 Missing (2) for the 200OK,  (6) ACK should read (7) ACK
Would the
(5) re-INVITE (SDP + a=record:off)
also include an a=inactive direction attribute?

 

mit freundlichen Grüßen/Kind Regards

Dr.-Ing. Thomas Stach
Siemens Enterprise Communications Austria
RPDC P SE
Dietrichgasse 27
A-1030 Vienna
Tel: +43 57008 4377
Fax: +43 570085 4377
mailto:[email-masked]

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 1 Jun 2012 13:58:15 -0700

Hi Thomas, thanks for the review. Please see inline.

I will defer to Charles on the RTP handling sections.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stach, Thomas
> Sent: June-01-12 7:54 AM
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-protocol-04.txt
> 
> Leon,
> 
> The architecture document draft-ietf-siprec-architecture-04 describes
> scenarios where either the SRC or the SRS can establish the recording session.
> However, section 4 of the protocol document has the focus on the case where
> the SRC initiates the RS and doesn't describe the other option.  Other section
> have similar issues as detailed further down.

[Henry] Paragraph 1 of section 5.2 mentions that an SRS can establish a recording session by sending a new INVITE to SRC. We don't specify what calls SRS wants to record in this recording session and how this is done; it's beyond the scope of this draft.

> This would only be the case if the SRC is located in a SIP UA. A B2BUA would

[Henry] Whether a SIP UA registers or not it's entirely up to the UA, I don't think we need to qualify which type of UA it is. This statement here requires that whenever a SRC UA needs to register it must include the feature tag.

> Section 5.1 does not specify behaviour of the SRC when it receives the initial

[Henry] The SRC recognizes a recording session with the presence of the siprec option. How the SRC chooses to accept the request is up to the SRC, and the SRC must also include the +sip.src feature tag in the contact. Can you clarify what other behaviour you are looking for that needs to be specified?

> How should the SRC behave when the SRS establishes a "permanent" recording
> session, how when the recording session is established mid-call.
> Is there a difference?

[Henry] We always qualify a SIP session as a recording session with the use of the siprec option. It must be included in the initial INVITE and you cannot change that in the mid-call.

> I saw some text afterwards in section 10, but that is far away. Maybe a hint

[Henry] Note that the recording session is different than the user call (communication session) and the recording session purely deals with transporting recorded media. The recording indication needs to show up in the communication session so that is why it has a separate section 10.
> Section 5.2 does not specify behaviour of the SRS when it receives the initial

[Henry] I have a similar question for the SRC behaviour above. The SRS identifies a recording session with the option tag and it's up to SRS to accept the INVITE or not.

> E.g. is it a failure case when the '+sip.srs' feature tag or the "siprec"
> option tag is missing in the INVITE from the SRC?  Other parts of the draft
> talk about SIPREC-unaware UAs, so it's probably not an error?

[Henry] When the siprec option or +sip.src is missing then it means that the SIP session is not qualified as a recording session. The behaviour for handling a regular SIP session is up to the SRS.

> support SDP with multiple m-lines?

[Henry] This is already covered in RFC3264 section 5. It would be confusing to add normative statements on what is already normative.

> Consider the the SRC sending an SDP answer with the direction attribute set to

[Henry] Okay I will add a statement on this.

> The text only talks about SDP answers. If the SRS initiates the recording
> session it would set the direction attribute to a=recvonly in the SDP _offer_
> of the INVITE. Of course, the SRS could send an offerless INVITE, which would
> again result in the SRC being the offerer, but this is not detailed in the
> current text.

[Henry] Actually the SRS should not be adding media streams since the SRS is purely receiving media. Even when the SRS is initiating the recording session, the INVITE should not have an offer and let the SRC decide what the recorded streams are.

> Is there anything to say about RTCP usage in this situation in more detail?

[Henry] The intention of a persistent recording is that the media stream is still in sendonly state and not in inactive. In any case, RTCP is still sent periodically, and I don't think we need to have special handling for RTCP. 

> Who would receive this indication? The B2BUA or the peer SIP UA? Both?

[Henry] In this section we are talking about the participants in the call being recorded (the communication session). If the participant which can be any kind of user agent supports the extensions described in this section, then the UA should indicate that it supports them. We don't mandate that a UA must support these extensions since we need to interoperate with regular 3261 SIP UA to be recorded.

> Who would receive this indication?

[Henry] Only an SRC would care about the record-aware indication since the SRC would be performing the recording. 
> Does the UA request the recording? Or is it the user?

[Henry] This can be a human user or just the UA requesting the call to be recorded; the indication is sent by the UA.

> I'd like to see some explicitly spelled out procedures here.

[Henry] Perhaps I can provide an example here to illustrate how this works, but the procedures of what a recording-aware UA are already provided in section 10.1.

> What does the session level attribute mean? Probably, all media streams are

[Henry] the session level mean that all media streams have the attribute applied. You can also set this at the media stream level to indicate which media stream you wish to be (or not to be recorded). For example, you only wish your audio to be recorded but not your video stream, then you can set the attribute as a=recordpref:on in the audio media stream and a=recordpref:off in the video media stream.

> Is a preference in an offer achknowledged in the answer?

[Henry] An SRC is not required to honor such preference due to its own policies, so we have not modeled this attribute with any negotiation and this merely indicate what the user preference is for this media stream or session. The user will only know whether it is recording or not through the recording indication, and the SRC is required to provide the indication via the a=record attribute. 

> If the attribute was omitted in the offer what does it mean when it is

[Henry] We have discussion about this before and the conclusion is that the omission of this attribute is equivalent to a=recordpref:nopreference.

> Do you want to make pref extensible by adding "/ token"? Just in case ...

[Henry] 
> If it is a request, is there a response?

[Henry] "request" is indeed a bad choice of wording here. As I mentioned above, this is not a request/response parameter and I will correct the wording here. 

Revised text:

   on    Indicate that the UA wishes to be recorded or resume recording if the recording is paused.
   off   Indicate that the UA wishes not to be recorded or stop the recording if a recording is already in progress.
   pause Indicate that the UA wishes the recording to be paused if the recording is in progress.

> If this is just an indication of a preference, I also think it is somewhat
> questionable, if SDP is the right place or if it would be better at the SIP
> level. As the latter would complicate things, I will sit on the fence.

[Henry] We had discussions on this before and the reason we use SDP attribute is that we want media stream level indication and preference.

> Who would get the recording indication? UA A, UA B, both?

[Henry] All participants in the communication session must receive the record-aware indication. 

> Similar  as above, what are the rules when there are session and media level

[Henry] The SRC can choose to use session level attribute if all the media streams share the same indication, otherwise the SRC needs to use the media level attributes.

> Do you want to make indication extensible by adding "/ token"? Just in case

[Henry]  Do we really need a general token? I don't see another recording state that the SRC can be in.

>                     ^ by sending to a=record:XX attribute?

[Henry] The wording should be preference rather than request. Thanks for catching that and I will reword as follows:

   When the SRC receives the a=recordpref SDP in an SDP offer or answer,
   the SRC chooses to honor such the recording preference based on
   local policy on the SRC.  Whatever actions the SRC chooses, the SRC MUST also 
   update the recording indication to reflect the current state of the recording (on/off/paused).

> 
> 
> Editorial nits
> 
> The documents talks regularly about SIP headers (e.g. Require header) when a
> SIP header field is meant. Although one could accuse me of nit-picking I would
> prefer the term header field (e.g. Require header field)

[Henry] Okay I will fix them.
> Do you mean "synchronize the states" instead of "restart the states"?

[Henry] Okay I can change the word here.
 
> means such as playing a tone inband, if the SRC is required to do so e.g.

[Henry] Okay that sounds better.

>  Missing (2) for the 200OK,  (6) ACK should read (7) ACK

[Henry] Oh right, thanks.

> also include an a=inactive direction attribute?

[Henry] Stopping the recording does not mean the media stream in the communication is paused though.
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 4 Jun 2012 13:36:02 +0000

Henry,

thanks for the response. 

more inline

> -----Ursprüngliche Nachricht-----
> Von: Henry Lum [mailto:[email-masked]] 
> Gesendet: Freitag, 01. Juni 2012 22:58
> An: Stach, Thomas; [email-masked]
> Betreff: RE: [siprec] Comments on draft-ietf-siprec-protocol-04.txt
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Stach, Thomas
> > Sent: June-01-12 7:54 AM
> > To: [email-masked]
> [Henry] Paragraph 1 of section 5.2 mentions that an SRS can 
> establish a recording session by sending a new INVITE to SRC.

Section 5.2 is fine in that respect, my point was that this is not mentioned in the overview section 4.

> We don't specify what calls SRS wants to record in this 
> recording session and how this is done; it's beyond the scope 
> of this draft.
> 
> > 
> > 
> > This would only be the case if the SRC is located in a SIP 
> UA. A B2BUA would
> > not register.
> 
> [Henry] Whether a SIP UA registers or not it's entirely up to 
> the UA, I don't think we need to qualify which type of UA it 
> is. This statement here requires that whenever a SRC UA needs 
> to register it must include the feature tag.
OK
> 
> > Section 5.1 does not specify behaviour of the SRC when it 
> receives the initial
> > INVITE from the SRS.
> 
> [Henry] The SRC recognizes a recording session with the 
> presence of the siprec option. How the SRC chooses to accept 
> the request is up to the SRC, and the SRC must also include 
> the +sip.src feature tag in the contact. Can you clarify what 
> other behaviour you are looking for that needs to be specified?

My point is that section 5.1 describes just the sender's side, i.e. how the SRC builds the INVITE and includes the option/feature tag.
I'm missing the counterpart, i.e. what the receiver of such an INVITE (SRS) should do with it. 
Such text could include e.g : 
"On receipt of an INVITE the SRS SHALL check for presence of an 'siprec' option tag and a '+sip.src' feature tag. 
If present the SRS should start recording of the media streams based on the SDP in the body of the INVITE. 
Detailed SDP handling is described in section 6. 
If metadata is present, the SRS SHALL act as specified in section 8. ..."

> [Henry] We always qualify a SIP session as a recording 
> session with the use of the siprec option. It must be 
> included in the initial INVITE and you cannot change that in 
> the mid-call.

I should have asked more clearly. I meant a CS is already going on. At some time during that CS a "new" adhoc recording session is started.
Is there a difference compared to the case where a "permanent" recording session is already in place? 
This is probably not the case with respect to the option/feature tags and this could be stated in the text.

However (as an example) I could imagine different values of the direction attributes "inactive" vs. "sendonly" in the initial INVITE of the recording session. Now, section 6.1 just mentions usage of "sendonly". A creative developer might now think that only "sendonly" is allowed in the initial INVITE and rejects if the SDP includes "inactive". But that would make perfect sense as initial value of "permanent" recording session and should clearly be allowed.
I would like options like this being explicitly stated in the text in order to avoid interoperability problems in future implementations.

> > I saw some text afterwards in section 10, but that is far 
> away. Maybe a hint
> > would help?
> 
> [Henry] Note that the recording session is different than the 
> user call (communication session) and the recording session 
> purely deals with transporting recorded media. The recording 
> indication needs to show up in the communication session so 
> that is why it has a separate section 10.

Yes, I detected that when I later read section 10, but I stumbled over the issue.
As section 4 already gives an overview, you might also want to mention this indication already there.

This make me aware of something that I currently miss and which can probably also be enhanced in section 4.
Currently, there is a lot of detailed information spread over different parts. 
I think this fine, but I miss some glue that puts these parts together.

Section 4 could probably mention that section 5 describes the INVITE and its usage of option/feature tags,
Section 6 describes SDP, Section 7 describes RTP issues, Section 8 describes metadata, section 10 describes ...

> > Section 5.2 does not specify behaviour of the SRS when it 
> receives the initial
> > INVITE from the SRC.
> 
> [Henry] I have a similar question for the SRC behaviour 
> above. The SRS identifies a recording session with the option 
> tag and it's up to SRS to accept the INVITE or not.

Yes, my issue is also similar like for 5.1. 5.2 describes just the sender's side, I miss what the receiver of the INVITE should do.

> [Henry] When the siprec option or +sip.src is missing then it 
> means that the SIP session is not qualified as a recording 
> session. The behaviour for handling a regular SIP session is 
> up to the SRS.

I think that should be stated in the text.

> 
> > 
> > 6. SDP Handling
> > 
> > Although it sounds trivial, should the draft mention that 
> SRC and SRS MUST
> > support SDP with multiple m-lines?
> 
> [Henry] This is already covered in RFC3264 section 5. It 
> would be confusing to add normative statements on what is 
> already normative.

OK, agreed.
The reason behind my comments is that we met a lot of implementations that showed a variety of unexpected behavior when they received multiple m-line. Maybe we will be better of with recorders.

> > Consider the the SRC sending an SDP answer with the 
> direction attribute set to
> > a=sendonly.
> 
> [Henry] Actually the SRS should not be adding media streams 
> since the SRS is purely receiving media. Even when the SRS is 
> initiating the recording session, the INVITE should not have 
> an offer and let the SRC decide what the recorded streams are.

Ok, that works for me, but this is not yet stated in the text.
If everybody agrees with that view you should add something like: 
"When the SRS starts a recording session it MUST initial the INVITE without an SDP offer."
... and a similar statment on what the SRC does when it receives that INVITE.

> > The draft talks about using the direction attribute 
> a=inactive in earlier
> > section.
> > That results in RTCP still being sent for a persistent 
> recording session, when
> > there is nothing to record.
> [Henry] The intention of a persistent recording is that the 
> media stream is still in sendonly state and not in inactive. 

As per my response above I believe that the persistent recording would use "inactive" (at least in case when there is nothing to record yet at the time of establishment)

> In any case, RTCP is still sent periodically, and I don't 
> think we need to have special handling for RTCP. 

> > At the risk of being ingnorant of previous discussions, why 
> is this just a
> > SHOULD?
> [Henry] In this section we are talking about the participants 
> in the call being recorded (the communication session). If 
> the participant which can be any kind of user agent supports 
> the extensions described in this section, then the UA should 
> indicate that it supports them. We don't mandate that a UA 
> must support these extensions since we need to interoperate 
> with regular 3261 SIP UA to be recorded.

Understood, but a regular 3261 UA would just ignore the option tag in the Supported header field.
Though not a big deal, I'm still wondering about the SHOULD. Is it to make life easier for automatons?

> [Henry] Only an SRC would care about the record-aware 
> indication since the SRC would be performing the recording. 

OK, but you don't specify into which message the record-aware UA should put the option-tag.
Should it be in the INVITE request, 200OK? 
Does it need to be repeated in re-INVITE and its 200OK, UPDATE request and its 200OK?

> [Henry] This can be a human user or just the UA requesting 
> the call to be recorded; the indication is sent by the UA.

Ok, please state this in the text.
... and similar to above, MUST the indication be repeated during O/A cycle during the call?
Omission during a later O/A cycle could either mean the preference did not change or that fallback to the the default occurs.
I think that needs to be specified.

> [Henry] Perhaps I can provide an example here to illustrate 
> how this works, but the procedures of what a recording-aware 
> UA are already provided in section 10.1.
> 
> > 
> > What does the session level attribute mean? Probably, all 
> media streams are
> > peferred to be recorded.
> 
> [Henry] the session level mean that all media streams have 
> the attribute applied. You can also set this at the media 
> stream level to indicate which media stream you wish to be 
> (or not to be recorded). For example, you only wish your 
> audio to be recorded but not your video stream, then you can 
> set the attribute as a=recordpref:on in the audio media 
> stream and a=recordpref:off in the video media stream.

OK, understood. But SDP attributes that can be used at session level and media level need to have a rule that specifies what it means when the attributes are used simultaneously at session and media-level. 
Usually the media-level attribute overides the session-level value, such that 

a=recordpref:on 
m=audio 12240 RTP/AVP 0
m=audio 12242 RTP/AVP 0
m=video 12244 RTP/AVPF 98
a=recordpref:off

means the same as your example (all audio is preferred to be recorded, but video is not). 

> [Henry] An SRC is not required to honor such preference due 
> to its own policies, so we have not modeled this attribute 
> with any negotiation and this merely indicate what the user 
> preference is for this media stream or session. The user will 
> only know whether it is recording or not through the 
> recording indication, and the SRC is required to provide the 
> indication via the a=record attribute. 

Maybe you could include this in the text.

> 
> > If the attribute was omitted in the offer what does it mean 
> when it is
> > included in the answer?
> 
> [Henry] We have discussion about this before and the 
> conclusion is that the omission of this attribute is 
> equivalent to a=recordpref:nopreference.
> 
> > 
> > The section title and ABNF syntax say "preference", but the 
> explanatory text
> > talk about "requests".
> [Henry] "request" is indeed a bad choice of wording here. As 
> I mentioned above, this is not a request/response parameter 
> and I will correct the wording here. 

Good, that was my major concern with the SDP attributes.

>    off   Indicate that the UA wishes not to be recorded or 
> stop the recording if a recording is already in progress.
> > I haven't followed the SIPREC discussions closely, so 
> apologies if this was
> > already discussed, but
> [Henry] We had discussions on this before and the reason we 
> use SDP attribute is that we want media stream level 
> indication and preference.

Works for me

> > I stumbled a little bit over this since the SRC could be 
> located at the UA or
> > at a B2BUA.

Please, state this in the text.

> > Similar  as above, what are the rules when there are 
> session and media level
> > attributes?
> 
> [Henry] The SRC can choose to use session level attribute if 
> all the media streams share the same indication, otherwise 
> the SRC needs to use the media level attributes.

This would be a differnt rule than what is usually done. 
Whatever you want to specify needs to be explictly stated.

> > Do you want to make indication extensible by adding "/ 
> token"? Just in case
> > ...
> 
> [Henry]  Do we really need a general token? I don't see 
> another recording state that the SRC can be in.

I was just asking and don't have apreference. Sometimes things come up later that nobody could imagine at earlier times.

> [Henry] The wording should be preference rather than request. 
> Thanks for catching that and I will reword as follows:
> 

OK, could you just explictly mention the "a=record" attribute?

Regards
Thomas

> > since a SIP message has just a single header, which 
> consists of multiple
> > header fields.
> > 
> >    users.                                                 ^ 
> unusable?
> >                                   ^ suggest to replace with 
> "of changes with a
> > longer duration."
> > 
> > means such as playing a tone inband, if the SRC is required 
> to do so e.g.
> > based on policies.
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 4 Jun 2012 10:27:11 -0700

Yes, thank you Thomas for your thorough review.
Please see additional comments inline.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henry Lum
> Sent: Friday, June 01, 2012 1:58 PM
> To: Stach, Thomas; [email-masked]
> Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-04.txt
> 
> [Henry] Paragraph 1 of section 5.2 mentions that an SRS can establish a
> recording session by sending a new INVITE to SRC. We don't specify what
> calls SRS wants to record in this recording session and how this is
> done; it's beyond the scope of this draft.
> 
> >
> >
> > This would only be the case if the SRC is located in a SIP UA. A
> B2BUA would
> > not register.
> 
> [Henry] Whether a SIP UA registers or not it's entirely up to the UA, I
> don't think we need to qualify which type of UA it is. This statement
> here requires that whenever a SRC UA needs to register it must include
> the feature tag.
> 
> > Section 5.1 does not specify behaviour of the SRC when it receives
> the initial
> > INVITE from the SRS.
> 
> [Henry] The SRC recognizes a recording session with the presence of the
> siprec option. How the SRC chooses to accept the request is up to the
> SRC, and the SRC must also include the +sip.src feature tag in the
> contact. Can you clarify what other behaviour you are looking for that
> needs to be specified?
> 
> [Henry] We always qualify a SIP session as a recording session with the
> use of the siprec option. It must be included in the initial INVITE and
> you cannot change that in the mid-call.
> 
> > I saw some text afterwards in section 10, but that is far away. Maybe
> a hint
> > would help?
> 
> [Henry] Note that the recording session is different than the user call
> (communication session) and the recording session purely deals with
> transporting recorded media. The recording indication needs to show up
> in the communication session so that is why it has a separate section
> 10.
> >
> > Section 5.2 does not specify behaviour of the SRS when it receives
> the initial
> > INVITE from the SRC.
> 
> [Henry] I have a similar question for the SRC behaviour above. The SRS
> identifies a recording session with the option tag and it's up to SRS
> to accept the INVITE or not.
> 
> [Henry] When the siprec option or +sip.src is missing then it means
> that the SIP session is not qualified as a recording session. The
> behaviour for handling a regular SIP session is up to the SRS.
> 
> >
> > 6. SDP Handling
> >
> > Although it sounds trivial, should the draft mention that SRC and SRS
> MUST
> [Henry] This is already covered in RFC3264 section 5. It would be
> confusing to add normative statements on what is already normative.
> 
> >
> > Consider the the SRC sending an SDP answer with the direction
> attribute set to
> > a=sendonly.
> 
> [Henry] Actually the SRS should not be adding media streams since the
> SRS is purely receiving media. Even when the SRS is initiating the
> recording session, the INVITE should not have an offer and let the SRC
> decide what the recorded streams are.
> 
> >
> > The draft talks about using the direction attribute a=inactive in
> earlier
> > section.
> > That results in RTCP still being sent for a persistent recording
> session, when
> [Henry] The intention of a persistent recording is that the media
> stream is still in sendonly state and not in inactive. In any case,
> RTCP is still sent periodically, and I don't think we need to have
> special handling for RTCP.
> 
> >
> > At the risk of being ingnorant of previous discussions, why is this
> just a
> > SHOULD?
> [Henry] In this section we are talking about the participants in the
> call being recorded (the communication session). If the participant
> which can be any kind of user agent supports the extensions described
> in this section, then the UA should indicate that it supports them. We
> don't mandate that a UA must support these extensions since we need to
> interoperate with regular 3261 SIP UA to be recorded.

Actually, I agree with Thomas's comment here. I believe the reasoning Henry provides is accurate; however, we decided to specifically call out and define the roll of a recording-aware UA vs. a legacy UA that may not be recording-aware. For a recording-aware UA, I think MUST is appropriate.
 
> [Henry] Only an SRC would care about the record-aware indication since
> the SRC would be performing the recording.

[cue]
I think other network elements, such as recording-aware MCU, may be interested in this capability of a UA as well.
For example, if a recording-aware MCU knows that there is an SRC in a conference, and that SRC is currently recording, the MCU may want to propagate the recording indication from the SRC to the conference participants out of band using the mechanism defined in this draft.

> [Henry] This can be a human user or just the UA requesting the call to
> be recorded; the indication is sent by the UA.
> 
> [Henry] Perhaps I can provide an example here to illustrate how this
> works, but the procedures of what a recording-aware UA are already
> provided in section 10.1.
> 
> >
> > What does the session level attribute mean? Probably, all media
> streams are
> > peferred to be recorded.
> 
> [Henry] the session level mean that all media streams have the
> attribute applied. You can also set this at the media stream level to
> indicate which media stream you wish to be (or not to be recorded). For
> example, you only wish your audio to be recorded but not your video
> stream, then you can set the attribute as a=recordpref:on in the audio
> media stream and a=recordpref:off in the video media stream.
> 
> [Henry] An SRC is not required to honor such preference due to its own
> policies, so we have not modeled this attribute with any negotiation
> and this merely indicate what the user preference is for this media
> stream or session. The user will only know whether it is recording or
> not through the recording indication, and the SRC is required to
> provide the indication via the a=record attribute.
> 
> > If the attribute was omitted in the offer what does it mean when it
> is
> > included in the answer?
> 
> [Henry] We have discussion about this before and the conclusion is that
> the omission of this attribute is equivalent to
> a=recordpref:nopreference.
> 
> >
> [Henry] "request" is indeed a bad choice of wording here. As I
> mentioned above, this is not a request/response parameter and I will
> correct the wording here.
> 
> Revised text:
> 
>    off   Indicate that the UA wishes not to be recorded or stop the
> recording if a recording is already in progress.
> > I haven't followed the SIPREC discussions closely, so apologies if
> this was
> > already discussed, but
> [Henry] We had discussions on this before and the reason we use SDP
> attribute is that we want media stream level indication and preference.
> 
> >
> > I stumbled a little bit over this since the SRC could be located at
> the UA or
> > at a B2BUA.
> > Similar  as above, what are the rules when there are session and
> media level
> > attributes?
> 
> [Henry] The SRC can choose to use session level attribute if all the
> media streams share the same indication, otherwise the SRC needs to use
> the media level attributes.
> 
> >
> >       attribute /= record-attr
> > Do you want to make indication extensible by adding "/ token"? Just
> in case
> > ...
> 
> [Henry] The wording should be preference rather than request. Thanks
> for catching that and I will reword as follows:
> 
> > since a SIP message has just a single header, which consists of
> multiple
> > header fields.
> >

[cue] Yes, thanks.

> >    even cope with different codings received from different UAs.

[cue] Different codecs is one example of different codings, but it is not the only one. For example, the clock rate or some codec parameter(s) may be different.

> >    reasons.                                   ^ does not parse,

[cue] an -> any. Thanks for catching it.

> >    sending a decoder refresh point would render the video usable for

[cue] Yes, thanks.

> >                                   ^ suggest to replace with "of
> changes with a
> > longer duration."

[cue] of -> for

Cheers,
Charles

> > means such as playing a tone inband, if the SRC is required to do so
> e.g.
> > based on policies.
>