On 5/26/15 4:50 AM, Ren Xin wrote:
Our product actually compare the newly received SDP with previous one
and if they are not byte-to-byte identical and the SDP version does not
increase by 1, we invalidate the stream.
Customer is complaining about this. They think these two streams are
identical.
Now we can not reach an agreement on if this is a bug.
I think this depends on your objectives.
If your goal is to be "SDP Police" and verify that others adhere to the
letter of the specs, then you are probably doing the right thing.
If your goal is to maximize interoperability, then not so much. In that
case you are better to follow the Postel maxim: “Be liberal in what you
accept, and conservative in what you send.”
You just need to be sensible in how you are liberal. (IMO it isn't good
to be liberal by choosing one of two equally plausible interpretations
of an ambiguous point.)
IMO it would probably be a bad thing if you simply trusted that the
version being equal means the SDP is unchanged. In that case, if
somebody screwed up and made big changes to the SDP and failed to change
the version you could get into big interop problems.
But if, when you find the SDPs are not byte-by-byte identical, you act
as if the version was updated even if it was not, then ISTM the only
"harm" that can arise is that you might succeed in interoperating.
But it is your choice.
Thanks,
Paul
On Mon, May 25, 2015 at 6:31 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
On 5/25/15 6:45 AM, Ren Xin wrote:
Hey,
According to RFC 3264 par.7
"If the version in the origin
line does not increment, the SDP MUST be identical to the
SDP with
that version number. The answerer MUST be prepared to
receive an
offer that contains SDP with a version that has not changed;
this is
effectively a no-op. However, the answerer MUST generate a
valid
answer (which MAY be the same as the previous SDP from the
answerer,
or MAY be different), according to the procedures defined in
Section 6."
Do you think following two SDP offers are identical?
This was always less than clear to me too.
The obvious definition would be byte-by-byte identical. But is there
any point in deciding they are not identical?
ISTM an operational definition makes more sense:
A recipient that sees that the version is unchanged may assume that
the this is functionally the same as the last one received and not
further check or process it. By that definition, these are identical
enough.
Personally, I have always thought that it is dangerous to trust
this. I would prefer to actually do my own comparison before
deciding to optimize this way. Then if they aren't byte-by-byte
identical then just go ahead and process the new one as if the
version was different.
Thanks,
Paul
############# SDP 1
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
*a=sendrecv*
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
############# SDP 2
v=0
o=MxSIP 1751268753124820177 614423801163363146 IN IP4 10.249.130.34
s=-
c=IN IP4 10.249.130.34
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
I checked marriam-webster, and it seems that definition
1(selfsame) makes
them not identical, while definition 2(essentially same) makes them
identical.
www.merriam-webster.com/dictionary/identical
<http://www.merriam-webster.com/dictionary/identical>
What do you think?
Best Regards,
Xin
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto: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
<mailto: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
