Subject: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question

From: "Gardell, Steven" <[email-masked]>
Date: Tue, 21 Nov 2006 16:25:24 -0500

3264 allows the answer to include codecs that were not in the offer.
Is the offering side allowed to select an un-offered codec from the
answer list without a subsequent offer? The specification does not 
seem to expressly prohibit this, but it seems to violate the whole 
notion of "offer/answer" which is modeled on information being present 
in both the offer and the answer. It also seems at odds with a couple
of parenthetical remarks in this same document

Steven Gardell
GSX SIP Development 
[email-masked] 

t +1 978 614 8831 
f +1 978 614 8101 
250 Apollo Drive 
Chelmsford, MA 
01824 USA 
www.sonusnet.com <http://www.sonusnet.com/>
<file:///c:/sonuslogo.gif> 	
Deliver the Future First with Sonus Networks.
Disclaimer: Content provided is for information purposes only and is
subject to change without notice. Sonus has no obligation or commitment
to develop or deliver any future release, upgrade, feature, enhancement
or function described in this email or any attachment or presentation
except as specifically set forth in a written agreement. 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 21 Nov 2006 16:25:06 -0600

Short answer seems to be yes, but only with the understanding that the
codecs for the media stream must therefore by assymetric.

Only the set intersection between the SDP offer and answer can be used
by the answerer for generating media. The additional codecs in the
answer cannot be used by the answerer because the offerer didn't offer
them (and therefore there's no agreement or expectation that they'll be
rendered; ever). This is mentioned in section 6.1 of RFC-3264.

Section 7 does allow the offerer to send using any codec included in the
SDP answer for any accepted stream.

So, from a strict reading of RFC-3264, the following example can be
constructed:

- The offerer can send SDP with G.711 listed for an audio stream.
- The answerer can reply with SDP that includes G.711 and G.729 for the
same audio stream, accepting that media stream.
- The answerer can only send G.711 on that stream, but the offerer can
send G.711 or G.729 at its discretion.

I don't think this breaks the offer answer model. The answerer is in
essence offering another codec back to the answerer and the offerer is
answering it by using it. It's just not doing it through another formal
SDP exchange.

In practice, I doubt this is used much. I'd postulate that it may be a
bug in the spec except that it's explicitly mentioned in the text in
section 6. Doesn't seem to break anything.

Regards,
Brian

> -----Original Message-----
> From: Gardell, Steven [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 3:25 PM
> To: [email-masked]
> Subject: [Sipping] RFC 3264 (SDP Offer/Answer) Interpretation Question
> 
>  
> Is the offering side allowed to select an un-offered codec 
> from the answer list without a subsequent offer? The 
> specification does not seem to expressly prohibit this, but 
> it seems to violate the whole notion of "offer/answer" which 
> is modeled on information being present in both the offer and 
> the answer. It also seems at odds with a couple of 
> parenthetical remarks in this same document
> 
> 
> Steven Gardell
> GSX SIP Development
> [email-masked] 
> 
> t +1 978 614 8831
> f +1 978 614 8101
> 250 Apollo Drive
> Chelmsford, MA
> 01824 USA
> Disclaimer: Content provided is for information purposes only 
> and is subject to change without notice. Sonus has no 
> obligation or commitment to develop or deliver any future 
> release, upgrade, feature, enhancement or function described 
> in this email or any attachment or presentation except as 
> specifically set forth in a written agreement. 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>