Subject: [Tsvwg] SDP profile for SCTP.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 12 Mar 2001 06:56:22 -0800

Hi Ian,

Sorry I somehow missed this message - I only saw it while I was browsing the
archive. 

I beleive this capability is beyond the scope of protocol-specific SDP
profiles - SDP is only for session description not session negotiation. The
same situation would exist for RTP/AVP-TCP or anything else.

Of course everyone is waiting for the SDPng but that is still only on the
horizon. On the mmusic mailing list I saw a "hack" proposal for capability
negotiation in SDP.
[http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-01.tx
t] 

In any case, I think this is not an issue that is specific to SCTP and it
would be more appropriate to ensure that this multiprotocol negotiation is
supported by some non-protocol specific means (such as simcap).

Cheers,

Robert.

---
Original Message:
To: Sigtran <[email-masked]>, [email-masked] 
Subject: [Tsvwg] Re: U-SCTP Applications. 
From: Ian Rytina <[email-masked]> 
Date: Fri, 02 Mar 2001 15:59:01 +1100 
CC: [email-masked] 
List-Id: Transport Area Working Group <tsvwg.ietf.org> 
References: <[email-masked]> 
Sender: [email-masked] 

Hi Robert, 
Just to throw another idea into the ring....... 

Regarding the SDP issue, what happens if the receiving end 
doesn't understand what is being sent to it (i.e RTP/AVP-SCTP) ? 
I assume the session has to be re-initiated using RTP/AVP and the 
transport would default to UDP. This extra step of "negotiation" could 
lead to clipping. 

Would it be better to have a new attribute "transports=", with both 
ends advertising their capabilities ? 

e.g. m=audio 6000 RTP/AVP 0 2 
a=transports:SCTP UDP 
a=rtpmap:0 PCMU/8000 
a=rtpmap:2 G726-32/8000 

In this way, both ends know what RTP transports each other supports 
and the sender can decide which one to use. 
Absence of the attribute means the existing RTP transport is used 
(i.e. UDP). 

This method could also be used for advertising other RTP transports, 
(e.g. UDPlite, TCP) without affecting backward compatibility. 

Comments ? Flaws ? 

Cheers, 

Ian. 

"Fairlie-Cuninghame, Robert" wrote: 

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: Ian Rytina <[email-masked]>
Date: Tue, 13 Mar 2001 13:34:51 +1100

Hi Robert,

Yeah, you are probably correct, as far as TCP and SCTP are concerned, I
have come to the same conclusion in the last week or so.......

I think there may be an argument for my idea with regards to UDP and UDPlite,
since you could argue that UDPlite transport is a variant of UDP transport, so
the same <transport> sub-field should be used (RTP/AVP) in the "m=" line.
Then the subsequent attribute line could distinguish between the UDP
variant. I'm not sure whether the SDP experts would view this as "negotiation"
or not - I would say that it is not.

Cheers,

Ian.

"Fairlie-Cuninghame, Robert" wrote:

>
>
> Hi Ian,
>
> Sorry I somehow missed this message - I only saw it while I was browsing the archive.
>
> I beleive this capability is beyond the scope of protocol-specific SDP profiles - SDP
> is only for session description not session negotiation. The same situation would
> exist for RTP/AVP-TCP or anything else.
>
> Of course everyone is waiting for the SDPng but that is still only on the horizon. On
> the mmusic mailing list I saw a "hack" proposal for capability negotiation in SDP.
> [http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-01.txt]
>
> In any case, I think this is not an issue that is specific to SCTP and it would be
> more appropriate to ensure that this multiprotocol negotiation is supported by some
> non-protocol specific means (such as simcap).
>
> Cheers,
>
> Robert.
>
> ---
> Original Message: