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

From: "Anthony Toubassi (EUS)" <[email-masked]>
Date: Mon, 31 Jul 2000 13:00:32 -0500

David,
I did not receive the attachment to your message.  This may also explain the
lack of response/comments.  I think there is an interest in solving the
SDP/TCP/SCTP? problem, so please resend the attachment for review.

Thanks,
Anthony 
 Ericsson, Inc.
 [email-masked]

-----Original Message-----
From: David Yon [mailto:[email-masked]]
Sent: Monday, July 31, 2000 10:43 AM
To: [email-masked]
Subject: Re: [SIP] SIP, SDP, and TCP-based media transport

         Wow, not a single reply or comment.  Is there no interest/opinion 
at all on this subject?  Have I raised this subject in an inappropriate 
forum?  Does this duplicate work in other places that I've missed?  Should 
I take silence for agreement or is disagreement so strong that folks can 
hardly bring themselves to speak? :-)

         Any comments or suggestions appreciated.

At 10:31 AM 7/26/00 -0400, 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.
>

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: David Yon <[email-masked]>
Date: Mon, 31 Jul 2000 14:39:22 -0400

The word "attached" was used a bit loosely, in fact the discussion 
was inlined ASCII.  Check the list archive to read it in full:

http://lists.bell-labs.com/pipermail/sip/2000q3/001768.html

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

---

From: David Yon <[email-masked]>
Date: Mon, 31 Jul 2000 18:46:30 -0400

At 06:26 PM 7/31/00 -0400, you wrote:

>Does that mean I've been using "TCP" as the transport illegally for
>nearly two years now? Good grief.

I can't authoritatively say so, but that would be my impression.

>OK, so if I understand you right you want to allow a UAC to be the
>active part in setting up the TCP connection while at the same time
>specifying which local TCP port it will be using in an initial INVITE,
>but without actually connecting before receiving the 2xx specifying the
>host/port to connect to, right?  I believe not all programming
>environments (think Java) will actually allow allocating a local port
>without connecting, although it sounds like a reasonable thing to do.

Yes, that would be a concern.  A quick peek at the latest Java docs does 
seem to bear out your assertion.  I guess that perhaps the initiator could 
be allowed to specify port zero if it truly could not determine its port, 
and for some transports/topologies that would be acceptable.  A smart SIP 
ALP could then decide that it is going to either proxy the connection 
itself (or could find out from the NAT/firewall what port will be used on 
the WAN side) and rewrite the SDP appropriately.

>On the whole it doesn't sound like this is much of a problem in
>practice, but if it is my preference would be for using an SDP m= level
>attribute over TCP/C TCP/S transport specifiers. Looks better, IMHO.

I'm not hung up on the nomenclature, if something like this was legal:

m=image 5291 TCP ACTIVE lpr     (UA that connects)
m=image 515 TCP PASSIVE lpr     (UA that accepts)

...then that would be fine with me.  I just would prefer that there be a 
way to specify the two categories of "TCP" while preferably keeping it on 
the m= line.  It was my impression that the format of the m= line was 
fairly strict, and that inserting a new specifier after TCP wouldn't fly.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 31 Jul 2000 17:27:37 -0700

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.

---

From: David Yon <[email-masked]>
Date: Mon, 31 Jul 2000 21:17:57 -0400

>property should be reflected in any TCP model, should it not ?

         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]