Hi,
I think we should try to allow renegotiation of the supported features. There
may be certain packages I want to send and/or receive during certain parts of a
session.
Regards,
Christer
________________________________
Lähettäjä: [EMAIL PROTECTED] puolesta: Paul Kyzivat
Lähetetty: la 2.8.2008 16:31
Vastaanottaja: Eric Burger
Kopio: SIP IETF
Aihe: Re: [Sip] INFO Issue: Info-Send Procedures
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
_______________________________________________
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
