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