sip over sctp
DESCRIPTION
sip over sctpTRANSCRIPT
SIP over SCTP
1 Introduction...............................................................................................................................................2 2 Test Bed....................................................................................................................................................3
2.1 lksctp project......................................................................................................................................3 2.2 Dissipate Library................................................................................................................................4
3 SCTP as Transport for SIP: tests ..............................................................................................................5 3.1 Performance of Sip Call Setup using SCTP ......................................................................................5
3.1.1 Advantages over UDP .................................................................................................................5 3.1.2 Advantages over TCP .................................................................................................................6 3.1.3 SIP over SCTP ............................................................................................................................8
3.2 Interaction of a Sip transaction between various protocols .............................................................10 3.3 Open Issues ......................................................................................................................................12
6 SCTP as Signaling Transport Protocols..................................................................................................13 7 The implementation ................................................................................................................................14 8 Installation instructions...........................................................................................................................17 9 User Interface..........................................................................................................................................19 10 Test User Interface ................................................................................................................................24 11 References .............................................................................................................................................26
1 Introduction With this work we want to obtain experimental results showing SCTP’s real benefits. We will compare SCTP with already existing transport protocol and will analyze which real gains SCTP brings. At present there aren’t SIP implementation use SCTP as transport. So we have developed a new SIP client that can to run over all type of transport protocol: UDP, TCP, SCTP.
2 Test Bed Hardware Only two computers form the Test Bed: One is a desktop : Pentium IV, 260 MB ram, and two 3com Ethernet card 10/100 The other is a portable: Pentium III, 260 MB ram, and one PCMCIA Ethernet card 10 Mb The two computers are connected in net and in Internet through a Digicom Switch10/100 O.S. and Softwares Linux Red Hat 7.3 distribution, with KDE as graphic desktop. Kernel 2.5.67 with “lksctp project” dissipate library KPhone
2.1 lksctp project lksctp goal is to coordinate the continuing development of the SCTP kernel reference code, and to help disseminate information about SCTP. The SCTP kernel reference code is primarily developed at Motorola, but many people around the world help out. The reference code is completely Open Source and follows the current development of the Linux kernel. LKSCTP is the Linux kernel implementation of SCTP, it will be included in kernel 2.6 with following features • Message oriented, reliable transport protocol • Direct support for multi-homing • Runs on top of Internet Protocol (IPV4,6) • Connection-oriented data delivery • Congestion Control • In addition to TCP features: – Message Framing – Ordered and Unordered Message Delivery
– Multi-streaming – Multi-homing • Accepted in Kernel 2.5.33 • http://lksctp.sourceforge.net
2.2 Dissipate Library libdissipate is a library for developping applications based on the SIP signalling protocol defined in RFC3261. It can make and accept calls using SIP over UDP.
It is released under the GNU GPL license, with a provision that you can link it with Qt. The code has been tested on Linux and Solaris, but other OSs may also work.
We are modifying these library, like that be now further on support the SIP Use On UDP, also the use of SIP On TCP and SCTP. For the support of SCTP we have used a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API as referenced in [6]. In particular we have preferred the support a UDP-style interface: “This set of semantics is similar to that defined for connectionless protocols, such as UDP. It is more efficient than a TCP-like connection-oriented interface in terms of exploring the new features of SCTP”[6]
3 SCTP as Transport for SIP: tests For testing the working of the Sip Client, SCTP Kphone, on transport protocol SCTP, we are reporting to as specified in the draft “SCTP as a transport for SIP” [1]. Principally we want evaluate:
1) the possible advantage of SCTP over TCP (HOL blocking avoidance): the results of simulation are correct, or are they due to that implementation of stack SCTP ?
what are the advantages of a lightweight mechanism to perform transaction identification (mapping of SIP transaction into streams?)
3.1 Performance of Sip Call Setup using SCTP We want to evaluate, mainly two aspect:
- The delay of "Call Setup" to consider the middle delay of "Call Setup" - Evaluate, through a middle number of calls for seconds, the average delays of the "call setup"
3.1.1 Advantages over UDP To do.
3.1.2 Advantages over TCP To do
SYN
SYN
SYN
ACK INVITE
6 Secondi Only after this gap
INVITE is sent
Figure 3-1 delay in TCP initialisation
To do
1,5 secondi
1:500 (INVITE)
1:500 (INVITE)
ack 500
Figure 3-2 slow retransmission in TCP
To do
1,5 secondi
1:500(sessione 1:INVITE)
500:1000 (sessione 2:INVITE)
ack 500
ack 1
1:500(sessione 1:INVITE)
Figure 3-3 Fast Retrasmit in TCP
To do
1:500(sessione 1:INVITE)
500:1000 (sessione 2:INVITE)
ack 1
1:500(sessione 1:INVITE)
Figure 3-4 TCP Head of line blocking effects
3.1.3 SIP over SCTP 3.1.3.1 Multistreaming To do
INVITE TSN=6, Stream Id=3, Stream Seq=0
INVITE TSN=5, Stream Id=2, Stream Seq=0
100 TRYING TSN=4, Stream Id=3, Stream Seq=0
SACK TSN=4, GapAckBlock:TSN=6
INVITE of session combine to stream 3 Is delivered at ULP nevertheless the loss INVITE in stream 2
INVITE TSN=5, Stream Id=2, Stream Seq=0
PROXY-SERVER PROXY SERVER
Figure 3-5 SIP with multistreaming SCTP
To do
180 RINGING TSN=4, Stream Id=2, Stream Seq=1
100 TRYING TSN=3, Stream Id=2, Stream Seq=0
200 OK TSN=5, Stream Id=2, Stream Seq=2
SACK TSN=3, GapAckBlock:TSN=5
Only now 200 OK is delivered, together 180 RINGING 180 RINGING TSN=4, Stream Id=2, Stream Seq=1
Figure 3-6 Final before provisional response
3.1.3.2 Unordered delivery To do
INVITE TSN=6, Stream Id=0 Unordered
INVITE TSN=5, Stream Id=0 Unordered
100 TRYING TSN=4, Stream Id=0 Unordered
SACK TSN=4, GapAckBlock:TSN=6
INVITE is delivered instantly though if the
previous was lost
PROXY-SERVER PROXY SERVER
Figure 3-7 SIP messages sent with unordered delivery
To do
CANCEL TSN=6, Stream Id=0 Unordered
INVITE TSN=5, Stream Id=0 Unordered
481 TSN=4, Stream Id=0 Unordered
SACK TSN=4, GapAckBlock:TSN=6
INVITE TSN=5, Stream Id=0 Unordered
PROXY-SERVER PROXY SERVER
Figure 3-8 Problem CANCEL arrives before an INVITE
I have just read your document. One comment about Figure 3-8. I pointed out that problem in an old paper, but then I solved it in RFC 3261. Now proxies wait for the 100 Trying before sending the CANCEL. Therefore, you can remove that figure from the document, since it is not a problem anymore. (GONZALO MAIL del 30-05-2003)
3.2 Interaction of a Sip transaction between various protocols In literature on the SCTP use for SIP, two are the main conclusions: ??In the communication between User Agent and Proxy is worthwhile to use a not connected
transport protocol as UDP ??In the Proxy to Proxy communication is worthwhile to use a connected protocol as TCP
This conclusions derived by the comparison of the various scenarios, every one examined separately. Would be opportune studying what are the problems that can spring in the integration between the various backgrounds. In a scenario as in the following figure, they can there be three types of messages loss in the UDP link that influence in the SCTP link. We are supposing that Proxy as Stateless Sip Proxy. User Agent User Agent PROXY PROXY
UDP UDP SCTP
1) The loss of a 180 Ringing in the first UDP link
INVITE INVITE
INVITE
INVITE INVITE
INVITE
180 RING 180 RINGING
180 RINGING 0,5 sec
2) The loss of a BYE in the last link UDP
BYE BYE BYE
BYE BYE
200 Ok
200 Ok 0,5 sec
BYE
200 Ok 200 Ok
3) The loss of an ACK, in the last link UDP
200 OK 200 OK
200 OK
ACK 200 OK
0,5 sec
200 OK
ACK
200 OK
ACK
These are all situations of messages loss in the UDP link. Besides, it’s necessary considering that SIP retransmissions can happen also without the loss of messages, but simply for expiring of timeout. In every case there are SIP on UDP retransmissions uselessly propagate also on the SCTP link, not completely removing the problem of the congestion in these links. Then we suppose that a better solution is the use of SCTP in every link. We want test the difference between the first scenario and the following.
User Agent User Agent PROXY PROXY
SCTP SCTP SCTP
3.3 Open Issues 1 - If we are in a full SIP over SCTP scenario: after the startup of a session between two SIP client, is it possible make a directly SCTP association between two end point? What will happen to the various servers (if they are statefull) bound to that association? 2 - Isn’t better a mapping of Session (dialog) into Stream, respect a mapping of SIP Transaction into Streams??? 3 - I don’t consider it is possible imagine a situation in which every Statefull Server SIP have an association with all the other Server SIP… so if is required change a path, is this possible? 4 - Are there problem in the interaction between link SIP over TCP and link SIP over SCTP??? 5 - …
6 SCTP as Signaling Transport Protocols To do.
7 The implementation
Socket layer SCTP kernel
LK SCTP
ULP level SCTP level IP level
Sendmsg
Recvmsg ULP_queue
packet
inqueue
outqueue
FMS
socket
dissipate
Kphone interface user
SIP application layer
Transport layer
kphone
Kphone skeleton
SipTransaction
SipClient
SipCall
UDPMessage Socket
User interface
Send a request
SCTPMessage Socket
TCPMessage Socket
(1)
(2) (3)
(4)
(5)
Kernel linux (transport level)
SIP layer
Transport layer
(6)
SipTransaction
SipClient
SipCall
UDPMessage Socket
Receive a message
SCTPMessage Socket
TCPMessage Socket
(1)
(2)
(3)
(4) (5)
Kernel linux (transport level)
SIP layer
Transportlayer
(6)
(7)
(8)
8 Installation instructions Linux Red Hat 7.3 distribution
Kernel 2.5.67 - you can download the kernel [here] - you have patch the kernel 2.5.67 with 2.5.67 - lksctp-2_5_67-0_6_9.patch that includes sctp specific changes that didn't go into 2.5.67 [ here] - you have configure your kernel, you can download my .config file [here]
Does it compile, but not load? If so, you likely need new modutils for kernel 2.5 module-init-tools-0.9.11a.tar [here] For the installation read below or README file in the package.
1) you have to install in /sbin: ./configure --prefix=/ make moveold (if installing for the first time). "make moveold" renames the old insmod, modprobe, rmmod and lsmod to insmod.old, modprobe.old, rmmod.old and lsmod.old, and the matching manpages. 2) Now, build it: make make install 3) If running for the first time, you might want to convert your old modules.conf to modprobe.conf: ./generate-modprobe.conf /etc/modprobe.conf 4) You will need to run "depmod" for your new kernel, eg: depmod 2.5.50 6) If you want to hack on the source: aclocal && automake --add-missing --copy && autoconf
lksctp tools tar ball includes user level sctp library and test programs for sctp users and developers -lksctp-tools-2_5_67-0_6_9.tgz [here]
SIP/SCTP tar [here] new If you want receive the source code, please send me an email.
9 User Interface
Figure 9-1 The SCTP version
Figure 9-2 User Identity
Figure 9-3 Choose the transport protocol
Figure 9-4 Start a New Call
Figure 9-5 Receive an Incoming Call
10 Test User Interface
Figure 10-1 Client Side
Figure 10-2 Server Side
11 References
Draft and RFC
[1] J. Rosemberg, H. Schulzrinne, and G. Camarillo, “"The Stream Control Transmission Protocol as a Transport for the Session Initiation Protocol”. draft-ietf-sip-sctp-03.txt
[3] Rosemberg, H. Schulzrinne, et al. “SIP: Session initiation protocol”. Request for Comments
3261 [4] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L.
Zhang and V. Paxsons. Stream control transmission protocol. Request for Comments 2960, Internet Engineering Task Force, October 2000
[5] R. Stewart, L. Ong, I. Arias-Rodriguez, and K. Poon, “Stream Control Transmission Protocol
(SCTP) Implementer's Guide” draft-ietf-tsvwg-sctpimpguide-08.txt [6] R. Stewart, Q. Xie, L. Yarroll, J. Wood, K. Poon, K. Fujita, “Sockets API Extensions for Stream
Control Transmission Protocol (SCTP)” draft-ietf-tsvwg-sctpsocket-06.txt Articles & Presentation
[7] Intro article by Daisy Chang and Jon Grimm (IBM) http://www-124.ibm.com/linux/presentations/lwce2002/Chats/SCTP/SCTP-LWE.pdf
[8] La Monte H.P. Yarroll, Karl Knutson, "Linux Kernel SCTP : The Third Transport” http://lwn.net/2001/features/OLS/pdf/pdf/sctp.pdf
[9] G. Camarillo, H. Schulzrinne, R. Kantola, "A transport protocol for SIP"
[10] G. Camarillo, H. Schulzrinne, R. Kantola, "Signalling transport protocols"
[11] Loreto S., De Marco G., Longo M, De Vito D., 2003 "SCTP as a transport for SIP: a Case Study" http://www.iiis.org/sci2003