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

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

I don't have strong feelings one way or another about this, but I think the resources being freed may be more than just some memory. E.g. I think there can be DSPs assigned to process media for each early dialog.
But this is starting to get very complex, and I am being swayed in opposition to it. In particular, if the proxy must track the o/a state of the early dialog in order to decide if it can send a 199, then that starts to seem unreasonable to me. 

	Thanks,
	Paul

Francois Audet wrote:

So let's clarify what we are trying to solve then.
If we remove HERFP, it seems the main "requirement" is for a UA to free up RAM for maintaining state information when early dialogs terminate. 
And we are doing so by adding more protocol that will add more
states to keep track of.

I am extremely sceptical that this actually simplify anything.
Especially since it order to be backwards compatible, a
UA can not assume that a 199 will be sent to free up the "resources".
I find the incentive for anybody to implement this set of procedures
to be completely unconvincing. It seems to me that it add complexity
not remove any.
I was fooled into thinking at the previous meeting that we would then build on top of this proposal to actually solve a real problem 
(like HERFP) as opposed to theoretical "resource optimization" problem.
If it looks like HERPF will not use this, then I fail to see any incentive to implement 199. 



-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com] Sent: Tuesday, August 05, 2008 07:45 
To: Christer Holmberg; Audet, Francois (SC100:3055); sip at ietf.org
Subject: RE: [Sip] Inadequate Requirements for draft-ietf-sip-199-00

(As WG cochair)
The agreement in the SIPPING group where this was discussed was that we were not going to solve the HERPF problem. I think you will find a number of mails in the SIPPING archive confirming this.
It would be useful to identify and correct any text that you believe implies that the HERPF problem is to be solved.
Outside the HERPF problem I have no objection to clarifying the requirements and use cases. Please note that supposedly the SIPPING WG has already regarded these as complete. I would like to see clarification rather than feature creep. 

Regards

Keith


-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
Behalf Of 
Christer Holmberg
Sent: Monday, August 04, 2008 9:29 PM
To: Francois Audet; sip at ietf.org
Subject: Re: [Sip] Inadequate Requirements for draft-ietf-sip-199-00


Hi Francois,
As was agreed during the "requirements phase", we are not going to solve the HERPF problem as part of this task. Nobody 
objected to that.
It was agreed that the scope is to only be able to indicate
that the 
early dialog has been terminated.
I have tried to explain different kind of "resources" for which the mechanism could be useful.
If you want to start a separate work item in order to solve
(with or
without using 199) other problems you are free to propose 
such work :)

Regards,

Christer



-----Alkuperäinen viesti-----
Lähettäjä: Francois Audet [mailto:audet at nortel.com]
Lähetetty: ma 4.8.2008 22:17
Vastaanottaja: sip at ietf.org
Kopio: Christer Holmberg
Aihe: Inadequate Requirements for draft-ietf-sip-199-00
I believe that the Requirents section for this draft is completely inadequate. The only material in section 3 is the following:
REQ 1: It must be possible to indicate to the UAC that an early dialog has been 
	terminated before a final response is sent.
This is almost as good as "REQ: It must be possible to do whatever this draft says".
This draft must really explain what it is trying to achieve. The Introduction has a bunch of text that describes what looks and smells exactly like the HERFP problem.
In Dublin, it was stated that this draft does not attempt
to solve the
HERFP problem. If that is the case, then I am completely baffled by what exactly is it trying to solve. Yes, there is a little bit of wording about the need to "release resources" (whatever that means), but I find it a little
bit hard to 
swallow that we need new protocol for that.

_______________________________________________
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 


_______________________________________________
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


_______________________________________________
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