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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux