Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing

From: Adam Roach <[email-masked]>
Date: Fri, 06 Nov 2009 06:43:55 +0900

[as an individual]

On 10/29/09 3:57 PM, Sanjay Sinha (sanjsinh) wrote:
> If the INFO transaction fails, then let the application decide whether
> it wants to continue with the dialog or not?
>    

That's functionally equivalent to asking "why don't we leave it to the 
application to decide whether a BYE terminates an invite usage?"

When an error occurs, both sides need to know the resulting state. If 
you sent me a 469, and your application decided that this terminated the 
dialog but mine decided it only terminated the transaction, the result 
would be unexpected and decidedly unfortunate behavior.

That's why we bothered to publish RFC 5057 at all.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Nov 2009 09:24:52 -0500

Adam,

I think Sanjay was responding to an earlier comment by me.

I had said that INFO failures should only affect the transaction, and 
that if such an error was more profound to the application then the 
application has the option of taking down the session (using BYE).

So I think we are all in agreement.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 15:35:46 +0100

Hi,

I agree with Adam, and based on feeback I got from Robert, a 469 should
NEVER terminate the dialog usage, and individual Info Packages shall not
change that.

Anyone objects to that?

Regards,

Christer

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: 5. marraskuuta 2009 23:44
> To: Sanjay Sinha (sanjsinh)
> Cc: Paul Kyzivat (pkyzivat); Christer Holmberg; SIPCORE
> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing
> 
> [as an individual]
> 
> That's functionally equivalent to asking "why don't we leave 
> it to the application to decide whether a BYE terminates an 
> invite usage?"
> 
> When an error occurs, both sides need to know the resulting 
> state. If you sent me a 469, and your application decided 
> that this terminated the dialog but mine decided it only 
> terminated the transaction, the result would be unexpected 
> and decidedly unfortunate behavior.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 15:38:40 +0100

Hi, 

>I had said that INFO failures should only affect the 
>transaction, and that if such an error was more profound to 
>the application then the application has the option of taking 
>down the session (using BYE).
> 

Bueno. That is also what the pre-03 version says.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 7 Nov 2009 15:34:31 +0100

I am fine with the text we now have in -03pre which says:

   If a UA receives an INFO request associated with an Info Package that
   the UA has not indicated willingness to receive, the UA MUST send a
   469 (Bad INFO Package) response (see Section 11.6).  In the
   terminology of Multiple Dialog Usages [RFC5057], this represents a
   Transaction Only failure.  Based on [RFC5057] the response represents
   a Transaction Only failure, and does not terminate the invite dialog
   usage.

except that we now seem to be saying it twice. Can we combine this into a single sentence.

I note that we have covered the dialog usage of other responses to INFO in 3.2.2 as follows:

   The UA MAY send other error responses, such as Request Failure (4xx),
   Server Failure (5xx) and Global Failure (6xx), in accordance with the
   error handling procedures in [RFC5057].

except that surely we need a parallel paragraph to this in section 3.2.1 to say that reception of such responses is handled as defined in RFC 5057.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Friday, November 06, 2009 2:36 PM
> To: Adam Roach; Sanjay Sinha (sanjsinh)
> Cc: SIPCORE
> I agree with Adam, and based on feeback I got from Robert, a 
> 469 should NEVER terminate the dialog usage, and individual 
> Info Packages shall not change that.
> 
> Anyone objects to that?
> 
> Regards,
> 
> Christer
> 
> 
>  
> 
> state. If 
> > you sent me a 469, and your application decided that this 
> terminated 
> > the dialog but mine decided it only terminated the transaction, the 
> > result would be unexpected and decidedly unfortunate behavior.
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Nov 2009 14:16:03 +0100

Hi, 

>except that we now seem to be saying it twice. Can we combine this into
a single sentence.

I changed it to:

   "If a UA receives an INFO request associated with an Info Package
that
   the UA has not indicated willingness to receive, the UA MUST send a
   469 (Bad INFO Package) response (see Section 11.6).  In the
   terminology of Multiple Dialog Usages [RFC5057], this represents a
   Transaction Only failure, and does not terminate the invite dialog
   usage."

>except that surely we need a parallel paragraph to this in section
3.2.1 to say that reception of such responses is 
>handled as defined in RFC 5057.

I am wondering whether the text should really refer to 5057. AFAIK 5057
does not specify what error code to send, only how they affect the
dialog usage. 

I would suggest that we refer to 3261 instead.

Regards,

Christer

> 469 should NEVER terminate the dialog usage, and individual Info 
> Packages shall not change that.
> 
> Anyone objects to that?
> 
> Regards,
> 
> Christer
> 
> 
>  
>