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 :)
>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?
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
[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
