Subject: [MMUSIC] Question on unrecognized "a=" attributes in SDP offer/answer

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 7 Jun 2007 15:34:47 -0700

>From reading RFC3264, it is not clear how an answerer should prepare SDP
answer when "a=" attribute lines in SDP offer are unrecognized.

For example, how should SDP answer look when attrib1 and attrib2 are
"sendonly" attributes and the answerer does not recognize them.

SDP offer with "sendonly" attribute and both media streams are
"sendrecv"
========
m=audio
a=attrib1:value1

m=video
a= attrib2:value2

I think the best current practice is SDP answer (1). Is there any RFC
which clearly describes this behavior?
Answerer simply removes the unrecognized attributes while preparing the
SDP answer.

SDP answer (1)
=========
m=audio
m=video

Another possible answer if answerer simply ignores the unrecognized
lines and does not remove them from SDP answer
SDP answer (2)
=========
m=audio
a=attrib1:value1

m=video
a= attrib2:value2

I think that SDP answer (2) would result in issues. It might indicate
that answerer is signaling attrib1/2 in answerer->offerer direction.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 10:01:34 +0200

Hi,

Since the receiver will discard attributes it doesn't understand I don't think it should put anything in the answer. Because, then the one who sent the offer may actually think that the other party DOES understand the attribute.

Regards,

Christer 

> -----Original Message-----
> From: Desineni, Harikishan [mailto:[email-masked]] 
> Sent: 8. kesäkuuta 2007 1:35
> To: [email-masked]
> Subject: [MMUSIC] Question on unrecognized "a=" attributes in 
> SDPoffer/answer
> 
> For example, how should SDP answer look when attrib1 and 
> attrib2 are "sendonly" attributes and the answerer does not 
> recognize them.
> 
> SDP offer with "sendonly" attribute and both media streams 
> are "sendrecv"
> ========
> m=audio
> a=attrib1:value1
> 
> m=video
> a= attrib2:value2
> 
> 
> I think the best current practice is SDP answer (1). Is there 
> any RFC which clearly describes this behavior?
> Answerer simply removes the unrecognized attributes while 
> preparing the SDP answer.
> 
> SDP answer (1)
> =========
> m=audio
> m=video
> 
> Another possible answer if answerer simply ignores the 
> unrecognized lines and does not remove them from SDP answer 
> SDP answer (2) ========= m=audio
> a=attrib1:value1
> 
> m=video
> a= attrib2:value2
> 
> 
> I think that SDP answer (2) would result in issues. It might 
> indicate that answerer is signaling attrib1/2 in 
> answerer->offerer direction.
>

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 8 Jun 2007 10:35:35 -0700

Yes, such behavior makes sense and I believe most implementations match this. Is it explicitly recommended in any RFC? (RFC3264 does not have any text which recommends such a behavior)

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Friday, June 08, 2007 1:02 AM
> To: Desineni, Harikishan; [email-masked]
> Subject: RE: [MMUSIC] Question on unrecognized "a=" attributes in
> SDPoffer/answer
> 
> 
> Hi,
> 
> Since the receiver will discard attributes it doesn't understand I don't
> think it should put anything in the answer. Because, then the one who sent
> the offer may actually think that the other party DOES understand the
> attribute.
> 
> Regards,
> 
> Christer
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 23:24:42 +0200

Hi, 

>Yes, such behavior makes sense and I believe most 
>implementations match this. Is it explicitly recommended in 
>any RFC? (RFC3264 does not have any text which recommends 
>such a behavior)

I think it is said - somewhere - that unsupported attributes shall be discarded, so personally I would say it's quite clear that they will then not be part of the answer.

Regards,

Christer

> > Since the receiver will discard attributes it doesn't understand I 
> > don't think it should put anything in the answer. Because, then the 
> > one who sent the offer may actually think that the other party DOES 
> > understand the attribute.
> > 
> > Regards,
> > 
> > Christer
> > 
> > > I think the best current practice is SDP answer (1). Is there any 
> > > RFC which clearly describes this behavior?
> preparing 
> > > the SDP answer.
> unrecognized 
> > > lines and does not remove them from SDP answer SDP answer (2) 
> > > ========= m=audio
> > > a=attrib1:value1
> > >
> > > m=video
> > > a= attrib2:value2
> > >
> > >