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

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

Hi,
 
>Ok, now we are getting somewhere.
>
>Can you describe that in the document.

I thought I had done that in the use-case section, but for sure I can have another look at the use-case text and see whether I can clarify/extend the text.

>Also, in the REQ section, let's write requirements that are specific
>and are able to address the problems you listed below.

Well, I think the use-cases justifies the existing requirement. Do you want to have specific requirement for all the use-cases?

Regards,

Christer


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com] 
> Sent: Wednesday, August 06, 2008 11:38
> To: Audet, Francois (SC100:3055); Paul Kyzivat; Anders Kristensen
> Cc: sip at ietf.org; DRAGE, Keith (Keith)
> Subject: VS: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
> 
> 
> Hi,
>  
> >>There are already problems which 199 CAN solve, without any other 
> >>work.
> >
> >And those are?
> >
> >They should be clearly described. All I hear is examples of things 
> >where
> >199 is not sufficient (e.g., Media choosing, HERFP). 
> 
> I have tried to describe examples not related to media choosing.
> 
> One example is related to in-band procedures (e.g. ICE, 
> in-band security negotiations). At least in the mobile world 
> those can consume radio- and battery resources, so it is good 
> to be informed about terminated dialogs as soon as possible, 
> without having to detect it using re-transmission failures etc.
> 
> Another example in the mobile world is related to codecs and 
> DSP resources. If you have negotiated codec X only for one 
> early dialog, and that dialog is terminated, you know that 
> you can free the codec X resources (you can do that without 
> having to be able to associate media with dialogs) and e.g .. 
> allow reservation of other codecs needed for other dialogs. 
> Especially when we move into the world of multimedia, using 
> video etc, this kind of functionality becomes important. 
> 
> Another example in the mobile world is radio resources. In 
> case of forking and multiple stream there may not be possible 
> to allow early media on all dialogs, so some dialogs may e.g. 
> be set to "inactive". It is then very useful to know when a 
> dialog is terminated, so that media can be allowed on other 
> dialogs. How those inactive decissions are made is based on 
> local policy etc, but 199 provides a tool which is useful for 
> taking those decissions.
> 
> Due to the cases above, and others, terminals may restrict 
> the number of accepted SIP dialogs, so by knowing when one 
> dialog has been terminated it can accept another dialog.
> 
> These are not theoretical issues, but problems that exist 
> today. Maybe not in your PC with unlimited memory, connected 
> to fixed access with unlimited bandwidth, but in some other places :)
> 
> >If SRTP actually solves the problem for media choosing, then let's 
> >state it in the document.
> 
> Sure, I can do that.
> 
> 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