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 wrote:
> I should have noticed Dale's reply before w
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 writes:
Our product actually compare the newly received SDP with previous one and
if they are not byte-to-byte identical and the S
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
Ren Xin 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
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 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 no
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-o
