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

From: David Yon <[email-masked]>
Date: Thu, 07 Sep 2000 09:46:09 -0400

Thanks for the quick feedback.  Sorry it has taken so long to follow up.

At 08:08 PM 8/29/00 -0700, Fairlie-Cuninghame, Robert wrote:
>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.

The direction parameter goes on the a= line, not the m= line.  The "fmt" 
identifier is a qualification of the protocol above TCP.  For want of a 
better example, "t38" would be a valid entry in that position on the m= line.

>- I think there should be an assumed direction of "both" if the direction
>parameter is missing.

I'm pretty agnostic on this issue, so if nobody else has a problem with it 
I can live with that.

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

Agreed, fixed.

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

I've finally had some time to work through some of the scenarios, and I 
think the solution is to abandon the "highest port wins" heuristic and 
replace it with the following:

         In the event that both TCP connections succeed:

         1) Each endpoint MUST accept data from either TCP connection.

         2) Once an endpoint has started to transmit data on one of the TCP
            connections, it MUST use that TCP connection exclusively for
            transmission.

         3) If as a result of (2), one of the TCP connections is determined
            to be idle, either endpoint MAY close the idle TCP connection.

I think that gets rid of the race condition, works through an ALG where 
port numbers might change, yet still allows one of the connections to be 
shut down when circumstances permit.  Worst case is each connection becomes 
unidirectional.

Comments?  Anyone see a hole I missed?

>someone made to point that the stated algorithm doesn't work is both sides
>are behind ALGs. Can anyone confirm?

I'm having trouble parsing this sentence to begin with, never mind 
recalling the original issue. :-)  Could you rephrase?

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

I agree with most, but not all of this.  Certainly if you "want to be able 
to traverse a NAT/NAPT", then you likely would only need a single TCP 
connection but are forced to attempt two in order to determine who has the 
unimpeded path.

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

Yes.

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: Sun, 10 Sep 2000 01:45:27 -0400

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Friday, September 08, 2000 11:16 AM
> To: Fairlie-Cuninghame, Robert; [email-masked]
> Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
> 
> 
> At 11:23 PM 9/7/00 -0700, Fairlie-Cuninghame, Robert wrote:
> > >
> >Sounds good - I can't see any problems. So I guess this also 
> means that once
> >you have received data on a TCP connection you may not close it.
> 
> Correct.  Ditto if you've sent data on a TCP connection.  
> Once you've sent 
> *and* received data, and they happen to occur both on the same TCP 
> connection, it's safe to close the other one.

You should include this specific condition in the draft. Right now, its
a bit unclear how to usefully determine when a "timeout" has occurred in
order
to close the other connection. 

> So, if there are no additional comments, how do I go about 
> getting this 
> into the queue?  Jonathan...?  Henning...?  Comment?

Submit it as an I-D. You do that by sending it to [email-masked].
It can't be a working group item yet, since there has not yet been consensus
to add this as a working group item (to date, this has happened initially by
proposing this at a meeting, and seeing if there are objections from the
list afterwards). So, you will need a filename like:

draft-yon-sip-sdp-tcpmedia-00.txt

-Jonathan R.

---

From: David Yon <[email-masked]>
Date: Sun, 10 Sep 2000 09:56:08 -0400

>to close the other connection.

Well there's really no timeout involved.  Each endpoint knows whether it 
has an idle connection only after it has both sent and received data.  I 
see no value in trying to apply a timeout to that algorithm.

>draft-yon-sip-sdp-tcpmedia-00.txt

As it turns out the SIP WG chairs believe this to be more appropriately an 
MMUSIC item (since it only affects SDP), pending approval from the MMUSIC 
chair.  So I'll be taking that track instead of SIP.  I will keep the SIP 
list informed of changes to the draft and will be monitoring this list for 
discussion, since the draft is mostly applicable in the context of SIP.

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