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
