Sumit Garg wrote:
Another approach to avoid unnecessarily long bodies: (this would be more
on lines of offer-answer)
INVITE- these are events A desires to receive.
1st reliable response (provisional/200OK) from B:
- this is the subset of events (from the offer from A) which can
be provided by B.
- this is the set of events B desires from A.
ACK/PRACK:
- this is the subset of events (from the offer from B) which can
be provided by A.
That would work. I find it slightly more attractive than the
sendrecv/sendonly/recvonly/inactive approach, though both are roughly
equivalent in power.
Wouldn't the best approach be to supersede the INFO RFC with one which
takes care of issues, i.e. with these additional headers.
We can't get people to change the old implementations, but at least the
for new usages if the additional work required is a smaller delta (from
base INFO, as compared to having to implement SUBSCRIBE/NOTIFY), they
might be more amenable to use the new EVENT based INFO mechanism.
Frankly, I think what we are discussing would be better applied using
NOTIFY in the INVITE dialog. We would then be devising a new means to
negotiate event packages that will share the invite dialog, but using
the same NOTIFY messages to carry the data, not INFO.
Paul
-Sumit
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man."
-- George Bernard Shaw
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 9:24 AM
To: Christer Holmberg
Cc: sip; Francois Audet; Brian Stucker; Dean Willis
Subject: Re: [Sip] INFO
Christer Holmberg wrote:
Hi,
The "bundled subscriptions" need to be negotiated in both
directions.
That means something like:
INVITE must contain:
- these are the events I am willing to send
- these are the events I desire to receive
response must contain:
- these are the events I will send (subset from invite)
- these are the events you should send (subset from invite)
Maybe we could re-use the SDP direction attributes (sendrecv,
sendonly,
recvonly) for this?
Are you serious? Or have you been smoking something? :-)
Sometimes I think that would help in these discussions :)
Certainly you can use the SDP direction attributes if you want to
establish media sessions for this event signaling.
But AFAIK the point here is to negotiate the use of signaling in the
sip session itself.
I guess I should have been more clear. I didn't mean that we start
using SDP for this, but that we could use something SIMILAR to the
direction attributes - but in the form of some SIP header parameters.
Oh - thats not quite so crazy.
Yes, I suppose something like that could be done. But given how much
confusion that seems to have caused with SDP, I would certainly think
twice before using it again.
Note that this will need to be more than a one-time negotiation. Its
possible that the agreement will need to be renegotiated in mid-call.
(This comes up at least in 3pcc scenarios, where a device in the middle
is performing a transfer without the knowledge of the other side.)
Paul
_______________________________________________
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
