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

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



Ok, now we are getting somewhere.

Can you describe that in the document.

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

The ICE/DTLS-SRTP one is quite important.  

> -----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