Dale has covered this. For the original poster, Stefan: there is a lot of written information on this subject that you don't seem to be familiar with. The most obvious are RFCs 3261 and 3264. For a more complete treatment, see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt
Once you understand those I think your questions will be answered. Paul [EMAIL PROTECTED] wrote: > From: Stefan Sayer <[EMAIL PROTECTED]> > > The offerer may change the stream, but the answerer? > > Uh, yes. I answered a different question than was asked. > > In regard to how the answer may be different from the offer, the rules > are in section 6.1 of RFC 3264. In many cases, the answerer may add > media formats. E.g., > > For streams marked as sendrecv in the answer, the "m=" line MUST > contain at least one codec the answerer is willing to both send and > receive, from amongst those listed in the offer. The stream MAY > indicate additional media formats, not listed in the corresponding > stream in the offer, that the answerer is willing to send or > receive (of course, it will not be able to send them at this time, > since it was not listed in the offer). > > In any case, if one is trying to debug SDP, one should have read RFC > 3264 carefully. > > From: Stefan Sayer <[EMAIL PROTECTED]> > > And then, if you change any part of the SDP, you must update > (increase) the session version, which in both SDPs of the two 200s > is 1294106766. > > Interestingly, though the offers are identical, the answers are > different (and so should have different versions). > > Dale > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors