Design of a SIP Outbound Edge Proxy (EPSIP)

Transcription

1 Design of a Outbound Edge Proxy (EP) Sixth FRUCT seminar Helsinki, Finland on 3 6 ovember Sergio Lembo Department of Communications and etworking (TKK) Jani Heikkinen, Sasu Tarkoma Department of Computer Science and Engineering (TKK) 1

2 Scope of work Design of a Outbound Edge Proxy that follows the requirements stated in IETF Internet Draft Outbound. Ready to implement design, thus bridging the gap between the requirements in the draft and an actual and feasible implementation of these requirements in a real system. 2

3 Introduction (Session Initiation Protocol) Without special considerations User Agents behind a Firewall or etwork Address Translator (AT) are unable to receive incoming requests due to the presence of these network elements. We focus here on a particular solution provided by an IETF draft: Internet Draft Outbound. Outbound enables incoming requests to a User Agent behind a Firewall or etwork Address Translator (AT) with a mechanism that requires a particular kind of proxy, namely, Edge Proxy. We present a design of such Edge Proxy conforming to Outbound draft EP (Edge Proxy ). 3

4 Outbound and Functionality of a Outbound Edge Proxy UAC (User Agent Client) Edge Proxy (EP) Autoritative Proxy AT FW Stun Client Stun Server Registrar 4

5 Outbound and Functionality of a Outbound Edge Proxy REGISTER UAC (User Agent Client) Stun Client Flow AT FW Edge Proxy (EP) Stun Server non flow Autoritative Proxy Registrar 5

6 Outbound and Functionality of a Outbound Edge Proxy UAC (User Agent Client) flow AT FW Edge Proxy (EP) non flow Autoritative Proxy Stun Client keepalive Stun Server Registrar 6

7 Outbound and Functionality of a Outbound Edge Proxy UAC (User Agent Client) Stun Client flow AT FW keepalive Edge Proxy (EP) Flow Token Stun Server non flow Autoritative Proxy Registrar Flow Token (To map future requests back to the correct flow) 7

8 Scope of the design Fulfill Outbound draft. Working model of Outbound Suitable to handle several transport protocols Be relatively more than a proof of concept serve as a basic prototype for real production scenarios. Main principles: handle flows by processes map flow tokens to processes through local sockets 8

9 Principles in the design of a Outbound Edge Proxy The proxy should be based on a stateless proxy. The architecture must be capable to maintain TCP connections in time. TCP connections (flows) must be managed with a concurrent approach. associate a connection to a process or thread that will be responsible to handle the particular connection (flow). In this sense we introduce the concept that the proxy will have one process or thread running per established flow. Messages to be forwarded over a TCP connection (flow) must reach the corresponding flow by a suitable mechanism that maps the content in the flow token to the module in charge of the TCP connection. processes or threads must be reached appropriately when it comes the time to forward an arriving message over a flow i.e the content of the flow token must be mapped to some reference that will make the message reach the appropriate process or thread in charge of the flow. 9

10 Transport layer architecture design The design presented here is based on implementing concurrency in the proxy by using multiple processes. Main process Listening for incoming messages: Messages over connectionless transport protocols (UDP flows) ew messages over connection oriented transport protocols (TCP flows) The system will have one process per flow 10

11 Transport layer architecture design Child processes to handle connections for TCP transport protocol. Message over the flow: 1 message 2 CRLF keepalive Message from local socket: 3 message Message over non flow: 4 message Child Process Local socket File descriptor message to be sent over non flow. message or CRLF keepalive response to be sent over this flow. message to be sent over other flow. Forward message over a local socket (TCP case) to the corresponding process handling the flow, or directly (UDP case) to destination. Flow token 11

12 Transport layer architecture design Child processes to handle datagrams for UDP transport protocol. Message over the flow: 1 message 2 STU keepalive Message over non flow: 3 message Child Process message to be sent over non flow. message or STU response to be sent over a UDP flow. message to be sent over a TCP flow. Forward message over a local socket to the corresponding process handling the flow. 12

13 Edge Proxy (Implementation) Child process (handling TCP) TCP messages with an established connection enter here Transport and application layer design TRASPORT LAER Loop Send to destination over UDP Main process Block with SELECT/POLL for new messages without connection (i.e. for any UDP and new TCP that have no connection) All messages from UDP and only new TCP messages (without previous connection) enter here Child process (handling UDP) Process message content at application level Exit process Send STU response Messages over TCP. Fork child process. Message over UDP. Fork child Return to calling Loop Send CRLF response Local socket settings Block with SELECT and multiplex the following events incoming messages from the flow (established connection) incoming message over local socket time out incoming messages from the flow time out Process message content at application level incoming message over local socket Deliver message over flow (send to UAC) Close this TCP connection Exit process TCP connections forming an outbound flow will keep the process alive using the keepalive mechanism. With other TCP connections (from non flows) the process will forward the message and then terminate after timeout in SELECT UDP Continue Compose 430 TCP/ UDP? TCP Killprocflag ==1? Flow exists? (5.3) To be sent to destination over flow APPLICATIO LAER STU Parser Is STU keepalive? CRLF Parser Is CRLF keepalive? Parser Ignore message [killprocflag = 1] return Is message? Message is REGISTER? Remove top ROUTE header Update Max Forwards header Add new Via First hop? (one Via)(5.1) Add Path header RFC 3327 with URI, 'ob', flow token and keep stun (8). Compose 403 Message is a request? (5.3) Update Max Forwards header Check top VIA / rport Add new VIA header Remove top ROUTE header Proxy in top most Route? set destination stated in request URI Flow token integrity ok? Retrieve flow token from 1st Route header Flow token? outgoing Destination over flow? Message is a response? Flow token? REGISTER response? Remove VIA header Retrieve flow token from PATH header close flow (3.4) [killprocflag=1] return Answer Failure 4xx return set destination specified in flow token set destination from VIA header Destination over flow? Incoming 2007 Lembo TML/TKK 13

14 Conclusions We designed a Outbound Edge Proxy and : introduced the concept of using a dedicated process per flow. proposed a method to map a flow token to a TCP connection Relating a process to a local socket with a name equivalent to the information stored in the flow token. Relating a file descriptor to a process the design implements a multiple process concurrent approach to handle independently multiple flows. composed a flow chart that resumes in one figure the design of the proxy and Outbound logic. The proxy is suitable also as a multi transport protocol proxy with the advantage of offering a design that contemplates the use of transport oriented protocols. The design was implemented in a real proxy and we successfully verified its behavior in a test scenario. 14