[SIP] RE: SCTP as transport for SIP

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Wed, 14 March 2001 16:52 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27782 for <sip-archive@odin.ietf.org>; Wed, 14 Mar 2001 11:52:11 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A738344367; Wed, 14 Mar 2001 11:52:10 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D267E44367 for <sip@lists.bell-labs.com>; Wed, 14 Mar 2001 11:51:57 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA07184; Wed, 14 Mar 2001 11:55:02 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <FMX9QL1G>; Wed, 14 Mar 2001 11:53:55 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF0128BBA4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fairlie-Cuninghame, Robert'" <rfairlie@nuera.com>, "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [SIP] RE: SCTP as transport for SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 14 Mar 2001 11:53:54 -0500


  
-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
>Sent: Thursday, March 08, 2001 9:43 AM
>To: 'schulzrinne@cs.columbia.edu'; 'jdrosen@dynamicsoft.com'
>Cc: 'sip@lists.bell-labs.com'
>Subject: SCTP as transport for SIP
>
>
>Hi there, 
>I have a query with your "SCTP as transport for SIP" draft
(http://www.cs.columbia.edu/
>~hgs/sip/drafts/draft-rosenberg-sip-sctp-00.txt),
>
>For instance: 
>             If the transport is SCTP, the entity SHOULD look for 
>             exising open SCTP connections to the given IP address and 
>             port. The number of streams within the connection, and the 
>             mapping of SIP requests to streams, are at the discretion 
>             of the entity. However, it is RECOMMENDED that some kind of 
>             stateless hash be used so that requests for the same call 
>             all be mapped into the same stream. If no SCTP connection 
>             is established, one is opened and the request sent over it. 
>
>The draft says that the mapping of the SIP requests to streams is up to the
entity. How can 
>this be? A SIP server would normally be only listening to particular
streams to receive SIP 
>requests, the other streams may be unused or used for some other purpose.
The "lookup 
>method" (SRV or whatever) must surely specify an IP address, SCTP port and
stream number to 
>locate the SIP service via SCTP? 

I don't think so. I had thought (perhaps mistakenly) that streams were
opened and closed as part of signaling within SCTP, and that these
parameters did not need to be signaled as part of SIP. A quick glance at
rfc2960 seems to support this claim, since the number of streams opened
appears to be signaled as part of the initialization process. Can you point
me to a section of rfc2960 which would indicate that a stream ID must be
signaled out of band in order to setup an SCTP association?


>What is more, due to the unidirectional nature of the SCTP streams, surely
the reverse 
>stream must be specified to the endpoint in the Via (or elsewhere). [I
don't think a 
>reverse DNS SRV lookup could be guaranteed - the UAC may not even have a
hostname.]

Same argument as above; I don't think so. I do not believe there is a notion
of explicitly listening on a stream. A SIP UAC which sends a request over
SCTP, and then sets up 10 streams, will be able to get a response on any one
of them. Again, I could be mistaken and would welcome comment or input from
real SCTP experts.

>I think there are quite a few consideration that SCTP raises above and
beyond other 
>transport protocols (even when you ignore the issues related to SCTP
association 
>establishment). I'll be interested to hear your opinions.

I'm not an SCTP expert. I'd welcome a draft from someone who is that could
comment on SIP issues with SCTP. Our SIP over SCTP draft has been around for
some time, and did not receive any significant comments from the SCTP
community.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.