Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 14:06:44 +0200

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.

>>12) The open issue in section 10 (can we get a proxy involved in 
>>sending its own 199 reliably) is a big part of the confusion I pointed
to at 
>>the beginning of these comments. This is the part of the draft that I
expected 
>>needing face time in Dublin, but maybe we can make enough progress on
it in the 
>>hallway.
>>I don't think there's any way to allow it, and what we'll need instead
is text
>>more strongly recommending the endpoints do this themselves and 
>>restrict any proxy genesis of 199s to the unreliable case (and explain

>>more that this is just a transitionary optimization - we _really_ want
the 
>>endpoints doing this work if anything's going to be doing it at all.
>
>If the "proxy" wants to send a reliable 199, then I think it needs to
do so on its own dialog. But that makes no sense. Having the proxy
attempt to send the reliable response on the dialog 
>belonging to the UAS is *insane*.

Let's discuss this in the "open issues" thread.

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 14:54:52 +0200

Hi Robert,

In this reply I will try to address all issues except the ones related
to proxies-sending-reliably-199, which is dealt with in another thread.

>1) The header says intended status is Informational? You mean PS,
right?

I guess so.

>3) In section 6 you talk of a non-2xx final response terminating one or
more early
>     dialogs. Can you give me an example scenario where "more" comes
into play?
>     (preferably add one to the text)? I'm having a hard time seeing
how this ever more
>      than one.

What I mean to say is that when the UAC receives a final response for an
early dialog it normally releases all other early dialogs (the UAC
should of course still be ready to accept 200 OK responses for other
dialogs).

>4) Section 6 says the proxy MUST send a 199 when it receives on of
these non-2xx
>      final responses. Why is this MUST and not MAY?
>      There's no Require header here. We can have motivational text
saying why
>      proxies might really want to, but saying MUST or even SHOULD
seems wrong
>      from a protocol requirement point of view.

The idea is that if the proxy supports the 199, it must send it.

>5) With respect to that same requirement - it looks right now like
you're requiring
>      the proxy to 199 this to-tag even if the UAS that generated it
already did and the
>      proxy already forwarded that 199 even.

I can add text saying that if the proxy is aware that a 199 has already
been sent for a particular dialog, it shall not send a 199.

>6) Section 6 paragraph one's "MAY release resources" might be
misconstrued to
>      imply releasing the transaction state, which is NOT what you
mean. I'll propose
>      text to help try to avoid that later.

I guess we can add text saying that the transaction state must be
maintained as defined in 3261. Feel free to propose text :)

>8) The last paragraph of section 7 uses MUST NOT and MUST where it
really
>      should be using does not and is. This paragraph describes things
that are
>      rather than mandate behavior.

I'll have a look.

>9) Section 8 second open issue: We agreed that we were not addressing
HERFP
>      with this draft. If we are going to open this mechanism up to
something that
>      even _partially_ starts to address HERFP (by, as proposed,
including the
>      non-2xx response that caused the 199), then we need to stop work
on this
>      draft and go work on HERFP. In other words, my vode for the
answer to this
>      open issue is "NO".

Based on the agreement in Dublin I intend to remove it.

>10) Section 8 first open issue: This looks, at best, to be an
optimization of an
>        optimization. Considered in the light of having multiple
proxies on the
>        response path that would have to do extra parsing work because
of this
>        optimization, I don't think we should consider it further.

Ok.

>11) I can't follow the second paragraph of section 9 at all. Can you
rephrase it?
>       Once I know what its trying to say, I'll propose alternate text.

What it is supposed to say is that you cannot send a 199 if you are
required (by the offer/answer rules) to include SDP.

>13) The security considerations section is TBD.
>        There's a lot to talk through here. For instance, I can spoof
199s to affect how a call
>        is ultimately answered in ways that are different (from the
endpoints visibility into
>        what happened point-of-view) from cancels/byes or even other
response manipulation.

I agree we need to deal with the security considerations. I was hoping
we could get rid of some of the open issues first.

Thank you very much for your comments!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 10:10:15 -0400

> required (by the offer/answer rules) to include SDP.

Thinking about this further...

This means that a proxy must track the o/a state of the dialog usage in 
order to know whether it can send a 199 or not. That could be a 
considerable burden. It requires maintaining partial dialog state rather 
than simply transaction state, and also requires more parsing of 
messages and potentially message bodies. (E.g. with multipart.)

This has me again questioning the cost/benefit tradeoff of the whole 
thing. Of course in this case the cost is to the proxy, and the benefit 
is to the UAC.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 10:16:00 -0400

The following in the discussion of 199 issues reminded me of a question 
I have had for a long time. I'm changing the subject because it isn't 
directly pertinent to the 199 discussion.

> should of course still be ready to accept 200 OK responses for other

This has always been a fuzzy area to me. If the UAC is prepared to 
retain multiple final dialogs if they happen, is it still expected to 
release early dialog state for other dialogs when it receives the first 
2xx? That could mean that subsequent 2xx responses can't be turned into 
viable dialogs because state has been lost. (E.g. if preconditions were 
being negotiated during the early dialog.)

Shouldn't the rule be that *if* the UAC is only intending to retain the 
first final dialog then it should/may abandon all other early dialogs 
when it receives a 2xx, but if it might want to keep additional dialogs 
if additional 2xx responses are received, then it ought not drop the 
early dialogs?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 10:20:57 -0400

> 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

---

From: Bob Penfield <[email-masked]>
Date: Tue, 5 Aug 2008 10:34:17 -0400

I would say no, since 3261 has a specific guidance for this case:

   The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated.  Once the INVITE transaction is considered completed by
   the UAC core, no more new 2xx responses are expected to arrive.

Thus the other early dialogs will linger for 64*T1 seconds.

If the UAC does destroy all the other early dialogs, then it would need to be able to handle any additional 2xx responses for unknown dialogs, presumably by sending an ACK immediately followed by a BYE. This is really the same case as an additional 2xx response arriving for a brand new dialog (i.e. the UAC never received a 1xx).

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, August 05, 2008 10:16 AM
To: Christer Holmberg
Cc: SIP IETF
Subject: [Sip] Should early dialogs be dropped when 2xx is received???

        Thanks,
        Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 5 Aug 2008 11:41:47 -0400

>Thus the other early dialogs will linger for 64*T1 seconds.

Right, this is true if the UAC wants to have multiple final dialogs.

If it does not, then I do not think the UAC has to wait for 64*T1
seconds. It can terminate early dialogs by sending a BYE with
appropriate to-tag corresponding to the early dialog leg, that it wants
to terminate.

Sanjay

>
>If the UAC does destroy all the other early dialogs, then it 
>would need to be able to handle any additional 2xx responses 
>for unknown dialogs, presumably by sending an ACK immediately 
>followed by a BYE. This is really the same case as an 
>additional 2xx response arriving for a brand new dialog (i.e. 
>the UAC never received a 1xx).
>
>cheers,
>(-:bob
>
>The following in the discussion of 199 issues reminded me of a 
>question I have had for a long time. I'm changing the subject 
>because it isn't directly pertinent to the 199 discussion.
>
>Christer Holmberg wrote:
>
>> What I mean to say is that when the UAC receives a final 
>response for 
>> an early dialog it normally releases all other early dialogs 
>(the UAC 
>This has always been a fuzzy area to me. If the UAC is 
>prepared to retain multiple final dialogs if they happen, is 
>it still expected to release early dialog state for other 
>dialogs when it receives the first 2xx? That could mean that 
>subsequent 2xx responses can't be turned into viable dialogs 
>because state has been lost. (E.g. if preconditions were being 
>negotiated during the early dialog.)
>
>Shouldn't the rule be that *if* the UAC is only intending to 
>retain the first final dialog then it should/may abandon all 
>other early dialogs when it receives a 2xx, but if it might 
>want to keep additional dialogs if additional 2xx responses 
>are received, then it ought not drop the early dialogs?
>
>        Thanks,
>        Paul
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip 
>Use [email-masked] for new developments on the application 
>of sip _______________________________________________
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 19:31:17 +0200

Hi,

>thing. Of course in this case the cost is to the proxy, and the benefit 

I guess we could simply say never to insert an SDP body in the 199 response. I don't think it would make much harm, since the dialog is terminated in any case.

And, this could only happen when/if 199 is sent reliably, since unreliable provisional responses can't carry offer/answers in the first place...

Regards,

Christer

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 19:54:39 +0200

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
>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.
> 

>an early INVITE. Is that legal?)

Don't know... Does the dialogusage spec talk about early dialogs?

>the actual final response code) that gives evidence that the whole 

I agree, and I can put some text about that.

Because, even if the 199 response did affect the whole dialog, the UAC should find out about it once  the forking proxy sends a final response.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 08:14:25 +0200

Hi, 

>>after the reception of the first 2xx response.  At this point all 
>>the early dialogs that have not transitioned to established dialogs
are
seconds. It can terminate early dialogs by sending a BYE with
appropriate to-tag corresponding to the early dialog leg, that it 
>wants to terminate.

Correct. Or, it could keep enough state in order to send ACK+BYE if/when
it receives additional 200 OK responses (which I think is going to be
quite rare in the first place).

Regards,

Christer

>If the UAC does destroy all the other early dialogs, then it would need

>to be able to handle any additional 2xx responses for unknown dialogs, 
>presumably by sending an ACK immediately followed by a BYE. This is 
>really the same case as an additional 2xx response arriving for a brand

>new dialog (i.e.

>[email-masked] for questions on current sip Use 
>[email-masked] for new developments on the application of sip 
>[email-masked] for questions on current sip Use 
>[email-masked] for new developments on the application of sip
>

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 6 Aug 2008 13:09:46 +0200

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-masked]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 05 August 2008 15:21
To: Christer Holmberg
Cc: SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2008 08:25:24 -0400

> 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.

> dialog then the dialog state will depend upon the state of the other

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.

> will have resolves itself. I fear however that there is no definitive

Right.

	Paul

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 6 Aug 2008 15:51:15 +0200

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)

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
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

combination.

Right.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 15:57:45 +0200

Hi,

I've changed the name of this thread, because I think the scope is wider
than 199 :)

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,

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
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

combination.

Right.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2008 11:21:10 -0400

> I've changed the name of this thread, because I think the scope is wider

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.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 20:17:00 +0200

Hi,

>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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2008 18:11:32 -0400

> 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…

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…

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.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 Aug 2008 07:41:37 +0200

Hi, 

>>>>I've changed the name of this thread, because I think the scope is
wider than 199 :)
>>>invite-dialog-usage can be early, and you can only have one of those 
>>>per dialog.
>>>

>>>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.
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

>> We cannot criticize RFC 3261 for this as when it was written INVITE 
>> was the ONLY dialog creating transaction.
>>
>> 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)
>>
>>> On an INVITE transaction can create an early dialog. The other 
>>> dialog creating transactions REFER and SUBSCRIBE, can only create 
>>> established dialogs.
>>>
>>> If you send a REFER or SUBSCRIBE method on an early dialog and you 
>>> get an acceptance response then you have an established dialog.

>> usage as a side effect of processing the 199 on the early invite 
>> dialog usage.
>>
>>> 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

>> terms of dialog usages rather than dialogs. Maybe that is a job for 
>> the draft standard version of 3261.
>>

>>> 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

>>> 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)
>>>
>>>> If the 199 contained the final response that triggered it, then 
>>>> that final response could be used to determine the impact
>>>> 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
>>>> which dialogusage (if there are many) the 199 applies, it should 
>>>> not
>>> do
>>> 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
>>> 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
>>>
>>>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Aug 2008 12:33:04 +0200

Hi,

I was thinking a little more about the offer/answer impact.

And, I am not sure this is an 199 issue after all. 

The only time a reliable provisional response is currently mandated to
carry SDP is the follwing: the INVITE didn't contain SDP offer, in which
case the FIRST reliable non-error response (provisional or final) must
contain and SDP offer (that is a rule which we have even questioned, but
that's another topic). 

However, 199 will NEVER be the first response sent, since at least one
18x must have been sent prior in order to establish the early dialog.

So, unless I have missed something I intend to say a few words about
that in the draft and close the open issue.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: 5. elokuuta 2008 20:31
To: Paul Kyzivat
Cc: SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt -
offer/answerimpact

Hi,

>considerable burden. It requires maintaining partial dialog state 
>rather than simply transaction state, and also requires more parsing of

>is to the UAC.

I guess we could simply say never to insert an SDP body in the 199
response. I don't think it would make much harm, since the dialog is
terminated in any case.

And, this could only happen when/if 199 is sent reliably, since
unreliable provisional responses can't carry offer/answers in the first
place...

Regards,

Christer

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Aug 2008 08:51:27 -0400

OK Christer - I accept your logic here.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Aug 2008 16:18:40 -0500

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:

> perform a
> 199 as

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 18 Aug 2008 16:50:02 +0200

Robert,

The work relating to multiple dialog usages may in time remove the
requirement to have multiple usages on the same dialog. Due to the
issues relating to B2BUAs which were briefly discussed in
draft-marjou-sipping-b2bua-01 and the mapping of the dialog reference
headers (Replaces, Target-dialog, Join and In-Reply-To) through B2BUAs I
don't believe that we can totally remove multiple dialog usages until
this handling is resolved.

The rejection of the sipping wg of this draft from forming part of the
charter will result in the deployment of solutions using multiple dialog
usages as use of an existing dialog will be the only way to ensure
routing of requests where reference to an existing dialog is required,
e.g. your example of subscribing to the dialog event package.

The current problem is that the existing sip specification does not take
account of multiple dialog usages and there are deployments which cannot
successfully handle this case. To change the sip model to account for
multiple usages is not in itself difficult but to make it backward
compatible with existing implementation is the major challenge.

As my major focus is IMS the use of B2BUA is pretty much a given. The
issue with routing when the dialog reference headers are used needs to
be resolved before it is possible to send requests on new dialog. In the
current situation there is no option except to use multiple dialogs with
all the issues that these create.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 15 August 2008 22:19
To: Ian Elz
Cc: Paul Kyzivat; Christer Holmberg; SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2008 11:02:02 -0400

> all the issues that these create.

Ian,

I think much of the responsibility here belongs with IMS rather than 
IETF. The B2BUAs specified by IMS *could* manage contacts so as to 
preserve the gruu property. I have helped write language for IMS that 
does so. I don't know whether that was adopted or not. But if not, then 
the ball is clearly in the IMS court.

	Thanks,
	Paul

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 18 Aug 2008 17:58:46 +0200

Paul,

I have changes the subject as this is getting too far from 199.

There are issues in this area relating to how the request containing the
dialog reference header is routed.

If there are multiple B2BUA in the message path of the original dialog
then the new request which refers to this dialog must be routed to each
of these B2BUA in the correct order to ensure that the dialog identity
parameters can be correctly mapped.

To ensure that this routing is performed in the correct order then there
are two options:

1. have each B2BUA map the contact header and when a new request is
created use the received contact header used as the Request URI for the
new request. This results in an end-to-end gruu being meaningless as it
must be mapped out by each B2BUA

2. have the UA which creates the request or response includes itself in
the Record-Route header so that the route will specify the UAC/UAS of
the B2BUA. This would allow the contact to be not mapped by the B2BUA as
all routing would be from the Route header.

There are other issues involved with the IMS as the initial routing of
an initial or standalone request uses a preset route towards the P-CSCF
which will then invoke the S-CSCF which use the iFC to find the
appropriate Application Servers. It is only after this initial preset
routing has occurred can the routing to the B2BUAs which have mapped the
dialog identifying parameters from the original dialog. This effectively
rules out the second option above as there is no means of passing the
route set as defined buy the original dialog.

My examination of this area has concluded the following:

1. The Call-Id must be mapped by B2BUA as this is required to be unique
for each dialog (RFC 3261). If this is not mapped then the handling
element is not a B2BUA as currently defined in RFC 3261, a concatenation
of a UAC and UAS.

2. As the Call-Id must be mapped across the B2BUA there are separate
dialogs on each side of the B2BUA and when a dialog reference header is
used it must be mapped by the same B2BUAs as mapped the dialogs in the
original dialog and in the same order. If this mapping does not happen
correctly then the dialog will not be recognized.

3. The Contact header must be mapped by the B2BUA so that a request
which uses the dialog reference headers can be correctly routed to each
mapping B2BUA in turn to ensure that dialog identity in the dialog
reference header and the Contact are correctly mapped. 

4. The Request containing the dialog reference header must use the
Contact received in the reference dialog as the R-URI in the new dialog.

While the use of an end-to-end gruu may appear to be of benefit any
Requests using this as the R-URI and containing a target dialog header
will fail where the referenced identity was mapped by a B2BUA as the
mapped dialog identity will not be recognized at the far end. 

Even if the original dialog identity was also passed from end-to-end in
the original dialog and used in the subsequent dialog then from an IMS
perspective this may result in the new Request being passed completely
outside the scope of the IMS which may then bypass the whole IMS and its
security mechanisms. 

There may be ways to redefine the B2BUA in sip so that mapping of any of
the dialog identifying parameters, Call-Id, to and from tags, but this
may leave a large number of legacy B2BUA which will not comply to the
new definitions. 

I have just checked 3GPP TS24.229 v8.4.1 (latest version) and while it
specifies mapping of the Replaces header in the AS there is no
requirement to also map the Contact to the Contact received in the
dialog being replaced. There is no mention of Target-Dialog in the
specification at all so there is no way to remove multiple dialog
usages. Replaces and Join are listed in the Profiles but there is no
specific routing to indicate how initial requests using these headers
are routed to the AS so that the mapping can occur. While Join is
mentioned in the Profiles there is no requirement to map the Join
parameter across a routing B2BUA.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 18 August 2008 16:02
To: Ian Elz
Cc: Robert Sparks; SIP IETF; Christer Holmberg
Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt

Ian,

	Thanks,
	Paul