Re: [Sip] Inadequate Requirements for draft-ietf-sip-199-00

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi,

>> I DO agree, however, that there is currently no general way 
>> to associate media with dialogs. In cases where you have 
>> security associations for the media it may be possible, 
>> however (I am no expert on that, though).
>> 
>> But, the how-to-associate-media-with-dialogs has also been 
>> discussed every now and then, and there seems to be interest 
>> among people (both in IETF and other SDOs) to start working 
>> on a general solution. But, that work would also be outside 
>> the scope of 199 (I guess it wouldn't necessarily even be 
>> done in SIP/SIPPING - at least not without involvement of 
>> other groups).

>This is what worries me: we are defining micro-procedures that
>don't really address the whole problem with the vague hope that
>one day it will actually be useful. MAYBE it will help with 
>media stream choosing. MAYBE it will help with HERFP.
>
>I find it unproductive to standardized protocol before we
>know if it actually helps in fixing actual problems.

There are already problems which 199 CAN solve, without any other work.

And, regarding associating media with dialogs, I belive it today can be done at least when SRTP is used - without any further work. I haven't looked into other media security mechanisms.

>So don't get me wrong: I am not against us working on 199. I
>just don't think we should RFC it before we have progressed
>along the rest of the procedures that would actually make it
>useful in the real world. If this is done through different drafts,
>be it. But there is definitively inter-dependency between them.

The purpose of 199 is to provide a mechanism indicating that an early dialog has been terminated. Period. There are some details we need to sort out, but at the end of the day there aren't that many different directions we can go as far as the basic purpose of 199 is concerned.

IF we at some point want to use 199 for HERPF, we can easily say that entities which support it shall insert a sipfrag in the 199 response. That is why we decided not to say anything about it, so that we don't forbid it for future use.

IF we at some point get a general mechanism to associate dialogs with headers, and that mechanism uses e.g. some new SIP headers, nothing prevents us from using those in 199.

Etc etc etc.

There IS a need for "basic 199 functionality" today. Based on previous work, solving the HERPF problem etc can take quite a while, and I see no reason to delay 199 just because of that. That will again cause delays and show inefficiency, when we try to save the world in one single go. Instead I think we shall try not to restrict things for no good reason (something we should also keep in mind for other work we do), in case it may be needed later.   

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip