Thanks Dale and Paul! I am not sure why my product is doing this, it is legacy behavior. I will suggest the "Be conservative in what you produce; be liberal in what you accept."
Best Regards, Xin On Tue, May 26, 2015 at 4:19 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > I should have noticed Dale's reply before writing my own that says the > same thing. > > Thanks, > Paul > > On 5/26/15 7:07 AM, Dale R. Worley wrote: > >> Ren Xin <nathanren...@gmail.com> writes: >> >>> 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 would argue that "identical" requires that they be byte-by-byte the >> same. On the other hand, why is your product attempting to enforce this >> rule? I would expect that the benefit of the rule "If the version in >> the origin line does not increment, the SDP MUST be identical to the SDP >> with that version number." is that if the version number is the same as >> before, the device can skip parsing the SDP and leave its media >> configuration the same as before. If the device is taking the trouble >> to do a complete inspection of the SDP anyway and actually comparing it >> to the previous SDP, why is it being particular about the version >> number? >> >> "Be conservative in what you produce; be liberal in what you accept." >> >> Dale >> >> > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
