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
