Subject: RE: [SIP] SIP, SDP, and TCP-based media transport

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 1 Aug 2000 03:07:14 -0700

I am uncertain as to whether you understood my point so I will give an
example.

SDP A
c=IN IP4 10.0.0.1
m=audio 6000 RTP/AVP 0

SDP B
c=IN IP4 10.0.0.2
m=audio 7000 RTP/AVP 0

This does not infer that B must send packets with a source port of 7000 or
that A must send packets with a source port of 6000 (if my understanding of
SDP is correct - please correct me if I'm wrong).

In your TCP model, must a TCP connection connection use a source port equal
to the destination of the remote node ? If so, isn't this going against the
spirit of the SDP spec ?

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2000 9:18 AM
> To: Fairlie-Cuninghame, Robert; Anders Kristensen
> Cc: [email-masked]
> Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
> 
> 
> At 05:27 PM 7/31/00 -0700, Fairlie-Cuninghame, Robert wrote:
> >Just thought I'd interject:
> >
> > >          The problem with port zero is that it forces a 
> server to use
> > > dynamic port assignments.  There are many cases where you
> > > want a TCP server
> > > to be sitting listening on a single port for incoming
> > > connections (indeed,
> > > this is the norm for most TCP-based services).  Assuming this
> > > topology, how
> > > is the server able to correlate an incoming connection to the
> > > original SIP
> > > caller?  In normal SIP/SDP, both sides specify an 
> Address/Port pair,
> > > forming a unique four-tuple which identifies the session.  If
> > > you force the
> > > client-side port to be zero, you lose a critical piece of 
> information
> > > necessary for the client to determine which party just connected.
> > >
> >I was under the impression that for the UDP case each SDP 
> body specifies
> >only the destination port and that UDP packets do NOT have 
> to have to have
> >their source port equal to the opposing destination port!! This same
> >property should be reflected in any TCP model, should it not ?
> >
> >Robert.
> >
> >
> 
>          You are correct, but I did not mean to infer that 
> both sides would 
> specify the *same* Address/Port pair.  Certainly the 
> addresses would be 
> different, and it would only be coincidence if the port 
> numbers were to be 
> the same.
> 
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> [email-masked]
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 8 Aug 2000 22:12:41 -0700

You are the man! I think this ties everything together very well.

If the attribute is missing what should the assumed value be? I would argue
that it should be "uni" as this is most inline with the way SDP is written. 

I agree with regards to port 0, ie even if "active" is used the port must
not be zero (perhaps the discard port (9) could be a recommendation?).

Do we want/need to define two tcp profiles: one for non-RTP/normal tcp and
one for RTP/AVP/TCP ?

Cheers,

Robert.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 12:50 PM
> To: David Yon
> Subject: Re: [SIP] SIP, SDP, and TCP-based media transport
> 
> 
> This thread never reached any conclusion; there was a lot of 
> discussion
> and it would be nice to come to consensus.
> 
> Summary so far:
> 
> 1. Seems there is consensus that we would like to be able to have a
> single TCP connection for bidirectional media. The case of two
> unidirectional tcp connections is easy and pretty much supported with
> the current SDP model.
> 
> 2. It was proposed that the INVITE could contain a port number even if
> the UAC was going to open the connection to the UAS; this port would
> indicate the source port used in the open. This was motivated by the
> desire for the UAS to have a single server port, and thus distinguish
> incoming tcp connections from different UACs on the same 
> machine by the
> source port.
> 
> I have a problem with including the source port in the 
> outgoing request.
> As Anders pointed out, this requires allocating a source port before a
> connection is setup, which is going to be impossible in 
> certain systems.
> 
> It would also be useful to allow both sides to try to connect, in the
> case where one is behind a firewall, the result is that one of the
> connection attempts will work and then that can be used. If both
> connect, we could define a precedence rule for dropping one.
> 
> So, my proposal would be:
> 
> 1. m line format stays as is
> 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP
> 3. the port number in the m line refers to the port it is listening on
> for connections; this may be meaningless dependending on the 
> next thing
> 4. we define a new attribute, tcp, with values of:
>    active: the port number is meaningless and the UA sending this SDP
> wishes to open the connection to the remote side
>    passive: please open a connection to this port
>    both: we should both try to open connections; the one opened to the
> highest remote port takes precedence if both succeed. If the ports are
> the same, the highest IP address.
>    uni: we should both open tcp connections, and use both, each being
> unidirectional (at least for RTP, RTCP would be sent back 
> over the same
> TCP connection I suppose)
> 
> I don't like using port zero since this overloads the meaning of port
> zero defined by SIP (refusal of a stream).
> 
> 
> Comments?
> 
> -Jonathan R.
> 
> David Yon wrote:
> > 
> > Attached is an informal discussion of various approaches to 
> solving the
> > SDP/TCP problem.  Any comments are welcome.  If there is 
> general agreement
> > I'd be happy to collaborate on or submit a formal I-D.
> > 
> > With FOGLAMPS under way, and T.38 Annex D already 
> finalized, this problem
> > needs to be solved as soon as possible.  While this may be 
> more of an SDP
> > issue than a SIP issue, this problem is directly relevant 
> to SIP which is
> > why I've posted this here.  If anyone has suggestions for 
> additional and/or
> > more appropriate forums please let me know.
> > 
> > ----
> > 
> >                 SIP, SDP, and TCP-based media transport
> >                 =======================================
> > 
> > The Session Description Protocol currently only describes a 
> small set of
> > protocols that are used for media transport, the most 
> common being RTP and
> > UDP.  A significant omission in SDP is a way to specify TCP as the
> > transport protocol.  Since SIP uses SDP to describe the 
> media used in the
> > session being initiated, there is currently no way to use 
> SIP to set up
> > sessions that use TCP connections for media transport.
> > 
> > Annex D of the T.38 spec recommends that a protocol 
> identifier of "TCP" be
> > added to SDP.  While this allows SDP to describe that the 
> media transport
> > will use TCP as the network protocol, it only tells half 
> the story.  The
> > major difference between RTP/UDP and TCP is that connection setup is
> > asymmetric---one side must be the initiator and the other 
> must be the
> > listener.  Only specifying that the network protocol is TCP 
> omits this
> > important piece of information.
> > 
> > The remainder of this document discusses ways that the 
> direction of the TCP
> > connection setup could be conveyed in SDP.
> > 
> > Specification By Inference
> > --------------------------
> > 
> > One approach is to leave the decision to the endpoints, and 
> just assume
> > that if they can agree on a media transport that they'll 
> implicitly know
> > how to correctly set up the connection.  For example, a 
> transport type of
> > "t38" over TCP might imply that the caller always initiates 
> the connection
> > and the callee accepts the connection.
> > 
> > The problem is that it doesn't scale.  It requires that SIP 
> ALP's stay
> > current on an ever-growing list of transport types and 
> hard-code their
> > connection heuristics.
> > 
> > Mapping to SIP Call Flow
> > ------------------------
> > 
> > Another approach is to standardize on mapping the SIP call 
> direction to the
> > connection of the TCP setup.  I.e., specify in the SIP RFC 
> that the UA that
> > does the INVITE is the one that accepts the TCP connection 
> from the UA that
> > does the OK.
> > 
> > The problem with this is that it imposes an arbitrary 
> restriction upon a
> > wide range of applications and topologies.  The transport 
> may involve a
> > legacy protocol that cares about the direction of the TCP 
> setup, and it may
> > not always map to the direction of the call flow.
> > 
> > The other problem is that it resolves the issue only for 
> SIP, leaving the
> > problem to be solved again and again for other protocols 
> that also use SDP.
> > 
> > First-Specified/First-Served
> > ----------------------------
> > 
> > One could specify that the first UA to offer up an SDP message is
> > implicitly offering to accept the TCP connection.  This 
> maps somewhat to
> > how SDP works on UDP-based transports, where by specifying 
> a port number
> > the UA is announcing that the port is now available to 
> accept a media stream.
> > 
> > This technique would certainly work when the topology 
> allows the UA sending
> > the INVITE to accept the TCP connection.  But if the 
> topology requires that
> > it be the UA sending the OK, then you run into the problem of
> > underspecifying the session type.  Most sessions signalled 
> in SIP are
> > described by the SDP being sent in the INVITE.  I.e., is 
> this an audio
> > call?  an audio/video call?  a T.38 fax call?  This question can be
> > answered by inspecting the SDP in the INVITE.  Not sending 
> this information
> > may deprive downstream SIP proxies of critical information 
> required to
> > select the correct media gateway.
> > 
> > Port Zero
> > ---------
> > 
> > Another twist that would leave SDP syntax unchanged would 
> be to establish
> > the convention that an SDP message specifying zero for the 
> port and TCP for
> > a transport is the UA that will initiate the TCP 
> connection.  It would be
> > up to the other UA to supply a valid port that will accept 
> this connection.
> > 
> > One problem is that this limits the flexibility of the network
> > topology.  Many TCP protocols have a well-known port at 
> which they will
> > accept connections, and it may be desirable to always use 
> that port number
> > for the accept (not the least of which is ease of dumb-firewall
> > administration).  If this is the case, specifying port zero for the
> > initiator means that the acceptor may not have sufficient 
> information to
> > correlate an incoming connection with a SIP session.
> > 
> > TCP/S and TCP/C
> > ---------------
> > 
> > The most explicit way to fully describe TCP-based transport 
> is to add two
> > new SDP protocol descriptors: TCP/S and TCP/C (any better 
> suggestions for
> > nomenclature?).  The UA that will accept the connection 
> specifies TCP/S
> > along with the port number it will be accepting on.  The UA 
> that will
> > initiate the connection specifies TCP/C along with the port 
> number to which
> > it has bound the outgoing socket.
> > 
> > This approach has numerous advantages.  The SDP messages 
> convey *exactly*
> > what will be occurring for media transport, and SIP ALP's 
> will be able to
> > Do The Right Thing(tm) for TCP-based transports with a 
> minimum of extra
> > complexity.  TCP-based servers can continue to use fixed 
> port numbers for
> > incoming connections if that is desirable.  At the same 
> time, connections
> > can be mapped to sessions without using additional 
> signaling in the media
> > transport itself.  Even dumb firewalls can easily be 
> configured to pass
> > this type of traffic (although NAT's remain a problem).
> > 
> > SSL/S and SSL/C?
> > ----------------
> > 
> > Any reason to add these to the list?  One could argue that 
> this belongs in
> > the description of the upper-layer protocol.  On the other 
> hand, it's
> > common enough that it may warrant being added to the list 
> of well-known SDP
> > transports.  Comments?
> > 
> > David Yon
> > Chief Technical Officer
> > Dialout.Net, Inc.
> > [email-masked]
> > 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Aug 2000 09:30:59 -0700

> TCP connection I suppose)

"both" is going to have funny results if there are one or 2 NATs on the
path... You should not rely on comparing the binary values of ports or
addresses. I thing that active/passive/uni provides a good match -- or
active/passive/both, leaving it to the app to decide which connection is
used for what purpose.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 10 Aug 2000 18:59:06 -0700

Good point. Perhaps we should just combine both & uni (to make both an
optimization of uni). Ie, a UA is free to send over either tcp connection
which successfully connects; received packets from either (successful) tcp
connection should be treated identically. This also makes things simpler
which is also a bonus.

I still beleive that both a tcp and a RTP/AVP-TCP SDP profile will have
their uses. For instance, Henning just mentioned using reliable RTP
text/digit transport through TCP in another stream.

Robert.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 12:31 AM
> To: 'Jonathan Rosenberg'; David Yon

---

From: David Yon <[email-masked]>
Date: Mon, 14 Aug 2000 08:38:24 -0400

I just want to clarify that you are not suggesting that we go solely with 
the "TCP-AVP" nomenclature, yes?  Rather, you're suggesting that we have 
"TCP" (or some such that suggests raw TCP with no AVP) *and* a 
"RTP/AVP-TCP" which implies RTP/AVP using TCP rather than UDP.

Have I got that right?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 16 Aug 2000 18:48:34 -0700

> >
> >Would both "TCP" and "RTP/AVP-TCP" share the same a= line 
> options?  Would 
> >they therefore be described in the same I-D or is there 
> sufficiently more 
> >to say about RTP/AVP-TCP to warrant its own I-D?
> 
I don't see why. We are prescribing the same mechanism for both cases,
right? So it seems silly to create two I-D's that describe the same
mechanism. I imagine that the RTP/AVP-TCP case will mostly simply reference
RFC1890.

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 29 Aug 2000 20:08:29 -0700

Hi David,

Great work !!

Here are my comments:

- Section 1.2: Are you referring to the driection parameter ? If so, then
Section 1.1 should also refer to this parameter to be consistent.  
- I think there should be an assumed direction of "both" if the direction
parameter is missing.
- IMO, in Section 2.3 the statement "Endpoints may choose to specify
direction:both under one or more of the following conditions:" should be
reworded as none of the bullets are really "conditions". Perhaps "Endpoints
may choose to specify direction:both for one of the following reasons:"
would be better. 
- In the case of both sides using "direction:both" I believe we decided not
to close either of the tcp connections to avoid a race condition. I think
someone made to point that the stated algorithm doesn't work is both sides
are behind ALGs. Can anyone confirm?
- I think that "the endpoints intend to use one/two TCP connections" should
be removed from the second and third reasons for using direction:both
(Section 2.3). If we are not dropping one of the TCP connections (see above)
then those two statements don't make a lot of sense. In my mind, there are
only two main reasons for using direction:both: 1) want to allow otherside
to specify either active or passive [your first point] 2) want to be able to
traverse a NAT or NAPT [your second point].
- In the case of both sides using "direction:both", it also needs to be
stated that each endpoint must be willing to receive media from either or
both connections. 

Cheers,

Robert.

> Sent: Tuesday, August 29, 2000 11:53 PM
> To: [email-masked]
> Ok, I've got an I-D available, any and all comments welcome:
> 
> ftp://ftp.dialout.net/drafts/draft-ietf-sip-sdp-tcpmedia-00.txt
> 
> I'm an admitted newbie to the whole I-D process, but based on 
> my readings 
> at www.ietf.org this needs to be submitted under the auspices 
> of the SIP 
> WG.  Can I just mail it to the [email-masked] 
> address or are 
> there other considerations to be dealt with first?
> 
> At 01:32 PM 8/18/00 -0400, David Yon wrote:
> >At 11:03 AM 8/18/00 -0400, Jonathan Rosenberg wrote:
> >
> >>OK? If so, lets declare this done, get an I-D written, and 
> move forward
> >>here.
> >
> >Yes, fine by me.  I'll assume since nobody else stepped up 
> to the plate 
> >that I've got the token on the I-D.
> 
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> [email-masked]
> 
> 
>