Subject: [Simple] MSRP: Connection Issue and proposal

From: Ben Campbell <[email-masked]>
Date: 02 Jun 2003 12:43:17 -0500

The last issue we discussed on MSRP in Ottowa concerned the connection
setup mechanism. The background is, when an MSRP endpoint receives an
offer containing "both", it does not immediately try to both host and
visit, like comedia endpoints do. Rather, it first attempts to act as a
visitor, then if that fails, it SHOULD attempt to host. This means that
an SDP _answer_ will _never_ contain a direction attribute of "both".

It was mentioned in the meeting that it can take some time for the
connection attempt to timeout. In the situation where the answerer
cannot open a connection to the host, it could conceivably take a small
number of minutes before it falls back to act as a host. This would not
be a very good user experience.

A second issue that Jonathan brought up is forking. If an INVITE forks,
you could end up with multiple visitors legitimately trying to connect
to the host. The current draft only allows one connection for any given
session. The first visit will always win, and any others will be
rejected. We could allow multiple connections to be associated with the
session, but that would add a great deal of complexity and additional
security concerns.

One idea (hereby designated as option 1) that was mentioned to me is
that we could solve both of these issues by simply changing the process
so that the visitor always hosts. However, this greatly reduces the
flexibility dealing with firewall issues, and would probably greatly
reduce the chance for any two endpoints to be able to talk.

Another option (hereby designated option 2) is twofold:

a) Follow the existing process for the answerer when it receives an
offer containg "both", with an additional statement that the answerer
SHOULD time-out the connection attempt after some fairly small
value--say 10 seconds.

b) Keep the current behavior when a fork occurs. The first connection
wins. Any subsequent connections will get an error response as
documented in the draft. Answerers that receive that response MUST fail
the offer. Adam pointed out that doing anything else is not particularly
useful, because any proxy that forks the request will probably CANCEL
any outstanding transactions after receiving the first 200 response, so
there is no way to reliably use the forking mechanism to set up multiple
session connections anyway.

I propose we go with option 2, as it gives us the most flexibility
without adding a great deal of complexity.

Thoughts?

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2003 18:43:40 -0400

I think option 2 sounds pretty reasonable with some provisos:

- 10 seconds can be an eternity in some call flows, especially if you 
are sending a reinvite that attempts to add IM as a new media stream to 
an existing call. Often call flows must assume reinvites will complete 
immediately.

- maybe there is a way to control the timeout. Perhaps the Expires 
header on the INVITE might set an upper limit on the time to wait.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2003 18:43:40 -0400

Paul

---

From: Ben Campbell <[email-masked]>
Date: 03 Jun 2003 23:12:23 -0500

> an existing call. Often call flows must assume reinvites will complete 

I did not necessarily mean for 10 seconds to be the final answer--I just
tossed out a number. But keep in mind, we are talking about primarily
text messaging here. 10 seconds is well withing normal conversational
latency when people are typing.

> header on the INVITE might set an upper limit on the time to wait.

Interesting idea. That would not fit with the normal usage of Expires on
invite, but it might make sense to add something to the sdp for this.
Perhaps an additional parameter on the direction attribute?

---

From: Ben Campbell <[email-masked]>
Date: 03 Jun 2003 23:12:23 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2003 09:28:22 -0400

> latency when people are typing.

I realize that. But that assumes this time is masked by conversational 
latency, and that it is a human that is waiting. I have in mind a case 
where a reinvite is sent, adding IM to a preexisting call. The question 
is whether it is acceptable to have a reinvite take a long time. I know 
there have been discussions about this, with the conclusion that 
reinvite should never take long human-interaction scale times.

This was primarily because there are call flows using reinvite in a 3pcc 
environment that won't work under those circumstances - e.g. because 
they are spliced between a 200 OK and an ACK of another call. This is a 
borderline case if we are talking about 10 seconds. And in any case it 
may be that there should be exceptions to the rule that reinvites must 
be fast. I don't think this was ever formalized anywhere.

> Perhaps an additional parameter on the direction attribute?

Why doesn't it fit with the normal use of Expires on INVITE? Doesn't it 
normally mean to give up if you can't complete the call in that amount 
of time? Here, if you were to wait longer you would be expected to fail 
the call. So instead you let the call proceed by letting the other end 
attempt a connection. But I suppose you would have to do this a bit 
before the expiration time in order to give the call time to succeed the 
other way. Perhaps *half* the expiration time should be an upper limit 
on how long to wait.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2003 09:28:22 -0400

Paul

---

From: Ben Campbell <[email-masked]>
Date: 04 Jun 2003 09:08:21 -0500

On Wed, 2003-06-04 at 08:28, Paul Kyzivat wrote:
> of time? 

Yes, but we are not talking about giving up on the invite. We are
talking about changing the mode of the call.

> Here, if you were to wait longer you would be expected to fail 

The other issue is, so far, the draft only depends normatively on SDP,
not SIP.

---

From: Ben Campbell <[email-masked]>
Date: 04 Jun 2003 09:08:21 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2003 18:06:52 -0400

> talking about changing the mode of the call.

If you wait longer than the expiration time on the invite, then the 
invite will fail. So it makes sense to stop waiting before then if there 
is then a way that the call can succeed. There are actually two ways the 
call can succeed:

- simply give up on this medium - refuse the m-line but accept the invite.

- return an answer with direction:both and let the other side try to 
connect.

> The other issue is, so far, the draft only depends normatively on SDP,

Isn't it also dependent on 3264 (offer/answer)?

In any case, this more or less convinces me. Your suggestion of an SDP 
parameter is attractive here.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2003 18:06:52 -0400

Paul