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 were many logical inferences made, across text from
several documents, to determine original intent. The chain of logic is
not always captured in 6337.
IMO it is unfortunate that 3261 made it mandatory to ignore subsequent
SDP in responses once the answer is received. While it may sometimes
help keep a session working even when the UAS misbehaves, it is equally
likely to simply result in a mess where the UAC and UAS disagree on the
state of the session. If the answerer changes the SDP in a meaningful
way (e.g., changing the media address) then things will not work unless
the UAC also violates 3261 and honors the change.
In your case is the *only* change in the SDP is to the version number?
What is the point in doing that?
Bottom line: IMO both UAC and UAS are non-conformant. The UAS is sending
an invalid repetition of the answer, and the UAC is invalidly paying
attention to it and objecting.
On 9/18/15 7:59 AM, Roger Wiklund wrote:
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 is uncertain regarding this (at leat last year)
https://lists.cs.columbia.edu/pipermail/sip-implementors/2014-July/029740.html
I didn't go back and review that whole discussion, but IIRC, it was
really more about subsequent O/As after the initial session
establishment. In that case it is *valid* to change the SDP, and the
question is whether a change to only the version number is acceptable.
It is a bit different than in this case.
Thanks,
Paul
On Fri, Sep 18, 2015 at 1:11 PM, Brett Tate <br...@broadsoft.com> wrote:
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 reliable response for the same INVITE
transaction."
The only thing left to interpretation IMO is if version increment with no
SDP change is considered an update.
Thoughts on this?
The SDP is not an updated answer. The SDP is not a new offer. It is an SDP
that RFC 3261 says must be ignored.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
