Subject: RE: [SIP] SIP and T.38?

From: David Yon <[email-masked]>
Date: Mon, 24 Jul 2000 17:26:56 -0400

Thanks for the pointer, that's extremely helpful.  What's not 
clear from reading the draft is how the Annex solves some of the problems 
with SDP specifying a TCP transport.

         I'm happy to see that "TCP" will become a registered name, but I 
don't see how the direction of the initial connection is negotiated.  I.e., 
which side of the T.38 does the "connect" and which does the "accept"?  Is 
this described in the proposed extensions to SDP?  If so, where?  If not, 
was the idea that the direction of the connect would be implicit by the 
rest of the SDP media description (i.e., if it's t38 over TCP, then the 
caller always does the connect)?

         Does anyone else on the list think it might be a good idea to 
standardize this as part of how one describes a TCP-based transport in 
SDP?  It seems like it couldn't hurt to make it an explicit part of the SDP 
description.

At 03:19 PM 7/24/00 -0500, you wrote:
>T.38 Annex D (SIP/SDP Call Establishment Procedures) was done in February 
>and should soon be at: 
><http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html>http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html 
>
>
>It is not there yet because it was bundled in an Amendment with T.38 Annex 
>E (H.248/Megaco) which was delayed... In the meantime, you can look at the 
>'draft' version and the IANA SDP registrations at: 
><ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/>ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/ 
>
>
>Cheers, Glenn.

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Jul 2000 02:34:00 -0400

David Yon wrote:
> which side of the T.38 does the "connect" and which does the "accept"? 

I believe its the same as if it were UDP. If I receive an SDP message
with a UDP port for some stream, I send there upon receiving it; if
there is a TCP port for some stream, I open a connection there and send
on it. Receipt of SDP provides parameters to use in actively
communicating with a peer.

-Jonathan R.
-- 
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jul 2000 08:50:38 -0400

> communicating with a peer.

This would imply that either both sides open a (simplex) connection in
each direction (the most symmetric approach) or that the callee always
actively opens the connection if the caller includes SDP in the INVITE.
Alternatively, the caller could avoid putting SDP in the INVITE and wait
for the callee to do so, reversing the direction.

Given the likelihood that both caller and callee are behind a firewall,
it may not matter/help much to support fine-grained control.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 25 Jul 2000 13:35:48 -0700

> with a UDP port for some stream, I send there upon receiving it; if

TCP has an important difference from UDP, that a connection must be
originated from one end, and accepted at the other, but then data is
exchanged 2 ways. RTP connections are explicitly one way, and do not have
this directional creation. Bi directional data transfer with RTP is
accomplished by having 2 separate connections (one in each direction). These
might share UDP port numbers, but they are 2 separate connections.

More specifically:

for an RTP connection the receiver of data opens a specific UDP port number
on which to receive RTP packets. The RTP connection is defined by the
specific port number and IP address tuple of the receiver (please correct me
if I'm wrong - this is from memory). The sender then sends data (from any IP
address or port) to this receiver. Multiple talkers in a conference are
distinguished by different SSRCs. These can be received BOTH in multicast
mode AND in unicast mode. (does anyone have any idea if any SIP UAs support
multiple SSRCs at the moment?)

For a TCP connection the connection is opened in a specific direction, but
is then 2 way (data exchange can happen in either, or both directions). The
connection is defined by the 4 tuple of sender address and port, and
receiver address and port. A second backwards connection cannot be opened
with the same address/port numbers as the original connection.

This leaves the issue for TCP connections of deciding in advance who will
initiate the connection, (connect) and who will accept it. In a world
without firewalls one could imagine using a random number generated on both
sides, the side generating the higher number opening the connection (say).
Unfortunately firewalls may impose a requirement that a particular client
can only open an outbound connection - and cannot be the accepting end. In
this case the client must make the connections.

The problem scenario is where both clients must make the outbound
connection, and neither can accept a connection (say both are bahind
firewalls that only let out TCP connections). In this case the only solution
is for a third party to accept both connections and bridge the connections
together.

Simon Barber

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
Sent: Monday, July 24, 2000 11:34 PM
To: David Yon
Cc: Glenn Parsons; [email-masked]
Subject: Re: [SIP] SIP and T.38?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jul 2000 03:16:50 -0400

Simon Barber wrote:
> is then 2 way (data exchange can happen in either, or both directions).

It need not be the case. As Henning has pointed out, with what I was
proposing you would end up with two tcp connections, each one only being
used for data in one direction.

> The

It wouldn't be opened in the reverse direction with the same 5-tuple. If
A calls B, A provides B with a receive IP address and receive port, A.IP
and A.port. In the 200 OK, B provides A with a IP address and port, B.IP
and B.port. A opens a TCP connection to B on B's IP and port, resulting
in the tuple (source address, source port, destination address,
destination port) on A:

(A.IP, A.availableport, B.IP, B.port, TCP)

and then B opens to A, resulting in the tuple on A:

(A.IP, A.port, B.IP, B.availableport, TCP)

these are not the same.

Actually, the ideal case is to do this symmetric open, and then allow
both sides to actually use either TCP connection to send. This has the
advantage that if one (and only one) party is behind a firewall, and IFF
the firewall allows outbound TCP connections, one of these two will
succeed, and then that connection can be used by both parties.

-Jonathan R.

---

From: David Yon <[email-masked]>
Date: Fri, 28 Jul 2000 07:59:10 -0400

>succeed, and then that connection can be used by both parties.

         A serious flaw with this is that it forces an unnatural usage of 
TCP into topologies that may not support what you are describing, as I 
discussed in the informal draft I discussed earlier.  TCP works very well 
when used as intended, why contort it into something else when all that's 
needed is a bit of additional SDP information?

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