Anders Kristensen wrote:
I don't think it's just about releasing resources like memory. In fact,
the draft does mention that it can help a UAC determine when to start
rendering a different (early) audio stream. That seems pretty useful.
I don't see how that would work. As it is there is really no general way
to distinguish which early signaling session a given incoming media
stream corresponds to. In any case, one would expect that media would
not be sent by an early session that has been terminated. When you stop
receiving media from one source you should start rendering something else.
Thanks,
Paul
That said, I'm sure we're all in favor of simplicity and reuse of
mechanism.
Thanks,
Anders
Francois Audet wrote:
All I am saying is that this solution seems to be to try to address a
problem that is too narrow to justify the complexity and extra protocol
in this draft, and that the problem is not described properly in the
draft.
If it helped with something else (like HEFP), then perhaps it would be
useful.
I have heard in Dublin from Robert Sparks that "something else" (with no
details on what he has in mind) would be better to solve HERFP.
This is getting me extremely worried that we are jumping ahead too fast
on this 199 proposal, without a clear direction of where HERFP will
take us.
To answer Keith's question: the whole introduction in Christer's draft
(except the very last paragraph about undefined "saved resources")
describes what the HERFP problem is, i.e., that when forking occurs,
final responses are not passed to the UAC and it causes problems. That
is what HERFP is.
I see it as very disingeneous that we are pretending that this has
nothing to do with HERFP when it very is clearly related to it.
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED] Sent:
Tuesday, August 05, 2008 10:49
To: Audet, Francois (SC100:3055); DRAGE, Keith (Keith); [email protected]
Subject: VS: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
Hi Francois,
Nobody has said we will not work on solving the HERPF problem -
potentially using 199. We only agreed not to do it as part of 199.
You are welcome to draft a proposal, and at least I would be very
interested in working on that.
Reading the use-cases, I think you will see that it's not only about
"freeing up some RAM". It can be used for network/bandwidth/media
type-of resources.
It MAY also be part of a future solution for the
forking-and-early-media solution, in cases where you can assoicate
media with dialogs etc.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
