Re: 199 Open Issue: UAS sending 199

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 protected]] 
	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,
	 
	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 protected]] 
		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 protected]] 
			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 protected]
[mailto:[email protected]] 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

_______________________________________________
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