[Tsvwg] RE: U-SCTP Applications.

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

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-tcpmedia-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:[e-mail]]
> Sent: Friday, March 02, 2001 1:33 AM
> To: Fairlie-Cuninghame, Robert
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail] or [e-mail]
> 815-342-5222 (cell) 815-477-2127 (work)
>