[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Multiple early-dialog usages [was RE: Comments on draft-ietf-sip-199-00.txt]
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 From sip-bounces at ietf.org Wed Aug 6 22:41:28 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5DCFB3A690E;
Wed, 6 Aug 2008 22:41:28 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 7374A3A690E
for <sip at core3.amsl.com>; Wed, 6 Aug 2008 22:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.283
X-Spam-Level:
X-Spam-Status: No, score=-7.283 tagged_above=-999 required=5 tests=[AWL=0.966,
BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_SE=0.35,
RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jJ0rbQ3Zt0Ht for <sip at core3.amsl.com>;
Wed, 6 Aug 2008 22:41:24 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
by core3.amsl.com (Postfix) with ESMTP id 6EC883A6808
for <sip at ietf.org>; Wed, 6 Aug 2008 22:41:24 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
CEC0C213F5; Thu, 7 Aug 2008 07:41:38 +0200 (CEST)
X-AuditID: c1b4fb3e-a8e85bb000007a96-67-489a8b12531b
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
A6D1F213F1; Thu, 7 Aug 2008 07:41:38 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Thu, 7 Aug 2008 07:41:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 7 Aug 2008 07:41:37 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF07549019 at esealmw113.eemea.ericsson.se>
In-Reply-To: <489A2194.10005 at cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Multiple early-dialog usages [was RE: Comments
on draft-ietf-sip-199-00.txt]
thread-index: Acj4EUWPmZkFFnAERAeAnIiy6k15bQAPc3qQ
References: <88EAF47F-A9BE-4A8D-A849-41659EB90D12 at nostrum.com><48862EFF.3000908 at cisco.com><CA9998CD4A020D418654FCDEF4E707DF0750A4EC at esealmw113.eemea.ericsson.se> <489861C9.2020507 at cisco.com> <C0E80510684FE94DBDE3A4AF6B968D2D03D87ED4 at esealmw118.eemea.ericsson.se> <48999834.4080304 at cisco.com> <C0E80510684FE94DBDE3A4AF6B968D2D03DBB10D at esealmw118.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF07548A9B at esealmw113.eemea.ericsson.se> <4899C166.70109 at cisco.com>
<CA9998CD4A020D418654FCDEF4E707DF046C78D0 at esealmw113.eemea.ericsson.se>
<489A2194.10005 at cisco.com>
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
To: "Paul Kyzivat" <pkyzivat at cisco.com>
X-OriginalArrivalTime: 07 Aug 2008 05:41:38.0411 (UTC)
FILETIME=[42EF4BB0:01C8F850]
X-Brightmail-Tracker: AAAAAA==
Cc: SIP IETF <sip at ietf.org>, Ian Elz <ian.elz at ericsson.com>
Subject: Re: [Sip] Multiple early-dialog usages [was RE: Comments
on draft-ietf-sip-199-00.txt]
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 havonly 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.
>>
>>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...
>
>Agreed. I think the most likely way to get into the situation is to
send a SUBSCRIBE, or more likely a REFER, within a dialog resulting from
an early invite dialog usage. The REFER case may
>actually be plausible.
>
>>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.
>
>I can't think of a likely use for SUBSCRIBE.
>
>>And, because of all issues described in RFC 5057, I hope people won't
define such use-case in future either.
>
>If we can find no deployed usages, we might take the opportunity to
simply ban them.
Yes. Something for the fix-the-bugs documentation work the WG has been
discussing?
Also, when we now have decided to start working on the info packages,
people will have a choise to use those instead for early in-dialog cases
(and in-dialog cases in general).
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
>> ian.elz at ericsson.com
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>> 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'.
>e 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.
>>
>>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...
>
>Agreed. I think the most likely way to get into the situation is to
send a SUBSCRIBE, or more likely a REFER, within a dialog resulting from
an early invite dialog usage. The REFER case may
>actually be plausible.
>
>>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.
>
>I can't think of a likely use for SUBSCRIBE.
>
>>And, because of all issues described in RFC 5057, I hope people won't
define such use-case in future either.
>
>If we can find no deployed usages, we might take the opportunity to
simply ban them.
Yes. Something for the fix-the-bugs documentation work the WG has been
discussing?
Also, when we now have decided to start working on the info packages,
people will have a choise to use those instead for early in-dialog cases
(and in-dialog cases in general).
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
>> ian.elz at ericsson.com
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>> 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'.
>>>
>>> O>>
>>> 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
>>> ian.elz at ericsson.com
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>>> 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 dn 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
>>> ian.elz at ericsson.com
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>>> 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 discussioiscussion
>>>>>> 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
n
>>>>>> 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip