Subject: [siprec] SDP Comments to draft-ietf-siprec-protocol-00

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 13 Sep 2011 10:54:59 +0200

Hi,

here are some comments to the SDP in draft-ietf-siprec-protocol-00

- Section 5.3. I found a few "must" and "should" in lowercase. I wonder 
whether these should be written normatively (uppercase) or is there a 
reason for not doing it, in which case, I would recommend to go around 
the lowercase terms to avoid confusion.

- Section 5.3, third paragraph: the text is written around the format 
(a=sendonly), but I will instead put the focus on the semantics. For 
example, I would write:

    Since the SRC does not expect to receive media from the SRS, the SRC 
will typically set each media stream of the SDP offer to only send media, 
by qualifying them with the a=sendonly attribute. Conversely, as the SRS 
only receives RTP streams from SRCs, the SDP answer will normally set 
each media stream to only receive media, by setting them with the 
a=recvonly attribute, according to the procedures of RFC 3264 [RFC3264].

- Section 5.3, fourth paragraph. As a matter of personal taste, I prefer 
that actions are attributed to either the SRC or the SRS, but not to the 
"SDP" (which is not an entity). For example, the sentence "the SDP must 
provide a label..." should be restated in terms of the "the SRC MUST 
include a label *attribute* (a=label) in each media stream of the SDP"...

Also, in this fourth paragraph in Section 5.3, avoid the future tense, 
unless you really want to describe an action that will take a later time: 
"... will be used ..."

- Figure 4 in Section 5.3: the "o=" line is incorrect, due to sess-id and 
sess-version are set to 0. Also, the selected IP address is not being 
according to RFC 5737. Use this one instead:

    o=SRS 2890844526 2890844526 IN IP4 198.51.100.1

- Figure 4 in Section 5.3: the "s=" line is incorrect according to RFC 
3264. Use an white space or dash character instead:

    s=-

- Figure 4 in Section 5.3: the "c=" line is incorrect due to the IP 
address not being according to RFC 5737. Use this one instead (should be 
the same IP address as in the o= line).

    c=IN IP4  198.51.100.1

- Figure 4 in Section 5.3: all the m= lines are incorrect. All the lines 
should indicate an even port number for RTP, implicitly indicating that 
the consecutive port number is used for RTCP. Additionally, two lines 
referring to the H264 codec indicate that the stream is of type "audio", 
which is incorrect. Use the following "m=" lines (in order).

   m=audio 12240 RTP/AVP 0 4 8
   m=video 22456 RTP/AVP 98
   m=audio 12242 RTP/AVP 0 4 8
   m=video 22458 RTP/AVP 98

- Figure 4 in Section 5.3. Use a correct a=fmtp line, for example:

       a=fmtp:98 profile-level-id=42A01E;
                 sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

- Section 5.3, 5th and 6th paragraphs: The text should be stated in terms 
of SDP offer/answer (we are in Section 5.3, which is "SDP handling"), and 
a reference to RFC 3264 should be added. Therefore:

    To remove a recorded media stream from the recording session, the SRC
    sends a new SDP offer where the port of the media stream to be
    removed is set to zero, according to the procedures in RFC 3264
    [RFC3264].

    To add a new media stream to the recording session, the SRC sends a
    new SDP offer adding a new media stream description in an m= line,
    according to the procedures in RFC 3264 [RFC3264].

- Section 5.3, 7th paragraph should also be drafted in terms of SDP O/A.

- Figure 6 in Section 5.4, use this SDP instead:

      v=0
      o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
      s=-
      c=IN IP4 198.51.100.1
      t=0 0
      m=audio 12240 RTP/AVP 0 4 8
      a=sendonly
      a=label:1

- Section 6.2.1. The syntax is not correct. You should start by extending 
the "attribute" production in SDP, for example:

       attribute          /= record-attr
       ; attribute defined in RFC 4566
       record-attr        = "record:" indication
       indication         = "on" / "off" / "paused"

- Section 6.2.2. For discussion... Do you really need two attributes, 
"record" and "recordpref"? I believe both could be integrated into a 
single attribute. For example, you could have the a=record attribute with 
the two values, one for the current status, and one of the current 
preference.

- Section 7.1. Although this is not related to SDP, in this paragraph you 
need to specify the registry where you want to register the new option 
tags. I believe it is the Session Initiation Protocol Parameters registry.

- Section 7.5.1 and  7.5.2. The registration lacks contact name, email 
address, and telephone number, according to the requirements in RFC 4566.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 14 Sep 2011 12:44:38 -0700

Hi Miguel,

Thank you for all your comments. Please see snippet regarding a
clarification on one of your comments.

> the two values, one for the current status, and one of the current

Are you recommending:

record-attr        = "record:" indication pref [not sure if this is
legit syntax]
indication         = "started" / "stopped" / "paused" / "noindication"
pref                = "start" / "stop" / "pause" / "nopreference"

or 

record-attr        = "record:" value
value              = "started" / "stopped" / "paused"/ "start" / "stop"
/ "pause"

Thanks,
Charles

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 15 Sep 2011 08:34:07 +0200

Hi Charles:

Both options work for me. Perhaps the first one, being explicit, is more 
future proof.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 15 Sep 2011 08:53:07 -0700

Hi Miguel,

Thanks for the thorough review - indeed there were a LOT of mistakes in
the SDP example! 

Henry 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Miguel A. Garcia
> Sent: September-13-11 4:55 AM
> To: [email-masked]; Henry Lum; [email-masked];
> Hutton, Andrew; [email-masked]; mmusic
> Subject: [siprec] SDP Comments to draft-ietf-siprec-protocol-00
> 
> Hi,
> 
[Henry] John had similar comments as well that we should not repeat
normative statements in other specifications. I will reword the
sentences properly to avoid the confusion.

> include a label *attribute* (a=label) in each media stream of the
[Henry] I agree this is better wording, I'll correct this.

>                  sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
[Henry] Thanks! The correct SDP example should look like:

v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
s=-
c=IN IP4 198.51.100.1
t=0 0
m=audio 12240 RTP/AVP 0 4 8
a=sendonly
a=label:1 
m=video 22456 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98
profile-level-id=42A01E;sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
a=sendonly
a=label:2
m=audio 12242 RTP/AVP 0 4 8
a=sendonly
a=label:3
m=audio 22458 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98
profile-level-id=42A01E;sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
a=sendonly
a=label:4

>     according to the procedures in RFC 3264 [RFC3264].

[Henry] Thanks for the correction.

>       m=audio 12240 RTP/AVP 0 4 8
[Henry] Okay I will fix this.

>        indication         = "on" / "off" / "paused"
[Henry] Okay I will fix this.

> the two values, one for the current status, and one of the current
[Henry] I will respond on a separate thread.

> address, and telephone number, according to the requirements in RFC
[Henry] Thanks I will fix the registrations.

> 
> /Miguel
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> 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.

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 15 Sep 2011 09:34:23 -0700

There are 2 reasons for using different SDP attributes: The first reason
is to distinguish who should insert the attribute. An SRC would include
the recording indication while a recording-aware UA would insert the
recording preference. The other reason is that the attributes are
intended to used as separate declarations for a recording-aware UA
(preference) and for an SRC (indication). Merging the two as a single
attribute makes like work like a negotiation attribute instead of a
declaration. 

Regards,
Henry 

> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: September-15-11 2:34 AM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]; Henry Lum; [email-masked];
> Subject: Re: [siprec] SDP Comments to draft-ietf-siprec-protocol-00
> 
> Hi Charles:
> 
> >> single attribute. For example, you could have the a=record
attribute
> > with

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 16 Sep 2011 08:33:07 +0200

Henry,

Everything is OK.

I also agree with John that you need to put a bit of effort in avoiding 
writing normative text where the same text has been already written in a 
previous RFC. A trick to do this is to express the idea in present tense 
without the 2119 wording, and add a normative reference to the RFC where 
the requirement is written. For example:

  .... and the endpoint sends an SDP answer, according to the procedures 
of RFC 3264 [RFC3264].

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 16 Sep 2011 08:34:54 +0200

Henry,

I am OK with your explanation. Please include the motivation that you 
wrote below somewhere in the draft. It will help a lot to understand it.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain