I just noticed this thread. So I'm jumping in where it seems to make sense.
Note that 3261 and friends are *not* very clear about this. RFC6337
tried to clarify the original intent, without being normative. (In
retrospect it would probably have been better to make a normative
update.) There we
> I agree with you but does not.
>
> Basically what they are saying is this: If SDP version number
> is incremented then this counts as an update/new offer period.
They can call it whatever they want. RFC 3261 says that the SDP must be
ignored (i.e. it is not an updated answer or new offer).
Ho
I agree with you but Nokia does not.
Basically what they are saying is this: If SDP version number is
incremented then this counts as an update/new offer period.
The problem is I can't find an RFC stating "You MUST NOT increment
version number if no change is made to the SDP"
Even Paul Kyzviat i
> The violation is:
>
> "When a reliable provisional response contains a session description, and
> is
> the first to do so, then that session description is the answer to the
> offer
> in the INVITE request. The answer cannot be updated, and a new offer
> cannot
> be sent in a subsequent reliabl
So it's clear that the UAC is violating the "MUST ignore".
I think this also makes it clear that the UAS is violating RFC.
RFC 6337 section 2.2.
Note that an offer/answer exchange initiated by an INVITE request
must follow exactly one of the Patterns 1, 2, 3, 4. When an initial
INVITE causes mu
