Brett Tate wrote:
I'm afraid we're over-engineering this whole thing, and we'll
end up with something which is even more complicated than what
we are trying to clarify :)
I agree. I think that the complication is less about the RFC ambiguity and more about vendors attempting to find ways to interop when some devices don't support (or disabled support of) the following: 1) interactions with forking proxies, 2) rfc3262, or 3) rfc3311.
You may be right about this.
Devices which don't support the above 3 items usually need work-a-rounds which are not compliant to SIP's offer/answer rules. Thus fixing potential RFC ambiguity does little to fix the real problem beyond highlighting that most/all of the work-a-rounds are non compliant or not desirable.
I'm not sure what point you are making here.
In cases where implementations are doing the wrong thing because they
don't understand what the right thing is, better specification of
expected behavior will reduce the cases where work arounds are required.
Of course it won't fix things immediately - only as implementations are
corrected. It will certainly help in *disputes* about the correct behavior.
The cases where the existing text calls for things to be ignored, rather
than checked, can actually facilitate interop where one end isn't quite
right. But only for certain types of incorrectness.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
