RE: [SIP] RE: SCTP as transport for SIP

["Fairlie-Cuninghame, Robert" <[e-mail]>]

Hi Tom & Jonathan,
 
I'm glad we are at least getting some discussion on the matter. SCTP as a
general transport protocol is beign handled by the tsvwg where it seems very
difficult to elict comment.
 
I agree with you that sharing associations between different applications is
a feature that may be implementation dependent; however in my mind this is
an orthogonal issue to whether or not it matters whether streams are treated
as a group or individually. This simply falls on the difinition of an
application. An application is usually made up of many separate processes.
The application is of course responsible for openng and managing multiple
streams in an association (this is not in question). An application is of
course not resticted to using only one protocol within its structure. And
obviously treating streams as a jumble (where any protocol can be received
on an arbitary stream) is untenable for sharing these "services" over a
single association. So what you are proposing is that each logical stream
must use a separate assocation - if you cannot differentiate streams then
you definitely cannot handle the streams by different procesess in the same
application. To enforce separate associations would very much defeat the
purpose of SCTP - SCTP allows bundling of multiple streams, uses HEARTBEAT
to active test network paths, fragments large datagrams so that
time-critical smaller packets are not effected etc etc. Allocating each
logical stream to a separate association effectively negates these benefits
wastes a lot more network bandwidth. 
 
Tom, I am not sure what you mean by this falling out of the SIGNTRAN model.
SCTP was developed such that it can also be a general purpose transport
layer (by their own admission). The SIGTRAN group is now only looking at it
as a signaling transport layer (which is no surprise) and are in the process
of developing adaption layers between SCTP and the signaling protocols.  The
remainder of the SCTP work is beign adopted by the tsvwg workign group. 
 
In fact I would say that SIP is going against the SIGTRAN model, for
instance in M2UA (MTP2 User Adaption) each stream is devoted to a different
SS7 link. Yet, the adaption layer as far as can tell does not housekeep the
streams. Also, there is no way that arbitrary packets can arrive on any
stream. SIGTRAN has no requirement that each SS7 link must use a different
association - so why is SIP any different? You must be able to identify the
stream a particular SIP packet should be sent on.
 
Also Tom, the U-SCTP draft (providing an unreliable datagram service) is now
a released draft <draft-ietf-sigtran-usctp-01.txt> and implemented in the
Randall Steward's open source reference implementation. 
 
As for not wanting an adaption layer for using SCTP as a general purpose
transport: SCTP and U-SCTP provide a reliable and unreliable datagram
service that is an analog to TCP and UDP respectively. Any so any many ways
there are few changes between the already published "adaption layers"
between an application and UDP/TCP. If a protocol already uses UDP or TCP
then its migration to SCTP is fairly simple. The SIGTRAN group are writing
adaption layers for protocols that do not current run over UDP/TCP. An
example: there are very few changes needed to send RTP over U-SCTP. RTP by
is own admission is written to be lower-layer independent and very little
changes when the Audio Video Profile [RFC1890] is applied to U-SCTP. 
 
Tom, I completely agree with you that more dynamic negotiation is required.
I am in the process of writing an SDP profile for SCTP. Using this profile,
you should be able to negotiate almost any session or connection over SCTP
that you can with SDP over UDP/TCP today. I see it opening many doors for
SCTP. 
 
Negotiation of course also involves "location" of resources which is of
course the main focus of our discussion here (for SIP). My point is:
independent of implementation or location method, the result must be able to
specify the stream on which the process handling that service is waiting
(and that just sending it to any stream is not sufficient). To do otherwise
infers that mutliple "services" or streams cannot be sent over the same SCTP
association which very much defeats the benefits of SCTP. Are you proposing
this for SIP ? That is, an association opened by an application utilizing
SIP can only attach a single UAS/proxy instance and all other protocols used
by the application must use a separate association (with loss of many
benefits provided by and incuring extra overhead) ?
 
Jonathan, I agree with you that there are issues to be resolved with how far
we take the inclusion of the stream identifier but I think it deserves some
more thought & discussion before giving up.
 
Sorry to be so long winded.
 
Regards,
 
Robert.
 

-- My opinions should not be taken as necessarily representing those of
Nuera Communications, Inc. -- 

-----Original Message-----
From: Tom-PT Taylor [ mailto:[e-mail]
<mailto:[e-mail]> ]
Sent: Thursday, March 15, 2001 3:33 PM
To: 'Jonathan Rosenberg'; 'Fairlie-Cuninghame, Robert';
'[e-mail]'
Cc: '[e-mail]' <mailto:'[e-mail]'> 
Subject: RE: [SIP] RE: SCTP as transport for SIP



I have read the later notes in this thread, but this will do for a reply.
The first point I would like to make is that Robert's points are very much
related to implementation.  If, for instance, your SCTP association has been
set up solely for transport of SIP, there is no issue about which streams to
listen and send on -- they are all used.  If you are setting up an SCTP
association with the intent of devoting certain streams to one protocol,
certain streams to another, and you want to do it on a dynamic rather than
configured basis, then either the receiving end has to classify the streams
according to initial received content or the two ends need a way to
negotiate stream usage.  This falls outside of the current SIGTRAN model,
which tends to have an adaptation layer which sets up associations for its
own use.  What is needed for Robert's case is a generic adaptation layer
which has no user-protocol-specific services but does handle the required
housekeeping.

Note that in general, to carry RTP within an SCTP association would require
an unreliable datagram transfer service which Randy Stewart has talked
about, but which is not currently part of SCTP.    

> -----Original Message----- 
> From: Jonathan Rosenberg [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, March 14, 2001 11:54 AM 
> To: 'Fairlie-Cuninghame, Robert'; '[e-mail]'; 
> Jonathan Rosenberg 
> Cc: '[e-mail]' 
> Subject: [SIP] RE: SCTP as transport for SIP 
> 
> 
> 
> 
>   
> -----Original Message----- 
> >From: Fairlie-Cuninghame, Robert [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> >Sent: Thursday, March 08, 2001 9:43 AM 
> >To: '[e-mail]'; '[e-mail]' 
> >Cc: '[e-mail]' 
> >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/ <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 
> [e-mail]                     FAX:   [phone] 
> http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: [phone] 
> http://www.dynamicsoft.com <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 
> [e-mail] with "subscribe" in the body. 
>