-----Original Message-----
From: Ian Elz
Sent: 6. elokuuta 2008 16:51
To: Paul Kyzivat
Cc: Christer Holmberg; SIP IETF
Subject: RE: [Sip] Comments on draft-ietf-sip-199-00.txt
Paul,
I only included 'early dialog' as this is the term that is already used.
We cannot criticize RFC 3261 for this as when it was written INVITE was
the ONLY dialog creating transaction.
Should some input be given to Robert Sparks' invfix draft as it is
proposing corrections to the INVITE transaction state machines.
Based on the existing draft (-02) sending or receiving a 1xx response
places the transaction in the 'proceeding' state which is does not exit
until a final response has been sent or received, or I assume the
dialog/usage terminates.
If we retain the state model of proposed in invfix then the 199 response
should be treated as an invitation to the UAC to terminate the early
dialog usage with a BYE method. If this does not happen the transaction
will remain as 'proceeding' and the early dialog usage may also remain.
The alternative is to modify the proposed transaction state models for
special handling for the 199 response. This is something which I am not
sure that I would favour.
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: 06 August 2008 13:25
To: Ian Elz
Cc: Christer Holmberg; SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt
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.
Agreed. I should have pointed that out.
However, the issue arises if you can get an early invite dialog usage
with a confirmed dialog usage. In that case one must be careful with the
rules to ensure that you don't accidentally terminate the confirmed
usage as a side effect of processing the 199 on the early invite dialog
usage.
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.
IMO there really shouldn't be any "early dialog", ever. The dialog comes
into existence, and departs, based on the existence of at least one
usage. The dialog is the same whether the usages are early or late, or a
combination.
I agree that it would be helpful to recast all the state machines in
terms of dialog usages rather than dialogs. Maybe that is a job for the
draft standard version of 3261.
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.
Right.
Paul
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
