A test needs to be applied to this - one that often causes problems.
Namely, does with work with 3pcc? In particular, if there is a B2BUA in
the middle, and it is carrying out a transfer on one side, while
preserving an existing dialog on the other side, will things work right?
This requires the ability to renegotiate the supported features of the
dialog.
Paul
Eric Burger wrote:
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
_______________________________________________
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
