Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 10 May 2011 02:03:09 +0000

Hi all,

I have a question for the SDP offer/answer model experts. It is related to the "3dFormat" attribute draft (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00.txt).

The issue has been touched before, but more in the context of frame packing. The current issue concerns how a legacy device will treat the for it unknown "3dFormat" attribute, especially in SIP negotiation.

I have found the following related info:

*         The SDP spec (RFC 4566) defines that unknown attributes MUST be ignored:
"If an attribute is received that is not understood, it MUST be ignored by the receiver." (section 5.13)

*         The SDP offer/answer spec (RFC 3264) gives no information about what to do with unknown attributes. The spec does not say whether the answerer can/will omit unknown attributes in its answer.

*         The SIP spec (RFC 3261) specifies a warning code 306 "Attribute not understood: One or more of the media attributes in the session description are not supported.". It does not mandate using this warning code, or specify whether it can be used with a SIP 200 OK response.

Ideal would be, when the answerer would omit SDP attributes it does not understand. In that case, the offerer can detect the client does not understand the "3dFormat" attribute and can update its offer.

Does any of you know more about how it works in praxis? Is there an established way on how current implementations deal with unknown SDP attributes when doing SIP negotiation?

Thanks a lot for your help!

Best regards,
Bert

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 May 2011 12:29:41 -0700

Hi Bert,

An end system that is producing an answer to an SDP offer that includes
SDP attributes it does not understand should ignore those attributes and
not include them within the answer. I find this to be done correctly by
most implementations.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bert Greevenbosch
> Sent: Monday, May 09, 2011 7:03 PM
> To: [email-masked]
> Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer
> 
> Hi all,
> 
> 
> 
> I have a question for the SDP offer/answer model experts. It is
related to the "3dFormat" attribute
> draft
(http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00.
txt).
> 
> 
> 
> The issue has been touched before, but more in the context of frame
packing. The current issue
> concerns how a legacy device will treat the for it unknown "3dFormat"
attribute, especially in SIP
> negotiation.
> "If an attribute is received that is not understood, it MUST be
ignored by the receiver." (section
> 5.13)
> 
> *         The SDP offer/answer spec (RFC 3264) gives no information
about what to do with unknown
> attributes. The spec does not say whether the answerer can/will omit
unknown attributes in its answer.
> 
> *         The SIP spec (RFC 3261) specifies a warning code 306
"Attribute not understood: One or more
> of the media attributes in the session description are not
supported.". It does not mandate using this
> warning code, or specify whether it can be used with a SIP 200 OK
response.
> 
> 
> 
> Ideal would be, when the answerer would omit SDP attributes it does
not understand. In that case, the
> offerer can detect the client does not understand the "3dFormat"
attribute and can update its offer.
> 
> 
> 
> Does any of you know more about how it works in praxis? Is there an
established way on how current
> implementations deal with unknown SDP attributes when doing SIP
negotiation?

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 11 May 2011 12:52:23 +0200

Hi Bert,

I agree with Charles, if an attribute present in the SDP offer is not 
understood, it will be simply ignored, and then the SDP answer will be 
produced.

Notice that the attribute not only needs to be understood by the 
recipient of the SDP offer, but also by possible intermediaries that 
inspect SDP, most notably SBCs. I guess most SBCs allow operators to 
decide on what to do with unknown attributes, in which case you have the 
possibility of the attribute to be filtered by an SBC.

/Miguel

On 10/05/2011 21:29, Charles Eckel (eckelcu) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 13 May 2011 00:48:56 +0000

Hi Charles,

Thanks, that was what I was hoping for.
I am preparing a new version of the draft that will reflect these issues.

Best regards,
Bert

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: 11 May 2011 03:30
To: Bert Greevenbosch; [email-masked]
Subject: RE: [MMUSIC] Question on unknown attributes in SDP offer/answer

Hi Bert,

Cheers,
Charles

response.
negotiation?

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 16 May 2011 02:38:15 +0000

Hi Miguel,

Thank you for pointing out this issue.

I have reviewed your comment in more detail, especially by reading RFC 5853.

Also from that RFC, I have understood that SBCs are not standardised, and can do many things, as long as end-to-end integrity protection is not enforced. As noted the RFC, it is very similar to a man-in-the-middle attack.

SBCs, in general, can cause trouble with SIP negotiation. For example, they can remove attributes, change codec and remove path/routing information. If they remove unknown attributes, they might also remove the 3D signalling from the SDP. (Until they know the attribute of course.)

The best thing would be for them not to remove unknown attributes. Some indeed will not do this, whereas others will. This is exactly the problem with their non-standardised nature, and it seems hard to cater for all of them.

What do you think?

Best regards,
Bert

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]] 
Sent: 11 May 2011 18:52
To: Charles Eckel (eckelcu)
Cc: Bert Greevenbosch; [email-masked]
Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer

Hi Bert,

/Miguel

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 16 May 2011 08:59:50 +0200

Hi Bert,

Your assessment on SBCs is correct. Perhaps the only thing we can do is 
to make sure that if the extension is not understood by an endpoint or 
SBC, or if the SBC is filtering the extension for administrative reasons, 
at least the session can be established with a regular video stream, I 
mean, without the 3D.

Notice that I am here assuming that you want to give priority to 
establishing the call without 3D over failing the call if 3D is not enabled.

BR,

      Miguel

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