Robert Sparks wrote:
I'm pretty (actually extremely) unhappy with the idea, but I'll try not
to throw myself on the tracks in front of it.
Taking a tumble down the slope:
These info packages need to be separate from event packages - there may
be some
where you just derive an info package from an event package with a
trival rfc, but it will
_not_ be the case that it will make sense to throw any old event
package's payload into
an INFO like thing like this (think of the mess you'll get into with
anything with a partial
payload, and the bigger mess when you get into the infrastructure of the
framework, including winfo
and eventlists).
AFAIK nobody is suggesting that by some stroke of the pen all event
packages will magically become usable via this new mechanism. I agree
that makes no sense.
It would indeed require some action on each and every one to adapt it to
work with this new environment. For many it would make no sense to do
so, and would probably be impossible.
For those where it is possible and desirable I think it will be sort of
like making a new "skin" for a GUI - the moving parts are all the same,
though perhaps not all are visible through the new skin, but the look is
different.
And we'd need to specify quite concretely what happens when one of these
INFOs gets rejected.
In most cases, the call is going to have to go away, and I bet that's
going to make a lot of people unhappy.
I don't understand you here. I just checked dialogusage. As far as I can
tell, the behavior in there makes perfect sense here. Those errors on
INFO that tear down the usage or the dialog should do the same here.
If it does turn out that the error handling for this new approach are
inconsistent with error handling for INFO then we should define a new
method.
Paul
On Oct 25, 2007, at 3:06 PM, Adam Roach wrote:
On 10/24/07 2:18 PM, Dean Willis wrote:
I propose we develop a new RFC that extends RFC 3265 and obsoletes
RFC 2976.
This RFC will document use of event bodies in INFO messages exchanged
in dialog usages established by SIP INVITE transactions. This will
include definition of the "Send-Events" and "Recv-Events" header
fields, use of those header fields in INVITE transactions to provide
an offer/answer exchange, definition and use of a new option tag for
this extension, and the needed changes to the registry established by
RFC 3265.
I can support such a plan.
I will continue to argue that the event packages and info packages
should be independent of each other, but that's a minor detail. I
generally agree with the larger picture.
/a
_______________________________________________
Sip mailing list https://www1.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://www1.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://www1.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
