And there we go... not even 20 minutes.
So, you are right for INFO as we have historically known it.
This new gorgon that Dean is proposing is not like that INFO.
It's something that's carrying state based on (effectively) an
implicit subscription (or something very much like a subscription,
but without any of the control infrastructure) in the INVITE.
If something goes _wrong_ in that subscription, you don't have a
clean separate usage you can tear down and leave the INVITE usage up
(I expect pushback here, and I anticipate that when you try to _add_
that clarity, you'll end up most, if not all, of the way to just
using SUBSCRIBE).
Maybe to avoid the confusion you just pointed to, we could call this
beast NOTINFO?
RjS
On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote:
Why does the call need to go away, if INFO is rejected? Isn't INFO not
supposed to affect call state(s)?
- Sanjay
-----Original Message-----
From: Robert Sparks [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 25, 2007 4:43 PM
To: Adam Roach
Cc: sip List; Dean Willis
Subject: Re: [Sip] INFO: A recap,sense of consensus and a
proposal for direction.
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).
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.
RjS
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
