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
