It's my hope that the work related to avoiding multiple usages will
make this
an entirely academic discussion. On the chance that turns out to be
untrue, however,
the one place I can see this coming up more quickly than elsewhere is
if a UAC
decides it wants to subscribe to the dialog event package at each UAS
that
provisionally responds to its INVITE and decides to reuse the dialog
identifiers
that provisional response established.
RjS
On Aug 6, 2008, at 6:09 AM, Ian Elz wrote:
Paul,
I don't believe that you can create 'multiple early dialog usages'.
On an INVITE transaction can create an early dialog. The other dialog
creating transactions REFER and SUBSCRIBE, can only create established
dialogs.
As you cannot start a second INVITE transaction while there is an
outstanding INVITE transaction on a dialog, early or otherwise.
If you send a REFER or SUBSCRIBE method on an early dialog and you get
an acceptance response then you have an established dialog.
If this is the early-dialog from an INVITE transaction then key
question
is what is the validity of a provisional response in creating a
dialog.
Is it early or established. While the provisional response is clearly
just that from a transaction perspective in this situation the meaning
of the proposed 199 provisional response is now transaction affecting
and not dialog affecting, i.e. the INVITE usage will not become
established although the other usage may be established.
The existing state models in sip only discuss dialogs and transactions
and have not considered the dialog usage. When you send a reliable
provisional response to an INVITE you are in effect creating an
early-dialog usage. If this is the only dialog usage on the dialog you
have also created an early-dialog. If there is another usage on the
same
dialog then the dialog state will depend upon the state of the other
dialog.
RFC5057, Multiple Dialog Usage (informational) does not discuss the
details involved in multiple usages and the impact on the sip state
models but I hope that this was a consideration when the initial
drafts
were prepared.
I am unsure if the concept of multiple usages on an early dialog was
ever considered when RFC5057 was in draft stage. The nuances of
multiple
dialogs on an established dialog appears to have been enough to
suggest
that the RFC specifically not recommend multiple usages without
getting
into the 'dark area' of early dialogs and multiple usages.
Whether it make sense to use a REFER or SUBSCRIBE inside an early
dialog
is problematic. I am unsure whether these do make any sense. Would you
want to subscribe to specific event which occurs during the early
dialog
phase of an INVITE transaction? Would you want to use REFER to
perform a
transfer of a ringing call and does the protocol actually support
this?
If the answer to these questions is a definitive 'NO' then the issue
will have resolves itself. I fear however that there is no definitive
answer at this time.
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
[EMAIL PROTECTED]
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: 05 August 2008 15:21
To: Christer Holmberg
Cc: SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt
Christer Holmberg wrote:
Hi,
7) Section 7: "A UAC that receives a 199 response for an early
dialog
MUST NOT
send any further requests on that dialog...". Can you point to any
list discussion
around this requirement? I think there's some danger to consider
there. At the
very least we need to make this statement multiple-usage safe.
This is a very good catch. This needs to be aligned with
dialogusage.
If the 199 contained the final response that triggered it, then that
final response could be used to determine the impact
on the dialog or dialog usage or just the transaction. But if the
199
doesn't contain the final response, then this is a problem.
I forgot to bring this issue up in Dublin. Sorry for that.
First, we need to remember that the UAS may terminate every
dialogusage
when sending the final response (depending on what final response is
sent), without the UAC knowing it. And, due to the forking rules, the
final response which is sent to the UAC may not even be the same
which
was sent by the UAS, if a final response from another UAS is chosen
as
the "best".
Second, we need to remember that this only affects early-
dialogusages.
If needed, I guess we could include the final response which
triggered
the 199, but we could also simply say that if the UAC does not know
to
which dialogusage (if there are many) the 199 applies, it should not
do
anything which may affect other usages for the same early dialog.
The establishment of multiple early dialog usages is a pretty strange
thing. Do we know of any use cases for this? (E.g. an in-dialog
REFER on
an early INVITE. Is that legal?)
Assuming it can arise, then I agree it is reasonable to treat the
199 as
affecting only its dialog usage unless there is info with it (such as
the actual final response code) that gives evidence that the whole
dialog is gone.
Thanks,
Paul
_______________________________________________
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
_______________________________________________
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
