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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 11 Jun 2001 06:47:16 -0700

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

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

http://www.ietf.org/internet-drafts/draft-fairlie-mmusic-sdp-sctp-00.txt
<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
<http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-entfw-01.txt

Cheers,

Robert.

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

At 06:46 PM 6/8/2001, you wrote:
> >
> > If N/PAT was not the scenario you were considering, could you elaborate
> > more on issue?  Thanks!
>
>No, the point isn't that I can't *trust* the address given in the SDP.
>
>One point is that the address my listener is at may differ from the
>address that I might connect from.

Why would that be the case?  There is no parallel in the traditional usage 
of SDP where RTCP/UDP streams are being described.  The IP Address you 
advertise in SDP is the address at which you intend to communicate.

>It isn't apparent (to me) if the proposal makes this assumption or not.
>If it does, then at least I can stop worrying about how to make things
>work on the listening side if it isn't true (which is what I have been
>doing), and instead start worrying about how to ensure that I connect
>from the same address I listen on.
>
>Another point is that the c= line may not uniquely identify a connecting
>endpoint.
>What if the direction:active endpoint is redundant, and provides a c=
>with a DNS name that maps to multiple addresses? Does the
>direction:passive endpoint accept a connect from any of the addresses?

A DNS name is not valid in the "c=" line---it must be a specific 
address.  Check the SDP spec for details:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt

> >
> > At 02:30 PM 6/8/2001, Paul Kyzivat wrote:
> > >I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
> > >at least when used with SIP. I made a posting to sip-implementors
> > >earlier but got no responses, so I will try here.
> > >
> > >Consider an endpoint like a gateway that might be establishing many
> > >connections simultaneously, and assume it wants to act in
> > >direction:passive or direction:both. To do so, it hands out SDP
> > >specifying the port number it will listen on for connections. If it
uses
> > >the same port number for multiple concurrent connections, then it will
> > >have difficulty in telling which incoming connection belongs to each
> > >pending call. (This is essentially the same problem that section 3 -
> > >Source-Port Considerations attempts to address, but the problem is
> > >actually a larger one that the draft doesn't address.)
> > >
> > >The <source-port> is supposed to make it possible to sort this out. But
> > >that can only distinguish between incoming connections from the same
> > >address - requests from different addresses could be using the same
> > >port.
> > >
> > >Perhaps the draft assumes that the connection will be from the c= in
the
> > >sdp from the other endpoint. But that is a pretty shaky assumption.
> > >
> > >The only certain solution I can see without changing the draft is to
> > >dedicate a listening port for the duration of a single invitation. But
> > >this is a costly solution. Alternately, the syntax could be extended
to:
> > >
> > >        a=direction:<role> <source-port> <source-address>
> > >
> > >I believe this would solve the problem if <source-port> and
> > ><source-address> are provided. Ensuring this would require making them
> > >mandatory rather than optional as currently specified.
> > >
> > >         Paul Kyzivat
> > >         Cisco Systems
> >
> > 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]

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 13:12:15 -0400

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.

> David, I do agree with Paul that perhaps a little more clarification
> would be helpful to explain the slight shift in paradigm from UDP.
>