Hi,
>>I've changed the name of this thread, because I think the scope is wider
>>than 199 :)
>
>Perhaps. But I don't think there is much to discuss.
>
>It seems clear that we don't have any way to cause a dialog with
>*multiple* *early* dialog usages. This is because only an
>invite-dialog-usage can be early, and you can only have one of those per
>dialog.
>
>It seems technically possible to have a dialog that has both an early
>dialog usage and a final dialog usage. There may be question of whether
>there is practical value in this, but for now I will simply assume it is
>possible. We can discuss if it might not be possible, or if it should be
>declared so, but I don't know if we need to.
>
>RFC 5057 addresses the impact of responses on the state of transactions,
>dialog usages, and dialogs. The interesting question is whether the
>proposed 199 response would require some alteration to 5057. The reason
>its interesting is because the 199 is effectively a final response in
>disguise. But that brings it back to something that ought to be
>discussed on the 199 thread.
So, from a 199 point of view I guess the only thing we can do at the moment is
to provide some text and say that care shall be taken when multiple
dialogusages exist, and the 199 doesn't provide more information.
I think it is extremely rare that one would first establish a subscription
dialog, and then send an INVITE and create an early invite usage within that
dialog. I would even dare to say that no such implementations exist today, but
I can of course be wrong...
As imentioned earlier, I also think it's not a good idea to create subscription
usages within an early INVITE dialog. In case of forking you may send SUBSCRIBE
to all UASes, and when some sends 200 OK for the INVITE you may have to
unsubscribe to all the other UASes. etc etc.
And, because of all issues described in RFC 5057, I hope people won't define
such use-case in future either.
Regards,
Christer
>
>
>
> -----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
>>
>>
>
_______________________________________________
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
