The text currently says that if one endpoint indicates it does not
support an Info-Package, that endpoint is to ignore subsequent Info-
Send headers sent by the other endpoint that continues to indicate
support for that Info-Package.
On the one hand, this continual resending of an Info-Send sends an
ambiguous message to the recipient. Namely, the recipient does not
know the sender received their "I do not support that package" response.
On the other hand, this continual resending of an Info-Send offer does
no harm, in that unless the recipient indicates support of that
package, the sender will not send it. Moreover, this continual
resending would enable the recipient to subsequently accept the
sending of the package at a later time. I could theoretically imagine
a situation where an endpoint wants to hold-off the other endpoint
from sending INFOs related to a given package, until it releases the
other end by eventually listing that package in the Info-Recv.
So, this is more of a discussion issue than a yes/no issue. The
topics to discuss are do we want to allow later negotiation or re-
negotiation of Info Package support (currently this is not allowed by
the draft past dialog establishment)? If not, do we want to require
senders to stop offering Info Packages the recipient has already
indicated it does not support the package?
I do not want to do the loosey-goosey, "MAY send", in that we know
that some implementations will renegotiate in error (if we decide
there is no renegotiation) while others will barf on subsequent Info-
Send headers (if we decide there is no renegotiation).
Related to this is we currently explicitly disallow renegotiation at
re-INVITE and UPDATE time. Do we really want this restriction? OK
with me.
What about REFER? Here one clearly would want renegotiation, we the
UAS will connect to another endpoint that may have different
capabilities.
_______________________________________________
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
