Subject: [Sip] 199 Open Issue: UAS sending 199

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Nov 2008 20:17:29 +0100

Hi,

The main open issue in the 199 draft at the moment is when a UAS sends
199 - IF a UAS sends 199.

The alternative proposals I have at the moment are described below (can
also be found in the slides I was supposed to present yesterday).

1.	UAS never sends 199:

In this case only forking proxies/B2BUA would send 199.

2.	UAS always sends 199:

The issue with this alternative is that 199 would be sent even if no
forking has occurred - which can be assumed to be the case in a large
percentage of all calls.

3.	UAS sends 199 if forking proxy does not support 199:

With this alternative the forking proxy would have to insert an
indicator that it supports 199.

Also, the UAS may not know whether it is the forking proxy closest to
the UAS that has inserted the indicator. This may not be a big issues,
since I assume in most forking cases there will only be one forking
proxy in the signalling path.

4.	UAS sends 199 once procedures have reached a certain state

With this alternative 199 would not be sent until certain actions have
taken place on an early dialog

Example: preconditions have been indicated as met
Example: SDP answer has been sent

The issue is that one would always have to specify at what point of
different procedures 199 would be sengt.

5.	UAC and UAS negotiate sending of 199 once the early dialog has
been established:

With this alternative that UAC would tell the UAS that forking has
occurred (could this be useful information also for non-199
procedures?), and that it wants 199 to be sent.

The issues with this alternative is that it may require additional
signalling (unless PRACK/UPDATE won't be sent for other reasons) to
inform the UAS that forking has occurred.

Other alternatives? 

NOTE: Robert S also raised an issue on what Require: 199 means. But, I
think that outcome of that issue may depend on what way forward we
choose for the issue in this mail.

Regards,

Christer
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Tue, 18 Nov 2008 14:19:18 -0600

I would like to make draft-ietf-sip-199 more useful by expanding 
it's capabilities.

I would like to add a REQ-2 that allows that the Proxy to indicate
WHY the dialog was terminated. 

This would be done by having the 199 response include (as a sifrag or watever) 
the actual error response that terminated the dialog. At a minimum it would
include the value of the error code itself.

I would like to add text in the second-to-last paragraph of section
one that explains that the reason for specific dialogs to be terminated
may be useful for the client to take appropriate action (for example, by
re-attempting a call to a specific branch when the error is 
recoverable). And some similar text in section 4 on UAC behavior.

I think that would make the document more useful.

PS: I also agree with Hadriel's use cases as generally more useful than the
ones currently listed in the draft.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 18 Nov 2008 20:48:25 +0000

My opinion is that 199 shouldn't be restricted to cases involving
forking, since some of its utility lies in mitigating the behavior of
middle boxes that mis-interpret what they see as forking.
 
Is it possible to define a simpler version of alternative #4, giving
general guidance as to when a 199 may be issued and being prescriptive
about what the recipient is to do upon its receipt?
 
tim

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
	Sent: Tuesday, November 18, 2008 1:17 PM
	To: IETF SIP List
	Subject: [Sip] 199 Open Issue: UAS sending 199

	Hi, 

	The main open issue in the 199 draft at the moment is when a UAS
sends 199 - IF a UAS sends 199. 

	The alternative proposals I have at the moment are described
below (can also be found in the slides I was supposed to present
yesterday).

	1.      UAS never sends 199: 

	2.      UAS always sends 199: 

	The issue with this alternative is that 199 would be sent even
if no forking has occurred - which can be assumed to be the case in a
large percentage of all calls.

	Also, the UAS may not know whether it is the forking proxy
closest to the UAS that has inserted the indicator. This may not be a
big issues, since I assume in most forking cases there will only be one
forking proxy in the signalling path.

	4.      UAS sends 199 once procedures have reached a certain
state 

	With this alternative 199 would not be sent until certain
actions have taken place on an early dialog 

	The issue is that one would always have to specify at what point
of different procedures 199 would be sengt. 

	5.      UAC and UAS negotiate sending of 199 once the early
dialog has been established: 

	With this alternative that UAC would tell the UAS that forking
has occurred (could this be useful information also for non-199
procedures?), and that it wants 199 to be sent.

	The issues with this alternative is that it may require
additional signalling (unless PRACK/UPDATE won't be sent for other
reasons) to inform the UAS that forking has occurred.

	Other alternatives? 

	NOTE: Robert S also raised an issue on what Require: 199 means.
But, I think that outcome of that issue may depend on what way forward
we choose for the issue in this mail.

	Regards, 

	Christer

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 18 Nov 2008 16:32:38 -0500

> In this case only forking proxies/B2BUA 

I prefer the goal of option 1.  B2BUA (which is a UAS) or proxy sends
199 whenever it desires to indicate termination of a dialog and sending
a final INVITE response is not yet appropriate.  The subsequent INVITE
final response SHOULD contain a different To tag than those sent within
199s.  A device which does not trigger more than 1 To tag (i.e. fork or
simulate forking interaction) for an INVITE, SHOULD NOT generate a 199
since it needs to generate subsequent final failure response with the
same To tag.

<snip>

> Robert S also raised an issue on what Require: 199 means.

It means the UAS is required to support the RFC.

Depending upon RFC (working group decision), "Require: 199" means UAS
MAY, SHOULD, or MUST send 199 for early dialogs containing To tags
different than the INVITE's subsequent final response To tag; I prefer
MAY.

Depending upon RFC (working group decision), "Require: 199" also means
UAS MAY, SHOULD, MUST, or SHOULD NOT send 199 for early dialog
containing To tag which is the same as the INVITE's subsequent final
response To tag; I prefer SHOULD NOT.  If MUST is preferred, I would
desire usage of a different option-tag such as "failure-reason" or
"termination-reason".
_______________________________________________
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: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Nov 2008 23:10:40 +0100

Hi Brett,
 
>199 whenever it desires to indicate termination of a dialog and sending
a final INVITE response is not yet appropriate.  
>The subsequent INVITE final response SHOULD contain a different To tag
than those sent within 199s.  A device which does 
>not trigger more than 1 To tag (i.e. fork or simulate forking
interaction) for an INVITE, SHOULD NOT generate a 199 
same To tag.

That's a good point - maybe even a new alternative #6: UAS sends 199 if
it is handling more than one early dialog.

>Depending upon RFC (working group decision), "Require: 199" means UAS
MAY, SHOULD, or MUST send 199 for early dialogs 
>containing To tags different than the INVITE's subsequent final
response To tag; I prefer MAY.
>Depending upon RFC (working group decision), "Require: 199" also means
UAS MAY, SHOULD, MUST, or SHOULD NOT send 199 for 
>early dialog containing To tag which is the same as the INVITE's
subsequent final response To tag; I prefer SHOULD NOT.  
>If MUST is preferred, I would desire usage of a different option-tag
such as "failure-reason" or "termination-reason".

Yes. I think the Require:199 thing would be more tricky if an UAS NEVER
sends 199.

But, in any case I agree with Robert S that it is good to clarify the
meaning of Require in the draft.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Nov 2008 23:13:58 +0100

Hi Tim,
 
>My opinion is that 199 shouldn't be restricted to cases involving
forking, since some of its utility lies in  
>mitigating the behavior of middle boxes that mis-interpret what they
see as forking. 
 
I am not sure I understand. Could you please clarify?
 
>Is it possible to define a simpler version of alternative #4, giving
general guidance as to when a 199 may be issued  
>and being prescriptive about what the recipient is to do upon its
receipt? 
 
Personally I think it would be very difficult to come up with something
general and useful.
 
Regards,
 
Christer

	Hi, 

	1.      UAS never sends 199: 

	2.      UAS always sends 199: 

	Other alternatives? 

	Regards, 

	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Nov 2008 23:28:18 +0100

Hi Francois, 

>I would like to make draft-ietf-sip-199 more useful by expanding it's
capabilities.
>
>I would like to add a REQ-2 that allows that the Proxy to indicate WHY
the dialog was terminated. 
>
>This would be done by having the 199 response include (as a sifrag or
watever) the actual error response that terminated >the dialog. At a
minimum it would include the value of the error code itself.
>
>I would like to add text in the second-to-last paragraph of section one
that explains that the reason for specific 
>dialogs to be terminated may be useful for the client to take
appropriate action (for example, by re-attempting a call 
>to a specific branch when the error is recoverable). And some similar
text in section 4 on UAC behavior.
>I think that would make the document more useful.

The agreement in Dublin was to not say anything about sipfrag. But, I am
ok with putting it back, especially if people want more use-cases. I
guess it could be optional for the UAC to inidicate support of sipfrag.

>PS: I also agree with Hadriel's use cases as generally more useful than
the ones currently listed in the draft.

My intention is to add those use-cases to the next version of the draft.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Nov 2008 16:46:58 -0600

> The agreement in Dublin was to not say anything about 
> sipfrag. But, I am ok with putting it back, especially if 
> people want more use-cases. I guess it could be optional for 
> the UAC to inidicate support of sipfrag.

Hi Christer,

It doesn't have to be sipfrag. Just the plain value of the 
error response code would work too.  Whatever is easier.

I just think that getting the reason WHY the fork failed is
useful.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 18 Nov 2008 23:50:13 +0100

Hi, 

>>The agreement in Dublin was to not say anything about sipfrag. But, I 
>>am ok with putting it back, especially if people want more use-cases. 
>>I guess it could be optional for the UAC to inidicate support of 
>>sipfrag.
>
>It doesn't have to be sipfrag. Just the plain value of the error
response code would work too.  Whatever is easier.

Maybe the Reason header could be used? Or a new parameter. I agree that
sipfrag is a little too "heavy" for sending a response code.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Nov 2008 16:51:34 -0600

Yeah, reason header seems appropriate and would be good enough I think. 

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, November 18, 2008 14:50
> To: Audet, Francois (SC100:3055); IETF SIP List
> Subject: RE: How to make draft-ietf-sip-199 more useful
> 
> 
> Hi, 
> 
> sipfrag. But, I 
> Maybe the Reason header could be used? Or a new parameter. I 
> agree that sipfrag is a little too "heavy" for sending a 
> response code.
> 
> Regards,
> 
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Nov 2008 19:49:07 -0500

> sipfrag is a little too "heavy" for sending a response code.

Well, with REFER sipfrag is typically used to carry only the response 
code. Sending more is optional. If something is to be sent then I think 
this is a good mechanism for doing so. I think the question would be 
whether sending the sipfrag with at least the reason is MUST, SHOULD, or 
MAY.

OTOH, I thought this was removed from the draft because some people 
thought this smacked too much of solving the HERFP problem when it 
didn't really do the job fully. Has anything changed?

	Thanks,
	Paul

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 19 Nov 2008 06:44:50 +0000

Christer,
 
Sorry, when I said "mis-interpret what they see as forking" I meant to
refer to serial forking, which is of course a form of forking.  So
there's no mis-interpretation (except mine!).  
 
But anyway the thought was that by providing a way to explicitly release
an early media stream the 199 could enable a "middle box" (SBC) that
today blocks serial forking, to support it.  This is one of the use
cases Hadriel mentioned.
 
tim

	From: Christer Holmberg [mailto:[email-masked]] 
	Sent: Tuesday, November 18, 2008 4:14 PM
	To: Dwight, Timothy M (Tim); IETF SIP List
	Subject: RE: [Sip] 199 Open Issue: UAS sending 199

	Hi Tim,
	 
	>My opinion is that 199 shouldn't be restricted to cases
involving forking, since some of its utility lies in  
	>mitigating the behavior of middle boxes that mis-interpret what
they see as forking. 

	>Is it possible to define a simpler version of alternative #4,
giving general guidance as to when a 199 may be issued  
	>and being prescriptive about what the recipient is to do upon
its receipt? 
	 
	Personally I think it would be very difficult to come up with
something general and useful.
	 
	Regards,
	 
	Christer

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christer Holmberg
		Sent: Tuesday, November 18, 2008 1:17 PM
		To: IETF SIP List
		Subject: [Sip] 199 Open Issue: UAS sending 199

		Hi, 

		The main open issue in the 199 draft at the moment is
when a UAS sends 199 - IF a UAS sends 199. 

		The alternative proposals I have at the moment are
described below (can also be found in the slides I was supposed to
present yesterday).

		1.      UAS never sends 199: 

		2.      UAS always sends 199: 

		The issue with this alternative is that 199 would be
sent even if no forking has occurred - which can be assumed to be the
case in a large percentage of all calls.

		3.      UAS sends 199 if forking proxy does not support
199: 

		With this alternative the forking proxy would have to
insert an indicator that it supports 199. 

		Also, the UAS may not know whether it is the forking
proxy closest to the UAS that has inserted the indicator. This may not
be a big issues, since I assume in most forking cases there will only be
one forking proxy in the signalling path.

		4.      UAS sends 199 once procedures have reached a
certain state 

		With this alternative 199 would not be sent until
certain actions have taken place on an early dialog 

		The issue is that one would always have to specify at
what point of different procedures 199 would be sengt. 

		5.      UAC and UAS negotiate sending of 199 once the
early dialog has been established: 

		With this alternative that UAC would tell the UAS that
forking has occurred (could this be useful information also for non-199
procedures?), and that it wants 199 to be sent.

		Other alternatives? 

		NOTE: Robert S also raised an issue on what Require: 199
means. But, I think that outcome of that issue may depend on what way
forward we choose for the issue in this mail.

		Regards, 

		Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 19 Nov 2008 10:11:40 -0600

"Solving HERPF" in general does not appear to be something we are 
willing to do. 

However, having 199 carry useful information such as "why the 
dialog was terminated", to me, seems like something that ought
be allowed. 

PS: I think including the reason should be mandatory.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, November 18, 2008 16:49
> To: Christer Holmberg
> Cc: Audet, Francois (SC100:3055); IETF SIP List
> Subject: Re: [Sip] How to make draft-ietf-sip-199 more useful
> 
> 
> 
> Christer Holmberg wrote:
> > Hi,
> > 
> sipfrag. But, 
> >>> I am ok with putting it back, especially if people want 
> more use-cases.
> > Maybe the Reason header could be used? Or a new parameter. I agree 
> > that sipfrag is a little too "heavy" for sending a response code.
> 
> Well, with REFER sipfrag is typically used to carry only the 
> response code. Sending more is optional. If something is to 
> be sent then I think this is a good mechanism for doing so. I 
> think the question would be whether sending the sipfrag with 
> at least the reason is MUST, SHOULD, or MAY.
> 
> OTOH, I thought this was removed from the draft because some 
> people thought this smacked too much of solving the HERFP 
> problem when it didn't really do the job fully. Has anything changed?
> 
> 	Thanks,
> 	Paul
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Nov 2008 00:02:24 +0000

Francois, 

> Behalf Of Francois Audet
> Sent: 18 November 2008 20:19
> To: Christer Holmberg; IETF SIP List
> Subject: [Sip] How to make draft-ietf-sip-199 more useful
> 
> recoverable).
[JRE] But how would the re-attempted call to a specific branch be
achieved? What goes in the Request-URI - the received Contact URI? Then
presumably Route header fields would need to be added based on
Record-Routes from the previous dialog? Or if the Contact URI has GRUU
properties, I guess Route isn't needed. But what if a temporary GRUU -
would it still be valid?

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 05:52:16 +0100

Hi, 

capabilities.
>watever) the actual error response that terminated the dialog. At a 
>one that explains that the reason for specific dialogs to be 
>terminated may be useful for the client to take appropriate action 
>(for example, by re-attempting a call to a specific branch when the 
>error is recoverable).
achieved? What goes in the Request-URI - the received 
>Contact URI? Then presumably Route header fields would need to be added
based on Record-Routes from the previous dialog? 
>Or if the Contact URI has GRUU properties, I guess Route isn't needed.
But what if a temporary GRUU - would it still be 
>valid?

Those are interesting questions, but go beyond the scope of the draft.

My proposal is to add text about including the original response code,
but NOT specify procedures for solving HERFP problems etc.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Nov 2008 07:53:40 -0600

Yes, I agree with Christer. (wow!) 

> Sent: Wednesday, November 19, 2008 20:52
> To: Elwell, John; Audet, Francois (SC100:3055); IETF SIP List
> Subject: RE: [Sip] How to make draft-ietf-sip-199 more useful
> 
> 
> Hi, 
> 
> >that explains that the reason for specific dialogs to be 
> terminated may 
> >be useful for the client to take appropriate action (for example, by 
> My proposal is to add text about including the original 
> response code, but NOT specify procedures for solving HERFP 
> problems etc.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 08:31:21 +0100

Hi Tim,
 
So, I guess the use-case you are thinking about is when an AS
establishes an early dialog with the UAC, in order to play some early
media stream, and then sends 199 afterwards to terminate that dialog?
 
I think that would fit with the proposed UAS rule, saying that a UAS
which establishes more than one dialog would be allowed to send 199.
 
Or, did I missunderstand your use-case? :)
 
Regards,
 
Christer

	From: Dwight, Timothy M (Tim)
[mailto:[email-masked]] 
	Sent: 19. marraskuuta 2008 8:45
	To: Christer Holmberg; IETF SIP List
	Subject: RE: [Sip] 199 Open Issue: UAS sending 199

	Christer,
	 
	Sorry, when I said "mis-interpret what they see as forking" I
meant to refer to serial forking, which is of course a form of forking.
So there's no mis-interpretation (except mine!).  
	 
	But anyway the thought was that by providing a way to explicitly
release an early media stream the 199 could enable a "middle box" (SBC)
that today blocks serial forking, to support it.  This is one of the use
cases Hadriel mentioned.
	 
	tim

		From: Christer Holmberg
[mailto:[email-masked]] 
		Sent: Tuesday, November 18, 2008 4:14 PM
		To: Dwight, Timothy M (Tim); IETF SIP List
		Subject: RE: [Sip] 199 Open Issue: UAS sending 199

		Hi Tim,
		 
		>mitigating the behavior of middle boxes that
mis-interpret what they see as forking. 

		>Is it possible to define a simpler version of
alternative #4, giving general guidance as to when a 199 may be issued  
		>and being prescriptive about what the recipient is to
do upon its receipt? 
		 
		Personally I think it would be very difficult to come up
with something general and useful.
		 
		Regards,
		 
		Christer

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Christer Holmberg
			Sent: Tuesday, November 18, 2008 1:17 PM
			To: IETF SIP List
			Subject: [Sip] 199 Open Issue: UAS sending 199

			Hi, 

			The main open issue in the 199 draft at the
moment is when a UAS sends 199 - IF a UAS sends 199. 

			The alternative proposals I have at the moment
are described below (can also be found in the slides I was supposed to
present yesterday).

			1.      UAS never sends 199: 

			In this case only forking proxies/B2BUA would
send 199. 

			2.      UAS always sends 199: 

			The issue with this alternative is that 199
would be sent even if no forking has occurred - which can be assumed to
be the case in a large percentage of all calls.

			3.      UAS sends 199 if forking proxy does not
support 199: 

			With this alternative the forking proxy would
have to insert an indicator that it supports 199. 

			Also, the UAS may not know whether it is the
forking proxy closest to the UAS that has inserted the indicator. This
may not be a big issues, since I assume in most forking cases there will
only be one forking proxy in the signalling path.

			4.      UAS sends 199 once procedures have
reached a certain state 

			With this alternative 199 would not be sent
until certain actions have taken place on an early dialog 

			Example: preconditions have been indicated as
met 
			Example: SDP answer has been sent 

			The issue is that one would always have to
specify at what point of different procedures 199 would be sengt. 

			5.      UAC and UAS negotiate sending of 199
once the early dialog has been established: 

			With this alternative that UAC would tell the
UAS that forking has occurred (could this be useful information also for
non-199 procedures?), and that it wants 199 to be sent.

			The issues with this alternative is that it may
require additional signalling (unless PRACK/UPDATE won't be sent for
other reasons) to inform the UAS that forking has occurred.

			Other alternatives? 

			NOTE: Robert S also raised an issue on what
Require: 199 means. But, I think that outcome of that issue may depend
on what way forward we choose for the issue in this mail.

			Regards, 

			Christer

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 25 Nov 2008 14:18:11 +0000

Christer,
 
Yes, that's what I meant.  Maybe this is a usage more common in IMS, but
(as you know) in IMS it is possible for an S-CSCF to invoke application
servers on behalf of the party (calling or called) it is serving.  The
AS's may in turn establish early media dialogs.  It would be useful in
terms of being economical with resources (particularly in the RAN) to
release the associated resources as soon as possible.  Sometimes it's
more than "useful", sometimes it's necessary, because of limitations
e.g., in a "middlebox" (SBC or IMS equivalent thereof).  Today we
redesign call flows to avoid such issues, but it would be nice not to
have to.
 
I'm not sure this fits the proposed UAS rule.  My concern isn't with a
single UAS that establishes multiple dialogs, it's with a series of
UAS's each of which will generally only establish one dialog (and each
of which is generally unaware of the others).
 
If I made S-CSCF's I'd probably feel that the AS's should "clean up
their own mess" (issue a 199 prior to releasing control back to the
S-CSCF); even if the AS had only established one dialog.  I suppose it's
also possible for the S-CSCF to clean up after the AS, and arguably the
S-CSCF is in a better position to know whether a 199 is necessary.  But
it seems complicated to ask this of the S-CSCF since it would have to
monitor the SDP of all messages to and from AS's it invokes, to know
which ones established early media dialogs and failed to "close them
out".
 
Is it problematic to allow a UAS to issue a 199 even if it has
established only a single dialog?
 
tim

	From: Christer Holmberg [mailto:[email-masked]] 
	Sent: Tuesday, November 25, 2008 1:31 AM
	To: Dwight, Timothy M (Tim); IETF SIP List
	Subject: RE: [Sip] 199 Open Issue: UAS sending 199

	Hi Tim,

	I think that would fit with the proposed UAS rule, saying that a
UAS which establishes more than one dialog would be allowed to send 199.

	Regards,
	 
	Christer

		Christer,
		 
		Sorry, when I said "mis-interpret what they see as
forking" I meant to refer to serial forking, which is of course a form
of forking.  So there's no mis-interpretation (except mine!).  
		 
		But anyway the thought was that by providing a way to
explicitly release an early media stream the 199 could enable a "middle
box" (SBC) that today blocks serial forking, to support it.  This is one
of the use cases Hadriel mentioned.
		 
		tim

			From: Christer Holmberg
[mailto:[email-masked]] 
			Sent: Tuesday, November 18, 2008 4:14 PM
			To: Dwight, Timothy M (Tim); IETF SIP List
			Subject: RE: [Sip] 199 Open Issue: UAS sending
199

			Hi Tim,
			 
			>My opinion is that 199 shouldn't be restricted
to cases involving forking, since some of its utility lies in  
			 
			I am not sure I understand. Could you please
clarify?
			 
			>and being prescriptive about what the recipient
is to do upon its receipt? 
			 
			Personally I think it would be very difficult to
come up with something general and useful.
			 
			Regards,
			 
			Christer

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Christer Holmberg
				Sent: Tuesday, November 18, 2008 1:17 PM
				To: IETF SIP List
				Subject: [Sip] 199 Open Issue: UAS
sending 199

				Hi, 

				The main open issue in the 199 draft at
the moment is when a UAS sends 199 - IF a UAS sends 199. 

				The alternative proposals I have at the
moment are described below (can also be found in the slides I was
supposed to present yesterday).

				1.      UAS never sends 199: 

				In this case only forking proxies/B2BUA
would send 199. 

				2.      UAS always sends 199: 

				The issue with this alternative is that
199 would be sent even if no forking has occurred - which can be assumed
to be the case in a large percentage of all calls.

				3.      UAS sends 199 if forking proxy
does not support 199: 

				With this alternative the forking proxy
would have to insert an indicator that it supports 199. 

				Also, the UAS may not know whether it is
the forking proxy closest to the UAS that has inserted the indicator.
This may not be a big issues, since I assume in most forking cases there
will only be one forking proxy in the signalling path.

				4.      UAS sends 199 once procedures
have reached a certain state 

				With this alternative 199 would not be
sent until certain actions have taken place on an early dialog 

				Example: preconditions have been
indicated as met 
				Example: SDP answer has been sent 

				The issue is that one would always have
to specify at what point of different procedures 199 would be sengt. 

				5.      UAC and UAS negotiate sending of
199 once the early dialog has been established: 

				With this alternative that UAC would
tell the UAS that forking has occurred (could this be useful information
also for non-199 procedures?), and that it wants 199 to be sent.

				The issues with this alternative is that
it may require additional signalling (unless PRACK/UPDATE won't be sent
for other reasons) to inform the UAS that forking has occurred.

				Other alternatives? 

				NOTE: Robert S also raised an issue on
what Require: 199 means. But, I think that outcome of that issue may
depend on what way forward we choose for the issue in this mail.

				Regards, 

				Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Nov 2008 15:26:32 +0100

Hi Tim, 
	 
>Yes, that's what I meant.  Maybe this is a usage more common in IMS,
but (as you know) in IMS it is possible for an S-CSCF to invoke
application servers on behalf of the party (calling or 
>called) it is serving.  The AS's may in turn establish early media
dialogs.  It would be useful in terms of being economical with resources
(particularly in the RAN) to release the associated 
>resources as soon as possible.  Sometimes it's more than "useful",
sometimes it's necessary, because of limitations e.g., in a "middlebox"
(SBC or IMS equivalent thereof).  Today we redesign 
>call flows to avoid such issues, but it would be nice not to have to.

Yes. And, I don't think it is IMS specific having an application servers
which creates a specific dialog for anouncmements etc :)
	 
single UAS that establishes multiple dialogs, it's with a series of
UAS's each of which will generally only establish one 
>dialog (and each of which is generally unaware of the others).
>	 
their own mess" (issue a 199 prior to releasing control back to the
S-CSCF); even if the AS had only established one dialog.  
>I suppose it's also possible for the S-CSCF to clean up after the AS,
and arguably the S-CSCF is in a better position to know whether a 199 is
necessary.  But it seems complicated to ask this 
>of the S-CSCF since it would have to monitor the SDP of all messages to
and from AS's it invokes, to know which ones established early media
dialogs and failed to "close them out".

Well, I could add some text, saying that an UAS may do it "based on
configuration", or something like that. I think the important thing is
that UASs don't start to send 199 responses "by default".

Regards,

Christer

		From: Christer Holmberg

		Hi Tim,
		 
		So, I guess the use-case you are thinking about is when
an AS establishes an early dialog with the UAC, in order to play some
early media stream, and then sends 199 afterwards to terminate that
dialog?
		 
		I think that would fit with the proposed UAS rule,
saying that a UAS which establishes more than one dialog would be
allowed to send 199.

		Regards,
		 
		Christer

			Christer,
			 
			Sorry, when I said "mis-interpret what they see
as forking" I meant to refer to serial forking, which is of course a
form of forking.  So there's no mis-interpretation (except mine!).  
			 
			But anyway the thought was that by providing a
way to explicitly release an early media stream the 199 could enable a
"middle box" (SBC) that today blocks serial forking, to support it.
This is one of the use cases Hadriel mentioned.
			 
			tim

				From: Christer Holmberg
[mailto:[email-masked]] 
				Sent: Tuesday, November 18, 2008 4:14 PM
				To: Dwight, Timothy M (Tim); IETF SIP
List
				Subject: RE: [Sip] 199 Open Issue: UAS
sending 199

				Hi Tim,
				 
				>My opinion is that 199 shouldn't be
restricted to cases involving forking, since some of its utility lies in

				>mitigating the behavior of middle boxes
that mis-interpret what they see as forking. 
				 
				I am not sure I understand. Could you
please clarify?
				 
				>Is it possible to define a simpler
version of alternative #4, giving general guidance as to when a 199 may
be issued  
				>and being prescriptive about what the
recipient is to do upon its receipt? 
				 
				Personally I think it would be very
difficult to come up with something general and useful.
				 
				Regards,
				 
				Christer

					From: [email-masked]
[mailto:[email-masked]] On Behalf Of Christer Holmberg
					Sent: Tuesday, November 18, 2008
1:17 PM
					To: IETF SIP List
					Subject: [Sip] 199 Open Issue:
UAS sending 199

					Hi, 

					The main open issue in the 199
draft at the moment is when a UAS sends 199 - IF a UAS sends 199. 

					The alternative proposals I have
at the moment are described below (can also be found in the slides I was
supposed to present yesterday).

					1.      UAS never sends 199: 

					In this case only forking
proxies/B2BUA would send 199. 

					2.      UAS always sends 199: 

					The issue with this alternative
is that 199 would be sent even if no forking has occurred - which can be
assumed to be the case in a large percentage of all calls.

					With this alternative the
forking proxy would have to insert an indicator that it supports 199. 

					Also, the UAS may not know
whether it is the forking proxy closest to the UAS that has inserted the
indicator. This may not be a big issues, since I assume in most forking
cases there will only be one forking proxy in the signalling path.

					4.      UAS sends 199 once
procedures have reached a certain state 

					With this alternative 199 would
not be sent until certain actions have taken place on an early dialog 

					Example: preconditions have been
indicated as met 
					Example: SDP answer has been
sent 

					The issue is that one would
always have to specify at what point of different procedures 199 would
be sengt. 

					5.      UAC and UAS negotiate
sending of 199 once the early dialog has been established: 

					With this alternative that UAC
would tell the UAS that forking has occurred (could this be useful
information also for non-199 procedures?), and that it wants 199 to be
sent.

					The issues with this alternative
is that it may require additional signalling (unless PRACK/UPDATE won't
be sent for other reasons) to inform the UAS that forking has occurred.

					Other alternatives? 

					NOTE: Robert S also raised an
issue on what Require: 199 means. But, I think that outcome of that
issue may depend on what way forward we choose for the issue in this
mail.

					Regards, 

					Christer