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

["Tom-PT Taylor" <[e-mail]>]

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]]
> 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]]
> >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/
> >~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         PHONE: [phone]
> 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.
>