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

["Miguel A. Garcia" <[e-mail]>]

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:
> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Bert Greevenbosch
>> Sent: Monday, May 09, 2011 7:03 PM
>> To: [e-mail]
>> 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.
>>
>>
>>
>> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain