Subject: [Sip] INFO Issue: Info-Send Procedures

From: Eric Burger <[email-masked]>
Date: Fri, 1 Aug 2008 16:00:59 -0400

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 02 Aug 2008 10:31:20 -0400

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:
> 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.
> 
> ambiguous message to the recipient.  Namely, the recipient does not know 
> the sender received their "I do not support that package" response.
> 
> 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).
> 
> 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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 2 Aug 2008 23:08:55 +0200

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-masked] 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

        Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 Aug 2008 10:01:17 +0100

Eric, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: 01 August 2008 21:01
> To: SIP IETF
> Subject: [Sip] INFO Issue: Info-Send Procedures
> 
<snip/>
> re-INVITE and UPDATE time.  Do we really want this restriction?  OK  

This would forbid B2BUAs that do third party call transfer, for example,
renegotiating to take into account the capabilities of the new party.
Whilst we may frown on 3rd party call transfer, the fact that REFER and
Replaces are effectively "MAY" (i.e., support for the RFCs is optional),
vendors are forced into continuing to support third party transfer.

John