Subject: [SIP] SCTP as transport for SIP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 8 Mar 2001 06:43:29 -0800

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?

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.]

Does this not mean that we need to add an SCTP stream id URL parameter ?

For instance, some lookup yields a SIP URL (ie Request-URI) of 
sip:host.company.com;transport=sctp;sctp-stream=13 (or something else -
maybe "transport=sctp-13")

and then the Via: would similarly need to specify the reverse stream (which
may very easily be to a different stream or even to a different SCTP port).

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.

Regards, 

Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 11:53:54 -0500

-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
>Sent: Thursday, March 08, 2001 9:43 AM
>To: [email-masked]'; [email-masked]'
>Cc: [email-masked]'
>Subject: SCTP as transport for SIP
>
>
>Hi there, 
(http://www.cs.columbia.edu/
>~hgs/sip/drafts/draft-rosenberg-sip-sctp-00.txt),
>
>For instance: 
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
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
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 
[email-masked] with "subscribe" in the body.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 14 Mar 2001 09:52:19 -0800

Hi Jonathan,

Thanks for the reply.

> signaled out of band in order to setup an SCTP association?

As far as I know, the number (and type) of streams are negotiated when the
SCTP association (which is between SCTP endpoints not media endpoints) is
established. Once that association is established then data can be sent on
any stream without further negotiation (as can be seen in 5.1.6). So I was
not saying that the opening and closing of streams needs to be signalled in
SIP, rather I was saying that the identity of the appropriate stream must be
signalled.

> of them. Again, I could be mistaken and would welcome comment 

I disagree with this. Just because an application opens 10 streams does not
mean that all ten streams go to the same receive process. To me, this would
largely defaeats the purpose (from an application standpoint - not a
transport standpoint) of using separate streams. For instance, you could
have RTP media on one stream and be expecting SIP requests on another
(within the same application). The RTP receive handler is simply going to
reject any received SIP request. 

SCTP is a transport protocol not an API. Your are discussing API issues
(whether or not separaate applications can share a single assocation;
whether streams are listened to individually or as a group). I don't think
that is a good idea - we should not be judging what applications should or
should not be doing. In my mind, we should simply be working out how to
specify/identify the SCTP transport stream used to reach a remote entity. 

Now of course you can entirely statically configure which streams are used
for what purposes (for each direction and for each association). This maybe
an adequate solution for small systems, I do not beleive it is a long term
or desriable approach. The reverse path information should be conveyed in
the SIP plane and the forward path information determinable from a SIP URL. 

As an aside: I beleive that for good system design, SCTP association
configuration should be application independent (ie separate). That is,
determination of which stream is used for SIP messages should be separate to
the basic SCTP association information (transport address sets, number of
streams, shared secrets, etc). 

Combining the preceeding properties allows the application-specific (ie,
SIP-related) SCTP configuration to be obtained from a protocol-independent
lookup and then the transport specific information to be resolved in an
application-independent manner.

It should also be noted that the concept of a "standard" SIP port does not
exist for SCTP. The port MUST be different for each SCTP association (ie for
every IP address to which a server has associations). This will probably
cause problems for using DNS lookups which will have to take into account
where the DNS request is coming from in order to choose the correct SCTP
port.

Cheers,

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 15 Mar 2001 04:33:50 -0800

I wish to amend/correct something I said from my last email on the subject. 
 
I previously said:
" It should also be noted that the concept of a "standard" SIP port does not
port. " 
 
I actually was referring to the fact that SCTP transport addresses (ie IP
address and port) are unique to each SCTP endpoint. This however does not
necessarily mean that the port must be different for each SCTP association
or that the same port cannot be used for different addresses AS LONG AS all
SIP requests are processed/handled by the same SCTP endpoint. The port must
be different if different SCTP endpoints are used for associations between
different locations (for instance because they use a different shared secret
or because of configuration).
 
It does however mean that IF the DNS SRV (or whatever) lookup is not to be a
function of the source address/port, THEN the SIP server must use the same
stream to receive requests on all associations AND the same SCTP endpoint is
used for all SIP requests. This also infers either some sort of exclusive
ownership of the SCTP endpoint or co-operative/reserved assignments of
streams for that SCTP endpoint, however, that is beyond the scope of SIP
which simply needs to know the stream to use.
 
Sorry for the confusion.
 
Cheers,
 
Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 5:52 PM
To: 'Jonathan Rosenberg'; [email-masked]'
Cc: [email-masked]'
Subject: [SIP] RE: SCTP as transport for SIP

Hi Jonathan, 

Thanks for the reply. 

Cheers, 

Robert.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Mar 2001 10:33:06 -0500

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.    

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 11:54 AM
> To: 'Fairlie-Cuninghame, Robert'; [email-masked]';
> Jonathan Rosenberg

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 17 Mar 2001 08:28:55 -0800

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:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, March 15, 2001 3:33 PM
To: 'Jonathan Rosenberg'; 'Fairlie-Cuninghame, Robert';
[email-masked]'
Cc: [email-masked]' <mailto:[email-masked]'> 
Subject: RE: [SIP] RE: SCTP as transport for SIP

> From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> >From: Fairlie-Cuninghame, Robert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> ( http://www.cs.columbia.edu/ <http://www.cs.columbia.edu/>  
> http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000 
> http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
>  
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 17 Mar 2001 08:28:57 -0800

> 
> I think that such a generic adaptation layer is a bad idea.
> 
> The reason is that one already exists - port numbers. Doing 
> what Robert is
> describing will require not just SIP, but *every* application 
> and system
> that uses port numbers to now incorporate another demux 
> identifier, the SCTP
> stream ID. We'd need to update DNS specifications, NATs, IANA 
> registrations,
> and the whole nine yards. I'd rather not. I just don't see a 
> need for yet
> another layer of demux.
> 
> So, given that just SIP runs over an SCTP association, since 
> the association
> is setup by SIP, any stream can be used by SIP, and we are 
> back to where we
> started, which is that nothing extra is required for SCTP.
> 

Hi Jonathan,

As I said in my last email, I agree that there are problems and I do not
propose to have all the answers. 

However, if we are going to use SCTP for SIP then we should do it properly.
Each association has both internal and network overhead associated with it
(unlike TCP which only has internal overhead). SIP Proxies and gateways
often use the port field to perform state machine demux - this would result
in a huge number of associations if each had to have its own association
(because it uses a different port). This is doubled if both sides use this
technique. [Obviously this would not be a good way of implementing things
for a proxy using SCTP.]

I think that most of the cases that you mentioned need changing (DNS, NATS,
IANA) are independent of this argument. In order to make anything use SCTP
transport then it must be able to specify or understand SCTP parameters to
some extent (so you've already gone 7 of those 9 yards). For instance, if
SIP UA/proxy understands the transport=SCTP option thenn it is should also
be able to understand other options. 

Ok let's take a look at your suggestion that SIP may send/recv to any stream
in an association. In my mind it would at least be better to say that if a
service is not dynamically negotiated or statically configured [ie, known to
be otherwise] then it should be assumed to be sending/recving on the first
(zeroth) stream in the association. This assumes that one application is
controlling an SCTP endpoint (which I don't think is a bad assumption) and
that service can be located by doing a plain old DNS lookup without any need
for specifying a stream in the response. Then at least sub-services (also
controlled by the application) can make use of the other streams in the same
association by using SCTP-aware negotiation or specification.

Many media-based application layer protcols are made to be transport-layer
independent (ie, carry no transport layer information in the packets), eg,
RTP. So for instance SDP can be easily expanded to encompass SCTP which
covers a lot of the ground for negotiation in media-based application. 

Making the default stream in both directions be zero at least allows you to
introduce changes/extensions incrementally rather than locking them out
entirely.

Robert.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Mar 2001 10:08:24 -0500

There are two issues here: SIP-level assignment to streams and SDP-level
assignment to streams (which applies only to media flows).
 
At the SIP level: let me point out that SCTP actually allows protocol
multiplexing at the stream level.  Each DATA chunk has its own protocol
identifier as well as stream identifier.  An application must therefore be
prepared to monitor all streams in an association and receive relevant data
from any stream UNLESS we standardize more restrictive behaviour.  Quite
frankly, I don't see why we should do so.  Certainly, requiring that all SIP
signalling use stream 0 by default is far too restrictive.
 
At the media level, I could see a case for specifying the stream number for
a given media flow within the SDP.  Again, this isn't totally necessary, but
it makes more sense than in the SIP case.  It's obvious that you can't
multiplex data to be delivered reliably and data to be delivered unreliably
within the same SCTP packet.  That can be taken care of by specifying
per-packet behaviour in the SCTP layer, and probably has to be.  (I haven't
read Randy's draft yet.)  However, dedicating specific streams to media
transport seems like logical application behaviour. 
 
 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 11:29 AM
To: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

Hi Jonathan, 

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 23 Mar 2001 08:17:11 -0800

Ok, let's sneak this reply in between the IETF and the bakeoff. 
 
I disagree with your conclusions. First of all I would like to rule out
demultiplexing of protocols via the payload id. In my mind, this is akin to
demultiplexing multiple RTP sessions by using the SSRC - ugly. It all boils
done to the fact that an SCTP stream provides a number of properties - it is
NOT just an arbitrary demultiplexing value like UDP ports. Likewise, in my
mind sending unrelated reliable and unrelible data flows using differing
per-packet behaviours is again ugly and misses the point of SCTP. There are
reason why we have SCTP streams - so that logical flows can be separated
(each with its own delivery parameters) without this sort of ugliness (see
Footnote 1). 
 
I can not see how this whole idea of saying that SIP can arbitrarily send on
streams without even specifying which it will be using is:
a) not a very good design - if you are going to use multiple streams then it
should be specified.
b) specifying API implementation
c) not allowing future extensions of SIP to properly use or negotiate the
use of within the association (because you have arbitrarily used _all_
streams).
 
If you are saying that an SCTP enabled SIP UA/proxy may use a separate
stream per transaction or per call to overcome head of line blocking then I
would say that you should be instead be using an the unordered reliable
delivery option on a single stream. If the stream cannot be specified, then
what way is the receiving SIP device able to use that separation of the
streams for any benefit ? It can't. So if the recieving UA/proxy can't
separate the streams then the SIP device may as well use stream 0 for all
unspecified streams in an unordered reliable delivery manner. 
 
Summary: To arbitrarily send on any stream in SIP (ie, without stream
specification) is effectively wasting any usefulness provided by SCTP
streams and rules out any future improvements. Why do you feel that using
arbitrary streams (without specification) is a) a good idea and b) better
than using a single unordered (or ordered) reliable stream ?
 
Regards,
 
Robert.
 
Footnote 1: The U-SCTP draft requires that a stream is explicitly configured
as either relaible or unreliable. Arbitrarily/unnecessarily over-riding this
transport property with per-packet behaviours should not be encouraged in my
mind. 

 

 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 11:29 AM
To: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

Hi Jonathan, 

Robert.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 24 Mar 2001 09:26:32 -0500

I wonder if we are miscommunicating because we see difference usage of the
SCTP association.  I am assuming the use of SCTP between entities handling
multiple calls at once, (e.g proxy-proxy, or proxy-gateway UA).  I am also
assuming a stream utilization logic at both ends as follows:
 
 (1) For each new call-leg, the UA chooses which outgoing stream it will
associate with the call-leg.  Note that this decision is made independently
at each end because streams are unidirectional.
 (2) It sends all messages pertaining to that call-leg, whether they are
requests or responses, in the same stream.  This constraint may be one we
want to add to the core spec.
 (3) It listens for SIP messages on all incoming streams providing ordered
service.  Note that you may spawn different threads to receive messages from
different streams, but the complete association has to be managed by a
single process.
 
The purpose of using streams is to reduce interference between different
call-legs while providing ordering within each.  
 
I think you are asking for a means within the protocol to indicate which
streams within an association can be used for SIP.  Since this is a
configuration issue which has to be settled outside the bounds of any one
call, the only possibility I can see is to indicate within a REGISTER that
your UA is prepared to support SCTP, and also to indicate a range of stream
numbers on which it is prepared to support SIP.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Saturday, March 24, 2001 7:12 AM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

Damn I hate it when I find problems in my own suggestions. Using an
unordered reliable channel may increase the likelihood of an INVITE being
delivered after a CANCEL (and other quirky situations). Good SIP
implementations should be able to handle this (as out-of-order delivery is
quite possible in normal UDP) but it may produce more confusion in some
implementations. So is it worth using multiple reliable ordered streams for
each transaction or call-leg to overcome any head-of-line blocking in a
single ordered reliable stream? Maybe. As I've said in a previous email, it
rules out using any other streams in the association for other purposes (in
a clean manner) and makes it difficult for the reciever to make use of the
separation. Is this a worthwhile tradeoff ?
 
The alternative is to allow the specification of which stream to use in the
contact & via. This allows the separation of streams but additionally allows
the receiving side to also make use of this separation. In the long run, I
think this is a better solution for more efficient use of SCTP associations.
Jonathan, you still have reservations ?
 
Cheers,
 
Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, March 23, 2001 4:17 PM
To: 'Tom-PT Taylor'
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

 

 
Regards,
 
Robert.

 

 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 11:29 AM
To: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

Hi Jonathan, 

Robert.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Mar 2001 12:00:08 -0500

Let me set the record straight on fragmentation, which seems to be causing
general confusion.  First, we are talking about user message fragmentation
and reassembly.  The chunk is a unit of transport within the SCTP packet; it
may contain a fragment but is not itself fragmented.  Secondly, the direct
effect of a missing fragment of a message for which ordered delivery has
been requested is to hold up delivery of the affected message and subsequent
messages in the same stream.  The indirect effect of a missing fragment MAY
be to slow down flows across the entire association as windows adapt to
perceived congestion.  However, messages which do get across are delivered
immediately if they are in streams other than the one the missing fragment
belongs to.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 9:49 AM
> To: Gonzalo Camarillo
> Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B881:EXCH];
> 'Fairlie-Cuninghame, Robert'; [email-masked]';
> [email-masked]'
> Subject: Re: [SIP] RE: SCTP as transport for SIP
> 
> 
> Gonzalo,
> 
> Gonzalo Camarillo wrote:                      (Tue, 27 Mar 
> 2001 17:34:55)
> > 
> > However, SIP applications will most likely use an SCTP 
> interface that
> > does not allow to read this flag. And even it they could 
> read the flag,
> > the pain of implementing such a priority queue in the 
> application is not
> > worthwhile.
> > 
> Socket interface permits normal MSG_OOB flags.  Not too tough to have
> one thread recvmsg with MSG_OOB set, the other not.
> 
> > 
> > This has nothing to do with what we are talking about. We 
> are talking
> > about unordered messages.
> 
> If fragmented, your unordered messages will be delivered ordered.
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>