draft-ietf-sip-info-events-00: package negotiation

General issues with the negotiation mechanism:

What happens if the initial INVITE by a UAC includes only Send-Info or 
Recv-Info? Does that indicate a "half-legacy" device??? Or does it delay 
negotiation for one but not the other? Or does the presence of one mean 
the absence of the other is equivalent to an empty one?

As I think about it, I don't think its really necessary to treat the 
absence of these headers as meaning "legacy". Treating the absence of 
these headers as equivalent to their presence without any packages is 
sufficient to get the proper legacy behavior. The tricky part is 
figuring out out when their absence *doesn't* mean that, which is 
significant only in the non-legacy case. In particular, when they aren't 
present in INVITE it means deferral of the "offer" to the UAS. And 
possibly absence in an UPDATE means "don't renegotiate"???

I'm confused by the three way negotiation of info packages in 
INVITE/2xx/ACK. Its allowed when the Send-Info/Recv-Info are in the 
INVITE, but not when they are deferred to the INVITE response, or when 
they are conveyed in UPDATE and its response. If the three way handshake 
is needed to seal the deal, then those other options should be off the 
table. But the "deferred offer" of these is really needed, so it can't 
be off the table. Or is this just an extra benefit that can be exploited 
when possible?

Also, I don't see any provision for additional round(s) of negotiation 
before 2xx via PRACK and UPDATE, though there is provision for 
additional "half-negotiations" via provisional responses and the final 
response. Given the parallels with O/A, I'd prefer to see them more 
aligned in this regard, though I can be talked out of that with a good 
argument.

I'd also like to take advantage of the lessons that have been learned 
with O/A and nail down more of the semantics now. One issue that leaps 
to mind in that regard is what happens if we start to negotiate info 
packages in a reINVITE and then the reINVITE fails?

IMO what is needed is a state model for this stuff, added to the state 
for an invite-dialog-usage. This state should determine which packages 
may be sent, and which should be received without error. We should be 
very clear about exactly which events cause changes to this state.

Even then there are race conditions that need to be clarified. For 
instance: Suppose, as a result of an INVITE/1xx exchange between Alice 
and Bob, that packages P & Q are allowed to be sent from Alice to Bob. 
Alice then sends an INFO with package Q, and at the same time Bob sends 
a 2xx that only allows the receipt of package P. Then Bob receives the 
INFO with package Q. What should happen?

Another issue is that if the Send-Info/Recv-Info contents change in 
subsequent 1xx responses to the same INVITE, the UAS has no guarantee 
that they are received. So any reduction in what can be received cannot 
be counted upon until the 2xx/ACK.

	Thanks,
	Paul
_______________________________________________
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