[asterisk-dev] Is Asterisk's handling of SDP version number on a re-INVITE correct?

[Kirill 'Big K' Katsnelson]

A device sends an in-dialog re-INVITE with a different SDP session user 
name, identifier and version. The re-invite is rejected by Asterisk 
because its version number is not increasing between existing and the 
old session.

My question is whether that behavior is correct or not. process_sdp_o() 
in chan_sip.c ignores the username and session id, but compares the 
version. Now, RFC2327 on page 8, where the o= field is described, says:

>    <session id> is a numeric string
>    such that the tuple of <username>, <session id>, <network type>,
>    <address type> and <address> form a globally unique identifier for
>    the session.

and (pp. 8-9)

>    <version> is a version number for this announcement.  It is needed
>    for proxy announcements to detect which of several announcements for
>    the same session is the most recent.  Again its usage is up to the
>    creating tool, so long as <version> is increased when a modification
>    is made to the session data.

The key here seems the words "the same session," which I understand as 
the session identified by the same <session id>. If my understanding is 
correct, then Asterisk's checking for version increment but ignoring the 
session id is a bug.

Example of re-invite that is ignored

Old SDP:
v=0
o=- 1274264417 1274264417 IN IP4 10.20.0.72
s=Paraxip Media Session
c=IN IP4 10.20.0.72
t=0 0
m=audio 9102 RTP/AVP 0 8
a=recvonly
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

New SDP:

v=0
o=root 687223968 687223968 IN IP4 10.20.0.126
s=Asterisk PBX local/1.6.2/04 at 35
c=IN IP4 10.20.0.126
t=0 0
m=audio 17728 RTP/AVP 0 101
a=fmtp:101 0-16
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=silenceSupp:off - - - -

results in

DEBUG[10536] chan_sip.c: Call 
M2Y2ZGViNjhmZDAyZWIzYjZmOGRjMWFmNTA3MjQ2OTc. responded to our reinvite 
without changing SDP version; ignoring SDP.

(do not get mislead by the wording here: this is not a response to "our" 
reinvite, it is their one, but processed in the same function).

  -kkm