Subject: RE: [Sip-implementors] problem indraft-ietf-mmusic-sdp-comedia-00 ?

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 11 Jun 2001 10:56:43 -0700

Hi Paul,

I think that the section you quote is unrelated to this argument. It deals
with differences between the addresses specified in the "remote" SDP and the
addresses specified in SCTP's four-way handshake. TCP does not negotiate
transport addresses and so this is not a problem in this scenario. 

Neither document places restrictions on the source address of where a
connection may be opened from (in any of the connection modes). However it
is not the source address of the connection that is the contentious issue
here. It is the fact that any endpoint of a connection taking part in the
session must be able to send _and_ receive media, in other words, you cannot
open a connection just for sending _or_ receiving media.

You option (B) is not an feasible restriction in my mind. It may not even be
possible for an application to predetermine the source address of a TCP
connection (on a multi-homed host). There are other reasons this is not a
good idea. NAT/NAPT and timing problems are just two of them.

Yes this does indeed have implications if the application's really wants to
have two unassociated send and receive processes. One solution to this
problem could be to use two separate explicitly unidirectional
(a=sendonly/a=recvonly) connections correlated using either Gonzalo
Camarillo's SDP "fid" media flow identifiers or an application-layer media
stream correlation mechanism (such as SIP's offer-answer model [bis-03]).
The benefit's for a connection-oriented and/or reliable transport mechanism
to be bidirectional at the transport layer are significant. For example,
bandwidth efficiency and ensuring bidirectional connectivity/reliability
especially w.r.t NAT/NAPT traversal, etc. 

Regards,

Robert.

-----Original Message-----
From:	Paul Kyzivat [mailto:[email-masked]]
Sent:	Monday, June 11, 2001 6:12 PM
To:	Fairlie-Cuninghame, Robert
Cc:	'David Yon'; MMUSIC
Subject:	Re: [Sip-implementors] problem
indraft-ietf-mmusic-sdp-comedia-00?

Robert - comment below.

	Paul

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi Paul,
> 
> I believe the confusion is due to the fact that comedia makes the
> assumption that when an application establishes a logical
> bidirectional "session" using two session descriptions (one for each
> side) then every TCP connection establishes a bidirectional
> communications channel between the two applications. It should be
> remembered that only one side of the TCP connection may be connected
> to a port specified in just one of the session descriptions. [It also
> assumes that both applications have knowledge of both session
> descriptions.]

I think I understand what is proposed, and I believe what you say is
consistent with that understanding. But let me attempt to state my
understanding, just in case there are differences.

The bidirectional session established using two session descriptions may
result in one or two TCP connections. Each of these connections has a
communication path in each direction, so we may have two available paths
in each direction. When there are two TCP connections, part of the
session establishment is to decide which of the two paths to use in each
direction. It may be that we choose one path from each of the two TCP
connections, or we may choose both paths from the same TCP connection.

> 
> This is in contrast to the UDP based solution where there is no
> concept of bidirectional connections (except as two unidirectional
> channel) and that each session description only describes how to
> receive media.
> 
> I tried to clarify/specify this concept more completely in my SCTP
> profile (which must also deal with these connection-based issues).
> [Especially in the rules for sending/receiving media and
> opening/closing SCTP associations.]

I haven't fully grokked your proposal yet - partly because I have no
experience with SCTP and have no compelling reason to try it yet. But I
think perhaps the following sentence from it may be relevant:

"It is up to the application to decide whether or not to accept an
association where the negotiated remote transport address set does not
match the address set in the remote session description."

This leaves open the issue of whether I should be restricted to sending
from the addresses at which I am willing to receive. But the situation
is less restrictive here because SCTP is set up to handle multiple
addresses on each end. 

It may not be true of the SCTP case, but at least in the TCP case the
looseness of this complicates implementation of either the passive side
or the active side, or both. Since most people implementing this will be
implementing both the active and passive features, this complicates life
for everybody.

Let me restate the problems:

A) if it is valid for an active endpoint to connect from an address
different than was in the c= of the SDP it offered, then a passive
endpoint will need to dedicate a listening port for the duration of an
Invite, or else risk not knowing which media stream a particular
incoming connection belongs to.

B) conversely, if it is valid for a passive endpoint to require the
address of an incoming connection to match the c= of an expected media
connection, then the implementation of the active endpoint will be
limited - it must ensure it makes the connection from the address it
advertised.

If I have to live with one or the other of these restrictions, then I
prefer B.

> 
> http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt
> 
> David, I do agree with Paul that perhaps a little more clarification
> would be helpful to explain the slight shift in paradigm from UDP.
> 
> This change is not arbitrary and is in fact quite powerful for solving
> NAT/NAPT traversal (where just one endpoint is behind the NAPT).
> 
> See also:
> 
>
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt
> Cheers,
> Robert.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jun 2001 16:02:02 -0400

See below

	Paul

> I think that the section you quote is unrelated to this argument. It
> deals with differences between the addresses specified in the "remote"
> SDP and the addresses specified in SCTP's four-way handshake. TCP does
> not negotiate transport addresses and so this is not a problem in this
> scenario.
> 
> connection may be opened from (in any of the connection modes).
> However it is not the source address of the connection that is the
> contentious issue here. It is the fact that any endpoint of a
> connection taking part in the session must be able to send _and_
> receive media, in other words, you cannot open a connection just for
> sending _or_ receiving media.
> 
> You option (B) is not an feasible restriction in my mind. It may not
> even be possible for an application to predetermine the source address
> of a TCP connection (on a multi-homed host). There are other reasons
> this is not a good idea. NAT/NAPT and timing problems are just two of
> them.

David Yon sent out a reply accepting my suggestion for an addition to
the direction attribute specifying what address to expect connection
from. In his wording, this is optional, but if not present then it is
assumed that the connection will come from the address in the c=. If it
is not possible for the application to predetermine the source address,
then it doesn't matter whether it is specified with the direction or
with the c=.

One implementation environment where it is difficult to predict either
the
address or the port is Java. Happily this is being fixed in 1.4, but it
is
a problem until that is generally in use. I don't know if there are
other
relevant implementation environments that can't preallocate the socket
resources so they can be announced in the SDP.

My problem is that *optionally* specifying the address and port that
will be used to connect isn't helpful. If I must accept calls from a UA
that doesn't do so, then I must ensure I have another way to distinguish
that connection from other connections. The only way I can see to do
that is to dedicate a listening socket for the duration of the
invitation. I find that to be *very* objectionable.

> Yes this does indeed have implications if the application's really
> wants to have two unassociated send and receive processes. One
> solution to this problem could be to use two separate explicitly
> unidirectional (a=sendonly/a=recvonly) connections correlated using
> either Gonzalo Camarillo's SDP "fid" media flow identifiers or an
> application-layer media stream correlation mechanism (such as SIP's
> offer-answer model [bis-03]). The benefit's for a connection-oriented
> and/or reliable transport mechanism to be bidirectional at the
> transport layer are significant. For example, bandwidth efficiency and
> ensuring bidirectional connectivity/reliability especially w.r.t
> NAT/NAPT traversal, etc.
> 
> Regards,
> 
> Robert.

---

From: David Yon <[email-masked]>
Date: Mon, 11 Jun 2001 16:52:09 -0400

>invitation. I find that to be *very* objectionable.

Maybe I should elaborate on what I meant by "optional" for the 
address.  It's optional only if the endpoint knows that it will be 
connecting from the same address as listed in the "c=" line.  If the 
address from which it will be connecting is *different* than what is found 
in the "c=" line, then the endpoint MUST specify that address in the 
"direction" attribute.

Does that help?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jun 2001 17:46:20 -0400

David,

Your meaning of optional was clear in your revised direction-spec.
But you mean something different in the optionality of the port.

But Robert F-C is concerned about the ability to predict what address
will send the connection, and you are obviously concerned about the
ability to predict the port. These concerns are relevant in the case of
Java today.

The listening end needs both of these to match a particular incoming
connection to a specific media description. Otherwise the listener must
dedicate a listening socket to the invitation. The big problem here is
that once something is optional it is tempting for people not to do it.
For instance, a device that only implements direction:active may just
not go to the trouble. But then every device that implements
direction:passive or direction:both must be prepared to deal with this
lack. That both complicates the code and increases resource usage during
invitation processing.

I'm not sure there is any way out of this. But at the least the document
should say that both the port and the address SHOULD be supplied.

	Paul