Re: Is SDP in an unreliable response "the answer" ???

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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP