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

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 28 Oct 2009 22:09:39 +0100

Hi,

I would like to point out the following WGLC comment provided by Keith.

------------------

"7.3.  Dialog Fate Sharing

   As described in [RFC5057], an INFO request is always part of an
   INVITE dialog usage.

   One needs to consider the fate of the dialog usage of an INFO request
   is rejected. In some cases it may be acceptable that the whole
   dialog usage is terminated, while in other cases is is desirable to
   maintain the dialog usage.

However as we have a specific new response code that represents a
failure of the INFO method extension rather than any specific package, I
believe the actions for 469 in respect of the dialog usage 
should be defined in this document."

------------------

Personally I agree with Keith - the fate of the dialog should not depend
on the package (and the SIP stack should not need to know package
specific behavior).

So, we should, in the main part of the spec talking about INFO
responses, specify whether 469 terminates the invite dialog usage, or
just the transaction.

I don't see a reason to terminte the whole invite dialog usage, because
the 469 could come due to a race condition, when I've sent a re-INVITE
with a new set of Info Packages, but the remote UA sent an INFO based on
the old set before it received the re-INVITE. 

But, I guess Robert can give some guidance.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2009 17:36:02 -0400

I don't think INFO should add any new dialog or usage failure cases.
Errors that generically cause global failure, such as 408, should of 
course do so for INFO as well. But specific failures of INFO (legacy or 
with I-P) should only fail the transaction.

If in a particular case an application wants to consider some result of 
and INFO to be fatal to the call it has ample means to cause that to happen.

	Thanks,
	Paul

Christer Holmberg wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 29 Oct 2009 02:57:07 -0400

I agree. 

If the INFO transaction fails, then let the application decide whether
it wants to continue with the dialog or not?

Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
Sent: Thursday, October 29, 2009 3:06 AM
To: Christer Holmberg
Cc: SIPCORE
Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing

If in a particular case an application wants to consider some result of 
and INFO to be fatal to the call it has ample means to cause that to
happen.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 08:41:57 +0100

Hi,
 
So, do people think we should keep the existing text (section 7.3), which talks about the dialog fate?
 
Regards.
 
Christer

________________________________

From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]]
Sent: Thu 10/29/2009 7:57 AM
To: Paul Kyzivat (pkyzivat); Christer Holmberg
Cc: SIPCORE
Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing

I agree.

Sanjay

-----Original Message-----

        Thanks,
        Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Oct 2009 11:05:20 +0100

Christer,

This is in the section on Info Package considerations. I rather doubt there is anything you need to specify on this topic when defining an Info-Package. All Info-Packages should be subject to the same rules: i.e., depending on the particular error response to an INFO request, the dialog usage will either remain or be terminated. If we need to say anything more on this matter (e.g., the impact of 469), that should be covered elsewhere in the document. I don't think we need 7.3.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 29 October 2009 07:42
> To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat)
> Cc: SIPCORE
> > failure of the INFO method extension rather than any 
> specific package,
> I
> > with a new set of Info Packages, but the remote UA sent an 
> INFO based
> on

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Oct 2009 11:23:56 +0100

To clarify on my original comment.

Any specific text on receipt of 469 should go in the most appropriate section, which is definitely not section 7 - I would suggest somewhere around section 4.4, but not in 4.4 because this is all UAS functionality and we want UAC functionality.

With 469 we do not have a Info-Package, becuase the receiver was unable to recognise one that was valid. If for example two had been previously negotiated with Recv-Info, it could be either of them, or indeed the unnegotiated appearance of a third. That is why I think the issue is generic rather than Info Package specific.

I would confirm that I see no need to kill the dialog but merely the transaction.

regards

Keith  

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Thursday, October 29, 2009 10:05 AM
> To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat 
> (pkyzivat)
> Cc: SIPCORE
> This is in the section on Info Package considerations. I 
> rather doubt there is anything you need to specify on this 
> topic when defining an Info-Package. All Info-Packages should 
> be subject to the same rules: i.e., depending on the 
> particular error response to an INFO request, the dialog 
> usage will either remain or be terminated. If we need to say 
> anything more on this matter (e.g., the impact of 469), that 
> should be covered elsewhere in the document. I don't think we 
> need 7.3.
> 
> John
> 
> > course do so for INFO as well. But specific failures of 
> INFO (legacy 
> > or with I-P) should only fail the transaction.
> > 
> > If in a particular case an application wants to consider 
> some result 
> > of and INFO to be fatal to the call it has ample means to 
> cause that 
> > to happen.
> > 
> >         Thanks,
> >         Paul
> > 
> > Christer Holmberg wrote:
> > >
> > > Hi,
> > >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Oct 2009 11:31:19 +0100

I had no problem with this text. I merely cited as some text that was related to my issue, but did not solve it.

regards

Keith 

> Sent: Thursday, October 29, 2009 7:42 AM
> If the INFO transaction fails, then let the application 
> decide whether it wants to continue with the dialog or not?
> 
> Sanjay
> 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
> Errors that generically cause global failure, such as 408, 
> should of course do so for INFO as well. But specific 
> failures of INFO (legacy or with I-P) should only fail the 
> transaction.
> 
> If in a particular case an application wants to consider some 
> result of and INFO to be fatal to the call it has ample means 
> to cause that to happen.
> 
>         Thanks,
>         Paul
> 
> Christer Holmberg wrote:
> >
> > Hi,
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 14:35:15 +0100

Hi,

I am not sure I understood what you said, but I'll give it a try. 

>Any specific text on receipt of 469 should go in the most appropriate
section, which is definitely not section 7 - I would suggest somewhere
around 
>section 4.4, but not in 4.4 because this is all UAS functionality and
we want UAC functionality.

Ok, so whatever text we write should not be in section 7, but somewhere
else. Then, the section 7 text is removed, and the individual Info
Package specifications do not need to say anything about the dialog
fate?

Or?

>With 469 we do not have a Info-Package, becuase the receiver was unable
to recognise one that was valid. If for example two had been previously 
>negotiated with Recv-Info, it could be either of them, or indeed the
unnegotiated appearance of a third. That is why I think the issue is
generic rather 
>than Info Package specific.

I think you will only send 469 if the INFO request contained
Info-Package, and the idea is that the 469 contains the latest set of
packages. One must not use the 469 to CHANGE the set, and maybe we need
to make that clear.

>I would confirm that I see no need to kill the dialog but merely the
transaction.

I agree with you. The question is whether we need to say something about
it. Based on what others say, it seems like we wouldn't need any text at
all about dialog fate. But, my head is so full of INFO that it soon
explodes, so I may have missunderstood :)

Regards,

Christer

> This is in the section on Info Package considerations. I rather doubt 
> there is anything you need to specify on this topic when defining an 
> Info-Package. All Info-Packages should be subject to the same rules: 
> i.e., depending on the particular error response to an INFO request, 
> the dialog usage will either remain or be terminated. If we need to 
> say anything more on this matter (e.g., the impact of 469), that 
> should be covered elsewhere in the document. I don't think we need 
> 7.3.
> 
> John
> 
> decide whether
> should of

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Oct 2009 10:05:45 -0500

I agree this document should talk about the 5057 impact for the 469  
response code and it would not make sense for that
behavior to change per-package. And I agree that the 469 only affects  
the transaction.

I'm not sure if you're asking about this, but this document can  
probably explore the effect of other error codes, and it would be  
wrong to preclude event-package-specific effects for those.

RjS

On Oct 28, 2009, at 4:09 PM, Christer Holmberg wrote:

> failure of the INFO method extension rather than any specific  
> package, I believe the actions for 469 in respect of the dialog usage
>
> Personally I agree with Keith - the fate of the dialog should not  
> depend on the package (and the SIP stack should not need to know  
> package specific behavior).
>
> responses, specify whether 469 terminates the invite dialog usage,  
> or just the transaction.
>
> I don't see a reason to terminte the whole invite dialog usage,  
> because the 469 could come due to a race condition, when I've sent a  
> re-INVITE with a new set of Info Packages, but the remote UA sent an  
> INFO based on the old set before it received the re-INVITE.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Oct 2009 16:52:24 +0100

Treat the 469 dialog handling text and the existing 7.3 text separately.

The 469 dialog handling belongs somewhere around the area of (but not in) section 4.4.

The 7.3 text should probably stay (in my view), and if it stays, it belongs where it currently is. If the consensus is to remove it (as suggested by some other people), then that is also fine, but I have no problem keeping it.

regards

Keith

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Thursday, October 29, 2009 1:35 PM
> To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha 
> (sanjsinh); Paul Kyzivat (pkyzivat)
> Cc: SIPCORE
> section, which is definitely not section 7 - I would suggest 
> somewhere around 
> Ok, so whatever text we write should not be in section 7, but 
> somewhere else. Then, the section 7 text is removed, and the 
> individual Info Package specifications do not need to say 
> anything about the dialog fate?
> 
> Or?
> 
> unnegotiated appearance of a third. That is why I think the 
> issue is generic rather 
> Info-Package, and the idea is that the 469 contains the 
> latest set of packages. One must not use the 469 to CHANGE 
> the set, and maybe we need to make that clear.
> 
> I agree with you. The question is whether we need to say 
> something about it. Based on what others say, it seems like 
> we wouldn't need any text at all about dialog fate. But, my 
> head is so full of INFO that it soon explodes, so I may have 
> missunderstood :)
> 
> Regards,
> 
> Christer
> 
> 
> rather doubt 
> > > So, do people think we should keep the existing text 
> (section 7.3), 
> > > which talks about the dialog fate?
> > >  
> > > Regards.
> > >  
> > > Christer
> > > 
> > > depend
> > > because

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 21:18:36 +0100

Hi,

My suggestion is to go with Robert's proposal, then and somewhere (in
Section 4.x) generally indciate that 469 only affects the transaction,
and then remote the text from section 7.

We used to have a section dedicated to the 469 response, so I guess it
could have fitted there also, but I was asked to remove it because the
text at that time didn't really bring anything new.

Regards,

Christer

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: 29. lokakuuta 2009 17:52
To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul
Kyzivat (pkyzivat)
Cc: SIPCORE

The 469 dialog handling belongs somewhere around the area of (but not
in) section 4.4.

The 7.3 text should probably stay (in my view), and if it stays, it
belongs where it currently is. If the consensus is to remove it (as
suggested by some other people), then that is also fine, but I have no
problem keeping it.

regards

Keith

> To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha (sanjsinh); Paul 
> Kyzivat (pkyzivat)
> Cc: SIPCORE

> individual Info Package specifications do not need to say anything 
> about the dialog fate?
> 
> Or?
> 
> packages. One must not use the 469 to CHANGE the set, and maybe we 
> need to make that clear.
> 
> I agree with you. The question is whether we need to say something 
> about it. Based on what others say, it seems like we wouldn't need any

> text at all about dialog fate. But, my head is so full of INFO that it

> soon explodes, so I may have missunderstood :)
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 30 Oct 2009 14:14:21 +0100

Hi,

I realized that section 4.4 already contains the following text about
469:

"In the terminology of Multiple Dialog Usages [RFC5057], this represents
a Transaction Only failure."

Regards,

Christer

> Sent: 29. lokakuuta 2009 22:19
> My suggestion is to go with Robert's proposal, then and 
> somewhere (in Section 4.x) generally indciate that 469 only 
> affects the transaction, and then remote the text from section 7.
> 
> We used to have a section dedicated to the 469 response, so I 
> guess it could have fitted there also, but I was asked to 
> remove it because the text at that time didn't really bring 
> anything new.
> 
> Regards,
> 
> Christer
> 
> To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); 
> Paul Kyzivat (pkyzivat)
> Cc: SIPCORE
> The 7.3 text should probably stay (in my view), and if it 
> stays, it belongs where it currently is. If the consensus is 
> to remove it (as suggested by some other people), then that 
> is also fine, but I have no problem keeping it.
> 
> regards
> 
> Keith
> 
> issue is 
> latest set of 
> > >I would confirm that I see no need to kill the dialog but 
> merely the
> > transaction.
> > 
> > > > > I would like to point out the following WGLC comment 
> provided by
> > > > Keith.
> > > > >
> > > > > ------------------
> > > > >
> > > > >    One needs to consider the fate of the dialog usage 
> of an INFO
> > > > request

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Oct 2009 14:19:41 +0100

Which covers the sender of the 469 but not the receiver. Apply the author guidelines and separate sender and receiver requirements into different sections.

regards

Keith 

> Sent: Friday, October 30, 2009 1:14 PM
> To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, John; 
> Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat)
> Cc: SIPCORE
> "In the terminology of Multiple Dialog Usages [RFC5057], this 
> represents a Transaction Only failure."
> 
> Regards,
> 
> Christer
> 
> somewhere (in 
> something

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 30 Oct 2009 14:30:57 +0100

Hi,

I could simply divide the paragraphs into two parts, and add some text
to the end of the new second paragraph:

"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 Section 11.6.  

In the terminology of Multiple Dialog Usages [RFC5057], the 469 Bad INFO
Package 
Response represents a Transaction Only failure, and a UA MUST NOT
terminate the invite dialog usage when 
it sends or receives a 469 response."

Regards,

Christer

> Sent: 30. lokakuuta 2009 15:20
> Which covers the sender of the 469 but not the receiver. 
> Apply the author guidelines and separate sender and receiver 
> requirements into different sections.
> 
> regards
> 
> Keith 
> 
> > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, John; Sanjay 
> > Sinha (sanjsinh); Paul Kyzivat (pkyzivat)
> > Cc: SIPCORE
> stays, it 
> > > > > > > responses, specify whether 469 terminates the 
> invite dialog
> > > > > > usage, or
> > > > > > > just the transaction.
> > > > > > >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Oct 2009 14:36:29 +0100

Please keep INFO method sender and INFO method receiver requirements in different sections.

Keith 

> Sent: Friday, October 30, 2009 1:31 PM
> I could simply divide the paragraphs into two parts, and add 
> some text to the end of the new second paragraph:
> 
> "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
> In the terminology of Multiple Dialog Usages [RFC5057], the 
> 469 Bad INFO Package Response represents a Transaction Only 
> failure, and a UA MUST NOT terminate the invite dialog usage 
> when it sends or receives a 469 response."
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> > > > > > > >    dialog usage is terminated, while in other 
> cases is is
> > > > > > > desirable to
> > > > > > > > the 469 could come due to a race condition, 
> when I've sent
> > > > > > > a re-INVITE
> > > > > > >

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 30 Oct 2009 14:51:43 +0100

The problem is that we don't have "UAC Procedures" and "UAS Procedures"
sections. We used to have that, but the text got very confusing.

Having said that, when I look at the text in the "4.2 INFO Request" and
"4.4 INFO Response" sections, I guess we COULD simply rename them to
"User Agent Client procedures" and "User Agent Server procedures",
without any major changes in the section itself. It would be more
alligned with the structure of section 3.

Regards,

Christer

> Sent: 30. lokakuuta 2009 15:36
> Package that 
> failure, 
> > and a UA MUST NOT terminate the invite dialog usage when it 
> sends or 
> > receives a 469 response."
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > > > > >With 469 we do not have a Info-Package, becuase 
> the receiver
> > > > > > was unable
> > > > > > to recognise one that was valid. If for example two 
> had been 
> > > > > > previously
> > > > > > > i.e., depending on the particular error response 
> to an INFO
> > > > > > request,
> > > > > > > > >    As described in [RFC5057], an INFO request 
> is always
> > > > > > part of an
> > > > > > > > >    INVITE dialog usage.
> > > > > > > > >
> > > > > > > > >    is rejected. In some cases it may be 
> acceptable that
> > > > > > the whole

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Oct 2009 16:05:50 +0100

I think we had a discussion way back about the terms UAC and UAS and understood them to be confusing in the context of INFO. It may be better to use terms "INFO request client" and "INFO request server" as section titles.

regards

Keith

> Sent: Friday, October 30, 2009 1:52 PM
> "4.4 INFO Response" sections, I guess we COULD simply rename
> them to "User Agent Client procedures" and "User Agent Server
> procedures", without any major changes in the section itself.
> It would be more alligned with the structure of section 3.
>
> Regards,
>
> Christer
>
>
> > Please keep INFO method sender and INFO method receiver
> requirements
> > in different sections.
> >
> > Keith
> >
> > > > > > Treat the 469 dialog handling text and the existing
> 7.3 text
> > > > > > separately.
> > > > > >
> > > > > > > > > > Personally I agree with Keith - the fate of
> the dialog
> > > > > > > should not
> > > > > > > > > depend

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 31 Oct 2009 13:27:32 +0100

Hi, 

>I think we had a discussion way back about the terms UAC and UAS and
understood them to be confusing in the context of INFO. It may be better
to use terms "INFO request client" and "INFO request server" 
>as section titles.

Yes, I was thinking about something like that. OR "INFO request sender"
and "INFO request receiver".

That terminology would also have made lots of specifications easier to
write, in my opinion :)

Regards,

Christer

> without any major changes in the section itself.
> > > > > > > > > > sipcore mailing list [email-masked]