1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Network Working Group J. Rosenberg
Request for Comments: 4168 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
October 2005
<span class="h1">The Stream Control Transmission Protocol (SCTP)</span>
<span class="h1">as a Transport for the Session Initiation Protocol (SIP)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport mechanism between SIP
(Session Initiation Protocol) entities. SCTP is a new protocol that
provides several features that may prove beneficial for transport
between SIP entities that exchange a large amount of messages,
including gateways and proxies. As SIP is transport-independent,
support of SCTP is a relatively straightforward process, nearly
identical to support for TCP.
<span class="grey">Rosenberg, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Potential Benefits ..............................................<a href="#page-2">2</a>
<a href="#section-3.1">3.1</a>. Advantages over UDP ........................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Advantages over TCP ........................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Transport Parameter .............................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. SCTP Usage ......................................................<a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. Mapping of SIP Transactions into SCTP Streams ..............<a href="#page-5">5</a>
<a href="#section-6">6</a>. Locating a SIP Server ...........................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-7">7</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-9">9</a>. References ......................................................<a href="#page-7">7</a>
<a href="#section-9.1">9.1</a>. Normative References .......................................<a href="#page-7">7</a>
<a href="#section-9.2">9.2</a>. Informative References .....................................<a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Stream Control Transmission Protocol (SCTP) [<a href="#ref-4" title=""Stream Control Transmission Protocol"">4</a>] has been designed
as a new transport protocol for the Internet (or intranets) at the
same layer as TCP and UDP. SCTP has been designed with the transport
of legacy SS7 signaling messages in mind. We have observed that many
of the features designed to support transport of such signaling are
also useful for the transport of SIP (the Session Initiation
Protocol) [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>], which is used to initiate and manage interactive
sessions on the Internet.
SIP itself is transport-independent, and can run over any reliable or
unreliable message or stream transport. However, procedures are only
defined for transport over UDP and TCP. This document defines
transport of SIP over SCTP.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Potential Benefits</span>
<a href="./rfc3257">RFC 3257</a> presents some of the key benefits of SCTP [<a href="#ref-10" title=""Stream Control Transmission Protocol Applicability Statement"">10</a>]. We
summarize some of these benefits here and analyze how they relate to
SIP (a more detailed analysis can be found in [<a href="#ref-12" title=""Evaluation of Transport Protocols for the Session Initiation Protocol"">12</a>]).
<span class="grey">Rosenberg, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Advantages over UDP</span>
All the advantages that SCTP has over UDP regarding SIP transport are
also shared by TCP. Below, there is a list of the general advantages
that a connection-oriented transport protocol such as TCP or SCTP has
over a connection-less transport protocol such as UDP.
Fast Retransmit: SCTP can quickly determine the loss of a packet,
because of its usage of SACK and a mechanism that sends SACK
messages faster than normal when losses are detected. The result
is that losses of SIP messages can be detected much faster than
when SIP is run over UDP (detection will take at least 500 ms, if
not more). Note that TCP SACK exists as well, and TCP also has a
fast retransmit option. Over an existing connection, this results
in faster call setup times under conditions of packet loss, which
is very desirable. This is probably the most significant
advantage of SCTP for SIP transport.
Congestion Control: SCTP maintains congestion control over the entire
association. For SIP, this means that the aggregate rate of
messages between two entities can be controlled. When SIP is run
over TCP, the same advantages are afforded. However, when run
over UDP, SIP provides less effective congestion control. This is
because congestion state (measured in terms of the UDP retransmit
interval) is computed on a transaction-by-transaction basis,
rather than across all transactions. Thus, congestion control
performance is similar to opening N parallel TCP connections, as
opposed to sending N messages over one TCP connection.
Transport-Layer Fragmentation: SCTP and TCP provide transport-layer
fragmentation. If a SIP message is larger than the MTU size, it
is fragmented at the transport layer. When UDP is used,
fragmentation occurs at the IP layer. IP fragmentation increases
the likelihood of having packet losses and makes NAT and firewall
traversal difficult, if not impossible. This feature will become
important if the size of SIP messages grows dramatically.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Advantages over TCP</span>
We have shown the advantages of SCTP and TCP over UDP. We now
analyze the advantages of SCTP over TCP.
Head of the Line: SCTP is message-based, as opposed to TCP, which is
stream-based. This allows SCTP to separate different signalling
messages at the transport layer. TCP only understands bytes.
Assembling received bytes to form signalling messages is performed
at the application layer. Therefore, TCP always delivers an
<span class="grey">Rosenberg, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
ordered stream of bytes to the application. On the other hand,
SCTP can deliver signalling messages to the application as soon as
they arrive (when using the unordered service). The loss of a
signalling message does not affect the delivery of the rest of the
messages. This avoids the head of line blocking problem in TCP,
which occurs when multiple higher layer connections are
multiplexed within a single TCP connection. A SIP transaction can
be considered an application layer connection. There are multiple
transactions running between proxies. The loss of a message in
one transaction should not adversely effect the ability of a
different transaction to send a message. Thus, if SIP is run
between entities with many transactions occurring in parallel,
SCTP can provide improved performance over SIP over TCP (but not
SIP over UDP; SIP over UDP is not ideal from a congestion control
standpoint; see above).
Easier Parsing: Another advantage of message-based protocols, such as
SCTP and UDP, over stream-based protocols, such as TCP, is that
they allow easier parsing of messages at the application layer.
There is no need to establish boundaries (typically using
Content-Length headers) between different messages. However, this
advantage is almost negligible.
Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the
addresses, but if it becomes unreachable, data sent to one can
migrate to a different address. This improves fault tolerance;
network failures making one interface of the server unavailable do
not prevent the service from continuing to operate. SIP servers
are likely to have substantial fault tolerance requirements. It
is worth noting that, because SIP is message oriented and not
stream oriented, the existing SRV (Service Selection) procedures
defined in [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>] can accomplish the same goal, even when SIP is run
over TCP. In fact, SRV records allow the 'connection' to fail
over to a separate host. Since SIP proxies can run statelessly,
failover can be accomplished without data synchronization between
the primary and its backups. Thus, the multihoming capabilities
of SCTP provide marginal benefits.
It is important to note that most of the benefits of SCTP for SIP
occur under loss conditions. Therefore, under a zero loss condition,
SCTP transport of SIP should perform on par with TCP transport.
Research is needed to evaluate under what loss conditions the
improvements in setup times and throughput will be observed.
<span class="grey">Rosenberg, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Transport Parameter</span>
Via header fields carry a transport protocol identifier. <a href="./rfc3261">RFC 3261</a>
defines the value "SCTP" for SCTP, but does not define the value for
the transport parameter for TLS over SCTP. Note that the value
"TLS", defined by <a href="./rfc3261">RFC 3261</a>, is intended for TLS over TCP.
Here we define the value "TLS-SCTP" for the transport part of the Via
header field to be used for requests sent over TLS over SCTP [<a href="#ref-8" title=""Transport Layer Security over Stream Control Transmission Protocol"">8</a>].
The updated augmented BNF (Backus-Naur Form) [<a href="#ref-2" title=""Augmented BNF for Syntax Specifications: ABNF"">2</a>] for this parameter
is the following (the original BNF for this parameter can be found in
<a href="./rfc3261">RFC 3261</a>):
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport
The following are examples of Via header fields using "SCTP" and
"TLS-SCTP":
Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SCTP Usage</span>
Rules for sending a request over SCTP are identical to TCP. The only
difference is that an SCTP sender has to choose a particular stream
within an association in order to send the request (see <a href="#section-5.1">Section 5.1</a>).
Note that no SCTP identifier needs to be defined for SIP messages.
Therefore, the Payload Protocol Identifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero.
The SIP transport layers of both peers are responsible for managing
the persistent SCTP connection between them. On the sender side, the
core or a client (or server) transaction generates a request (or
response) and passes it to the transport layer. The transport sends
the request to the peer's transaction layer. The peer's transaction
layer is responsible for delivering the incoming request (or
response) to the proper existing server (or client) transaction. If
no server (or client) transaction exists for the incoming message,
the transport layer passes the request (or response) to the core,
which may decide to construct a new server (or client) transaction.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Mapping of SIP Transactions into SCTP Streams</span>
SIP transactions need to be mapped into SCTP streams in a way that
avoids Head Of the Line (HOL) blocking. Among the different ways of
performing this mapping that fulfill this requirement, we have chosen
<span class="grey">Rosenberg, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
the simplest one; a SIP entity SHOULD send every SIP message (request
or response) over stream zero with the unordered flag set. On the
receiving side, a SIP entity MUST be ready to receive SIP messages
over any stream.
In the past, it was proposed that SCTP stream IDs be used as
lightweight SIP transaction identifiers. That proposal was
withdrawn because SIP now provides (as defined in <a href="./rfc3261">RFC 3261</a> [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>]) a
transaction identifier in the branch parameter of the Via entries.
This transaction identifier, missing in the previous SIP spec [<a href="#ref-9" title=""SIP: Session Initiation Protocol"">9</a>],
makes it unnecessary to use the SCTP stream IDs to demultiplex SIP
traffic.
In many circumstances, SIP requires the use of TLS [<a href="#ref-3" title=""The TLS Protocol Version 1.0"">3</a>], for instance,
when routing a SIPS URI [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>]. As defined in <a href="./rfc3436">RFC 3436</a> [<a href="#ref-8" title=""Transport Layer Security over Stream Control Transmission Protocol"">8</a>], TLS running
over SCTP MUST NOT use the SCTP unordered delivery service.
Moreover, any SIP use of an extra layer between the transport layer
and SIP that requires ordered delivery of messages MUST NOT use the
SCTP unordered delivery service.
SIP applications that require ordered delivery of messages from the
transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
same SIP transaction over the same SCTP stream. Additionally, they
SHOULD send messages belonging to different SIP transactions over
different SCTP streams, as long as there are enough available
streams.
A common scenario where the above mechanism should be used
consists of two proxies exchanging SIP traffic over a TLS
connection using SCTP as the transport protocol. This works
because all of the SIP transactions between the two proxies can be
established within one SCTP association.
Note that if both sides of the association follow this
recommendation, when a request arrives over a particular stream, the
server is free to return responses over a different stream. This
way, both sides manage the available streams in the sending
direction, independently of the streams chosen by the other side to
send a particular SIP message. This avoids undesirable collisions
when seizing a particular stream.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Locating a SIP Server</span>
The primary issue when sending a request is determining whether the
next hop server supports SCTP so that an association can be opened.
SIP entities follow normal SIP procedures to discover [<a href="#ref-6" title=""Session Initiation Protocol (SIP): Locating SIP Servers"">6</a>] a server
that supports SCTP.
<span class="grey">Rosenberg, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
However, in order to use TLS on top of SCTP, an extra definition is
needed. <a href="./rfc3263">RFC 3263</a> defines the NAPTR (Naming Authority Pointer) [<a href="#ref-7" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">7</a>]
service value "SIP+D2S" for SCTP, but fails to define a value for TLS
over SCTP. Here we define the NAPTR service value "SIPS+D2S" for
servers that support TLS over SCTP [<a href="#ref-8" title=""Transport Layer Security over Stream Control Transmission Protocol"">8</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security issues raised in <a href="./rfc3261">RFC 3261</a> [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>] are not worsened by SCTP,
provided the advice in <a href="#section-5.1">Section 5.1</a> is followed and TLS over SCTP [<a href="#ref-8" title=""Transport Layer Security over Stream Control Transmission Protocol"">8</a>]
is used where TLS would be required in <a href="./rfc3261">RFC 3261</a> [<a href="#ref-5" title=""SIP: Session Initiation Protocol"">5</a>] or in <a href="./rfc3263">RFC 3263</a>
[<a href="#ref-6" title=""Session Initiation Protocol (SIP): Locating SIP Servers"">6</a>]. So, the mechanisms described in <a href="./rfc3436">RFC 3436</a> [<a href="#ref-8" title=""Transport Layer Security over Stream Control Transmission Protocol"">8</a>] MUST be used when
SIP runs on top of TLS [<a href="#ref-3" title=""The TLS Protocol Version 1.0"">3</a>] and SCTP.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document defines a new NAPTR service field value (SIPS+ D2S).
The IANA has registered this value under the "Registry for the SIP
SRV Resource Record Services Field". The resulting entry is as
follows:
Services Field Protocol Reference
-------------------- -------- ---------
SIPS+D2S SCTP [<a href="./rfc4168">RFC4168</a>]
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc2234">RFC 2234</a>, November 1997.
[<a id="ref-3">3</a>] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", <a href="./rfc2246">RFC</a>
<a href="./rfc2246">2246</a>, January 1999.
[<a id="ref-4">4</a>] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", <a href="./rfc2960">RFC 2960</a>, October 2000.
[<a id="ref-5">5</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-6">6</a>] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", <a href="./rfc3263">RFC 3263</a>, June 2002.
<span class="grey">Rosenberg, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
[<a id="ref-7">7</a>] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", <a href="./rfc3403">RFC 3403</a>, October
2002.
[<a id="ref-8">8</a>] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", <a href="./rfc3436">RFC 3436</a>,
December 2002.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-9">9</a>] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", <a href="./rfc2543">RFC 2543</a>, March 1999.
[<a id="ref-10">10</a>] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", <a href="./rfc3257">RFC 3257</a>, April 2002.
[<a id="ref-11">11</a>] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", <a href="https://www.rfc-editor.org/bcp/bcp99">BCP 99</a>, <a href="./rfc3969">RFC 3969</a>, December
2004.
[<a id="ref-12">12</a>] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of
Transport Protocols for the Session Initiation Protocol", IEEE,
Network vol. 17, no. 5, 2003.
<span class="grey">Rosenberg, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
Authors' Addresses
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: <a href="http://www.jdrosen.net">http://www.jdrosen.net</a>
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
US
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
<span class="grey">Rosenberg, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4168">RFC 4168</a> SCTP as a Transport for SIP October 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg, et al. Standards Track [Page 10]
</pre>
|
