Subject: U-SCTP Applications.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 28 Feb 2001 22:49:35 -0800

Hello everyone,

I've only recently started looking at the SCTP proposed standard. The core
SCTP spec seems to be written primarily from the viewpoint that SCTP is for
signalling transport (which is not surprising given the reliable nature of
the base RFC and the name of the WG); however, I note with interest the
addition of the U-SCTP extension. 

In my mind this raises the interesting question: are people startign to look
at SCTP to carry media payload as well as signalling. The U-SCTP draft even
mentions RTP streams in passing. In this case , SCTP could form not only the
Signalling Gateway <--> Softswitch transport mechanism but also the Gateway
<---> Gateway transport mechanism. 

This concept carries the obvious advantages that all inter & intra-domain
traffic uses a single transport protocol and perhaps mroe importantly, that
payload traffic can also leverage the fault-tolerant & bundling (et al)
capabilities of SCTP. In addition, the Stream-based flow limiting extension
also seems to address one more obvious concerns with SCTP carrying both
signalling and media.

I have searched the sigtran mail archive but cannot see any discussion of
SCTP carrying media payload as well as the signalling payload, there may
well be good reasons for this. What is the work groups feeling toward this
application of SCTP ?

Regards,

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 1 Mar 2001 19:32:25 -0800

Copied to sigtran in case people haven't actually moved to tsvwg yet.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert 
> Sent: Friday, March 02, 2001 2:03 PM
> To: 'Randall R. Stewart'; 'Lyndon Ong'
> Cc: [email-masked]
> Subject: RE: U-SCTP Applications.
> 
> 
> Hi Randall & Lyndon, 
> 
> Thank you for your responses.
> 
> As I see it, there are a few issues that need to be looked to 
> make unified media & signalling transport over SCTP work well. 
> 
> However, regardless of any issues, in order to enable any 
> experimentation the most obvious piece of work required to 
> use of SCTP as a payload transport mechanism is the 
> development of an sdp profile for SCTP much in the same way 
> that we developed a sdp profile for tcp in the SIP (& mmusic) 
> working group. 
> http://search.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-t
> cpmedia-00.txt
> [As an aside: I think an IANA category should be opened for 
> SDP profiles (we already have about 6 or so including T.38).]
> 
> Is anyone working on this already or has anyone any ideas for 
> how it should proceed? Should it be similar to the TCP 
> profile in that each side can elect to be passive, active or 
> "don't care"? How should the SCTP association be identified ? 
> The most obvious suggestion is to simply use any one of the 
> SCTP endpoint addresses (since endpoint address cannot belong 
> to multiple SCTP endpoints); however, this assumes that the 
> SCTP association is already active which is probably an 
> unacceptable assumption.
> Comments please!
> 
> As for the U-SCTP for media transport issues: [I'm new to 
> SCTP so please go easy on me <grin>. I'm sure these have been 
> rasied before. Is there a SCTP FAQ yet?]
> 
> -To avoid clipping in VoIP applications, it would be highly 
> desriable to allow U-SCTP packets to be sent as soon as 
> possible. For instance, it may be worth considering accepting 
> (or at least the option of accpeting) U-SCTP DATA chunks 
> before the COOKIE ECHO is received. [Flame away. :)]
> -Avoiding starvation of signalling steeams by high bandwdith 
> payload streams [is the Stream-based flow limiting SCTP 
> extension sufficient?]
> -The "Pushing" of high-priority signalling over media 
> streams. Is it necessary?
> 
> Regards,
> 
> Robert.
> Nuera Communications, Inc.
> 
> > -----Original Message-----
> > From: Randall R. Stewart [mailto:[email-masked]]
> > Sent: Friday, March 02, 2001 1:33 AM
> > To: Fairlie-Cuninghame, Robert
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: U-SCTP Applications.
> > 
> > 
> > Robert:
> > 
> > I know of no conversations we have held on the mailing
> > list(s) on this issue (note SCTP discussion is being
> > moved to the tsvwg mailing list copied above).
> > We did, as you note, have this somewhat in mind when we 
> > wrote the draft. However the primary focus was for IPS. 
> > 
> > At the time we wrote the draft there was quite a bit of 
> > dicussion on the IPS reflector about not wanting reliable 
> > retransmission timers to be firing and at the same time have 
> > a SCSI retransmission fire off as well. This is where the
> > N retransmit came from. 
> > 
> > Now, there are some advantages to using SCTP for RTP. You can
> > pick up RTP multiplexing (for example) for free. But I
> > don't think this is the drafts primary focus.. it may
> > some day be used by RTP but time will tell..
> > 
> > Regards
> > 
> > R
> > 
> > > "Fairlie-Cuninghame, Robert" wrote:
> > > 
> > > Hello everyone,
> > > 
> > > I've only recently started looking at the SCTP proposed 
> > standard. The
> > > core SCTP spec seems to be written primarily from the 
> viewpoint that
> > > SCTP is for signalling transport (which is not surprising 
> given the
> > > reliable nature of the base RFC and the name of the WG); 
> however, I
> > > note with interest the addition of the U-SCTP extension.
> > > 
> > > In my mind this raises the interesting question: are 
> people startign
> > > to look at SCTP to carry media payload as well as signalling. The
> > > U-SCTP draft even mentions RTP streams in passing. In this 
> > case , SCTP
> > > could form not only the Signalling Gateway <--> 
> Softswitch transport
> > > mechanism but also the Gateway <---> Gateway transport mechanism.
> > > 
> > > This concept carries the obvious advantages that all inter &
> > > intra-domain traffic uses a single transport protocol and 
> > perhaps mroe
> > > importantly, that payload traffic can also leverage the 
> > fault-tolerant
> > > & bundling (et al) capabilities of SCTP. In addition, the 
> > Stream-based
> > > flow limiting extension also seems to address one more obvious
> > > concerns with SCTP carrying both signalling and media.
> > > 
> > > I have searched the sigtran mail archive but cannot see any 
> > discussion
> > > of SCTP carrying media payload as well as the signalling payload,
> > > there may well be good reasons for this. What is the work groups
> > > feeling toward this application of SCTP ?
> > > 
> > > Regards,
> > > 
> > > Robert.
> > 
> > -- 
> > Randall R. Stewart
> > [email-masked] or [email-masked]
> > 815-342-5222 (cell) 815-477-2127 (work)
> > 
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 2 Mar 2001 17:33:04 -0800

Allow me to answer myself a little. 

I spoke with David Yon who wrote the original sdp profile for TCP. He has
also just recently published a new draft which generalizes the direction
parameter to any connection-oriented transport protocol:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-00.txt

It lists three protocols: TCP, SCTP and TLS in SDP. He admitted however that
the draft is not sufficient for SCTP and that a separate draft is probably
needed (which he is not working on).

I guess this is a joint mmusic/tsvwg item but I think we should keep the
discussion in tsvwg for a while.

This is my concerns with the genralized scheme:

-Direction pararmeter only need if SCTP connection does not exist.
-A single address in the c= line and a "port" in the m= line is not
sufficient to identify an SCTP stream. We need an additional field to store
	- SCTP tranport port or inbound stream number (depending upon which
value is placed in m= line)
	- SCTP association creation information such that an association can
be created if one does not exist (eg, include auxiliary transport address,
max number of streams, direction etc)
-Specify that an existing SCTP association must be used if found. (That is,
whilst multiple sessions can specify/share the same SCTP trasnport
address(es), transport addressed cannot be shared between multiple SCTP
associations)
-Enhancement of "redundant both" direction mechanism to avoid creating two
SCTP connections.  Perhaps disallow the "redundant both" connection mode for
SCTP? [easiest] Is firewall traversal a lesser issue/requirement for SCTP
(verse say TCP)? Or propose a more complicated backoff/resolution process.
-Clarify the meaning/handling of send-only/recv-only/sendrecv a= parameters
(given unidirctional stream nature). I think for send-only and recv-only one
of the stream numbers should be ignored (preferably set an invalid value
such as the maximum number of streams).

An example SDP body:

v=0
o=- 0 0 IN IP4 1.2.3.4
s=-
t=0 0
c=IN IP4 1.2.3.4
a=sctp-port: 5000				   <--- used to identify
SCTP association
a=sctp-assoc: 1.2.3.5,1.2.4.6 256 both <--- addresses, # of streams and
direction
							(used if association
does not exist;
							the indication of
max streams would be
							more an indication
to the _sending_
							media gateway of the
value to place in 
							INIT).
m=audio 32 RTP/AVP-USCTP 0 12		   <--- inbound stream id's used in
m line.
m=video 34 RTP/AVP-SCTP 0 12
m=data 36 SCTP whatever
m=data 37 USCTP whatever

Comments please.

Robert.