Hi, >>> complete treatment, see >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt >> where you write in 4.2.5. Subsequent Offers and Answers: >> >> o In the o-line, only the version number may change, and if it >> changes it must increment by one from the one previously sent as >> an offer or answer. If it doesn't change then the entire SDP body >> must be identical to what was previously sent as an offer or >> answer. > >This is the most often misimplemented part. It's usual to see UAs >which send e.g. SDP with session ID and version both identical and >showed a time from session start, either for the same SDP or >changed one; or in another broken mode. In practice, one shall >never rely on this (in 4.2.5) rule. I don't agree. Also the SDP spec says that the version shall be incremented if the SDP information changes, so if one doesn't do it I think it's a clear protocol error. There are use-cases where you are going to send an un-changed SDP, for example if you are using the session-timer mechanism, or if you are updating the local target, in which case the version is not incremented. It is very useful information for the receiver, because it knows it doesn't need to start processing the SDP, compare it with previous SDPs etc. Regards, Christer
-- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] _______________________________________________ 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
