Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-04.txt

From: [email-masked]
Date: Mon, 18 Aug 2003 11:14:54 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: The Session Inititation Protocol (SIP) 'Replaces' 
                          Header
	Author(s)	: B. Biggs, R. Dean, R. Mahy
	Filename	: draft-ietf-sip-replaces-04.txt
	Pages		: 18
	Date		: 2003-8-18
	
This document defines a new header for use with SIP multi-party
applications and call control. The Replaces header is used to
logically replace an existing SIP dialog with a new SIP dialog.  This
primitive can be used to enable a variety of features, for example:
'Attended Transfer' and 'Call Pickup'. Note that definition of these
example features is non-normative.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-replaces-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-replaces-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2003 12:52:57 -0400

"If the UA cannot accept the new INVITE (for example: it cannot
    establish required QoS or keying, or it has incompatible media), the
    UA MUST return an appropriate error response and MUST leave the
    matched dialog unchanged."

Exactly what is the meaning of "incompatible media" in the above?

In general, when an INVITE arrives containing an offer, the recipient 
may accept the INVITE while rejecting some or all of the media, up to 
and including ending up with a call containing no media. If it is ok to 
accept a call while rejecting all the media then there is no such thing 
as a call with incompatible media.

I fear that we will begin to have interop problems if some UAs accept 
calls under this kind of situation, while others reject them.

	Paul

_______________________________________________
Sip mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Aug 2003 13:24:02 -0400

Here is another point that I find fuzzy, in Section 3:

   "If the Replaces header field matches an early dialog that was not
    initiated by this UA, it returns a 481 (Call/Transaction Does Not
    Exist) response to the new INVITE, and leaves the matched dialog
    unchanged. Note that since Replaces matches only a single dialog, the
    replacement dialog will not be retargeted according to the same
    forking logic as the original request which created the early
    dialog.
    (Currently no use cases have been identified for replacing just a
    single dialog in this circumstance.)"

I don't know how to interpret this. Suppose X sent an invite to Y, and Y 
returned a 183 establishing an early dialog. I think you are saying that 
an INVITE/Replaces referencing this dialog should be rejected if 
received by one of these UAs, but which one?

(X initiated the invitation which resulted in the dialog, but Y sent the 
response with a To-tag that actually initiated the specific dialog.)

In example 7.1 Alice, who is in the role of X above, answers the 
invite/replaces. This implies that you intend to have the party in role 
Y refuse the replacement.

But in Section 4 I see:

    For example, if Alice replaces Cathy in an early dialog with Bob, but
    he does not answer, Alice's replacement request will not match other
    dialogs to which Bob's UA redirects, nor other branches to which his
    proxy forwards. Although this specification takes reasonable

In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must be 
by Alice sending an invite/replaces to Bob. You seem not to want this to 
fail either.

So, I am confused with what you are trying to restrict.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Aug 2003 10:26:22 -0700

Paul,

Thanks for bringing this up.  I think the draft needs to distinguish 
between these cases:

1) The UA receives an offer with no compatible media and does not wish 
to maintain a session with no associated media.

2) The UA receives an offer but does not wish to send/receive media at 
the moment (possibly because it is negotiating a session using 3pcc on 
behalf of another UA).

I think the same distinction applies to UAs that receive "ordinary" 
INVITEs.  They can accept an offer but reject all the m-lines, or they 
can send a 4xx response. So...

- Do you think 3261 needs any clarification to make this distinction 
obvious?
- Can you propose some text for Replaces that makes clear my original 
intention (what you do in case 1), while still allowing for case 2?

thanks,
-rohan

On Monday, August 18, 2003, at 09:52 AM, Paul Kyzivat wrote:

> and including ending up with a call containing no media. If it is ok 
> to accept a call while rejecting all the media then there is no such 
> thing as a call with incompatible media.
>

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Aug 2003 13:05:38 -0700

On Monday, August 18, 2003, at 10:24 AM, Paul Kyzivat wrote:

> I don't know how to interpret this. Suppose X sent an invite to Y, and 
> Y returned a 183 establishing an early dialog. I think you are saying 
> that an INVITE/Replaces referencing this dialog should be rejected if 
> (X initiated the invitation which resulted in the dialog, but Y sent 
> the response with a To-tag that actually initiated the specific 
> dialog.)

No, the spec is pretty clear on this.  X initiated the dialog.  Y 
caused the dialog to become an early dialog.  If you can come up with a 
rewording which is more precise and still clear, I am happy to 
incorporate it.

> invite/replaces. This implies that you intend to have the party in 
> role Y refuse the replacement.

I don't follow you here.

> In this, Cathy is X and Bob is Y. If Alice replaces Cathy, that must 
> be by Alice sending an invite/replaces to Bob. You seem not to want 
> this to fail either.

I am not following X = Cathy, Y = Bob.  In any case, this paragraph is 
motivational explaining why you shouldn't send a Replaces header for a 
dialog you know is still in the early state, unless you are sending the 
replacement request to the initiator of the request you want to replace.

> So, I am confused with what you are trying to restrict.

Y cannot accept an INVITE with Replaces for the early dialog between X 
and Y.

is that clear?

thanks,.
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2003 19:08:40 -0400

Rohan Mahy wrote:
>> the response with a To-tag that actually initiated the specific dialog.)
> 
> 
> No, the spec is pretty clear on this.  X initiated the dialog.  Y caused 
> the dialog to become an early dialog.  If you can come up with a 

Based on your clarifications below, maybe the wording is ok as long as 
wording elsewhere that hints at another meaning is fixed.

>> role Y refuse the replacement.

I'm just applying logic to the example. Alice is in role X because she 
sent the invite. Alice also answers the invite/replaces. According to 
your rule, she would have had to refuse it if she was not the initiator 
of the dialog. So she must be the initiator of the dialog. So in my 
terms role X is the dialog initiator and hence role Y is not the dialog 
initiator.

Hence I agree that this example is consistent with what you say below, 
that Y cannot accept the invite/replaces.

> I am not following X = Cathy, Y = Bob. 

Here is logic:

- "... Cathy in an early dialog with Bob"

=> Cathy sent INVITE to Bob, OR Bob sent INVITE to Cathy
    AND that INVITE hasn't completed yet

- "but he does not answer"

=> the INVITE must have been from Cathy to Bob

- "Alice replaces Cathy ..."

=> Alice sends INVITE/Replaces to Bob
=> the invite/replaces exceeds (else Alice won't replace Cathy)

This means Cathy is in role X and Bob in role Y. Using either my 
terminology or yours, this is the case where the recipient of the 
invite/replaces must refuse it.

So this example seems to violate your rule.

 > In any case, this paragraph is

Well, it isn't motivational for me. :-)

Its just confusing. I now think I understand that you intend this as a 
counterexample, of what bad things could happen if the restriction were 
not in place. But as worded it isn't clear that it is an example that 
isn't possible given the restriction.

And I think it is nonsensical - what would lead Alice to do such a 
stupid thing? I'm not sure it is possible to come up with an example 
that makes much sense.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Aug 2003 17:28:14 -0700

On Tuesday, August 19, 2003, at 04:08 PM, Paul Kyzivat wrote:

>>> I don't know how to interpret this. Suppose X sent an invite to Y, 
>>> and Y returned a 183 establishing an early dialog. I think you are 
>>> saying that an INVITE/Replaces referencing this dialog should be 
>>> rejected if received by one of these UAs, but which one?
>>>
>> caused the dialog to become an early dialog.  If you can come up with 
>> a rewording which is more precise and still clear, I am happy to 
>> incorporate it.
>
> your rule, she would have had to refuse it if she was not the 
> initiator of the dialog. So she must be the initiator of the dialog. 
> So in my terms role X is the dialog initiator and hence role Y is not 
> the dialog initiator.
>
>> motivational explaining why you shouldn't send a Replaces header for 
>> a dialog you know is still in the early state, unless you are sending 
>> the replacement request to the initiator of the request you want to 
>> replace.
>
> counterexample, of what bad things could happen if the restriction 
> were not in place.

yes

> But as worded it isn't clear that it is an example that isn't possible 
> given the restriction.

bummer.  can you propose some rewording?

> stupid thing? I'm not sure it is possible to come up with an example 

you'd be *amazed*.

thx,
-r

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Aug 2003 08:31:21 -0400

> can send a 4xx response. So...

I agree that this is a general issue for invites - or perhaps more 
generally for offer/answer.

> intention (what you do in case 1), while still allowing for case 2?

I have been thinking about this problem for some time. I have an idea, 
but I have been reluctant to offer it because it seems to be overly 
complex. Nevertheless...

How about preconditions?

- In the absence of preconditions to the contrary, the assumption would 
be that the offerer is satisfied with whatever it can get, including 
nothing at all. It is up to the answerer to decide what is sufficient 
and what is not.

- some kind of new media precondition would provide the opportunity for 
the two sides to do an extended negotiation for mutually satisfactory 
media before alerting anyone. If it becomes apparent that the conditions 
cannot be met, then the invitation containing the offers and answers fails.

I haven't thought enough about this to go further and define exactly how 
the precondition would be expressed. But how does the general concept sound?

An advantage to this is that it doesn't change 3261, and is upward 
compatible with current practice.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Aug 2003 10:50:59 -0400

>>>> be by Alice sending an invite/replaces to Bob. You seem not to want 
[snip]
>> stupid thing? I'm not sure it is possible to come up with an example 

How about the following changes:

- in the second to last paragraph of section 4, modify the following:

    "If the Replaces header field
    matches an early dialog that was initiated by the UA, it accepts the
    new INVITE by sending a 200-class response, and shuts down the
    replaced dialog by sending a CANCEL."

   after "replaced dialog" insert ", any other early dialogs, and any
   other pending forks".

- in section 4, delete the following:

   "For example, if Alice replaces Cathy in an early dialog with Bob, but
    he does not answer, Alice's replacement request will not match other
    dialogs to which Bob's UA redirects, nor other branches to which his
    proxy forwards."

- add a new section 4.1:

4.1 Example of Incorrect Client Behavior

     The following is an example of an attempt to violate the rule
     against sending a replacement request to the non-initiating end
     of an early dialog.

                Bob         Bob         Bob          Bob
     Alice      Proxy       desk        home         lab
      |           |           |          |             |
      |--INVITE-->|--INVITE-->|          |             |
      |<----180---|<----180---|          |             |
      |           |--------INVITE------->|             |
      |<----180---|<---------180---------|             |
      |           |           |  Bob hears desk phone  |
      |           |           |  ringing from lab but  |
      |           |           |  isn't REGISTERed yet  |
      |           |           |                        |
      |           |           |<--fetch dialog state --|
      |           |           |---response ----------->|
      |           |           |<--INVITE/Replaces------|
      |           |           |----------481---------->|
      |<----200---|<---------200---------|             |
      |--------------ACK---------------->|             |
      |           |--CANCEL-->|          |             |
      |           |<---200----|          |             |
      |           |<---487----|          |             |
      |           |----ACK--->|          |             |

     Were this not illegal, it could result in something like
     the following:

                Bob         Bob         Bob          Bob
     Alice      Proxy       desk        home         lab
      |           |           |          |             |
      |--INVITE-->|--INVITE-->|          |             |
      |<----180---|<----180---|          |             |
      |           |--------INVITE------->|             |
      |<----180---|<---------180---------|             |
      |           |           |  Bob hears desk phone  |
      |           |           |  ringing from lab but  |
      |           |           |  isn't REGISTERed yet  |
      |           |           |                        |
      |           |           |<--fetch dialog state --|
      |           |           |---response ----------->|
      |           |           |<--INVITE/Replaces------|
      |           |           |----------180---------->|
      |           |<---4xx----|          |             |
      |           |----ACK--->|          |             |
      |<----200---|<---------200---------|             |
      |--------------ACK---------------->|             |

     In this case, Bob at his lab computer would simply listen to
     his desk phone ringing. Meanwhile, Alice's call is answered
     by someone at Bob's home. For a working example, see section 7.1.

- Note that this couterexample is still non-sensical - it is an 
erroneous attempt to achieve Bob's intent. I can't think of an a better 
case to expose the issue.

	Paul