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. On Mon, May 25, 2015 at 6:31 PM, Paul Kyzivat <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 >> >> >> What do you think? >> >> Best Regards, >> Xin >> _______________________________________________ >> 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 > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
