[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
Hi,
>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.
Correct. At least in many mobile terminals DSP resources are very limited.
>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.
As I said in another reply, I don't think we shall require the proxy to maintain o/a state.
The whole idea was to come up with a relatively simple mechanism.
...which then of course may be used to solve complex problems (like HERPF).
Regards,
Christer
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