VoIP with SIP Session Initiation Protocol RFC-3261/RFC-2543 Tasuka@Tailyn.com.tw 1
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone 2
Legacy Telephone Use SS7 as out band signaling Time Division Multiplexing T1 / E1 / SDH as trunk DS0 64Kbps per channel Routing based on dialing plan 3
Voice over IP 4
Voice over IP 4
Voice over IP Signaling out band with SIP / H.323 Packet Switching Transport with IP/UDP/RTP With G.711/G.723/G.726/G.729 Codec Routing based on IP address 5
SIP Overview Internet telephony use a verity of signaling protocols, such as H.323, SIP, MGCP and H.248 (MEGACO) for initiating VoIP call. However, SIP seems to overwhelm all the others, mainly due to the fact that is has been adopted by various standardization organizations i.e. IETF, ETSI, 3GPP as the protocol for both wireline and wireless world in the Next Generation Networks (NGN) era. 6
SIP is an application layer signaling protocol for creating, modifying and terminating multimedia sessions with one or more participants. A SIP message can either be a REQuest or ACKnowledgment to a request, consisting of the header field and the message body. SIP message are text-based and are similar to HTTP message format. The message body is either used to describe session requirements or to encapsulate various types of signaling. 7
SIP message must also identify the requested resource, which corresponds to a unique address. SIP addresses follow the general form of Mail addressing scheme. An example of a SIP address are: sip:tasuka@tailyn.com.com 8
SIP Protocol SIP works in concept with several other protocols and is only involved in the signaling potion of a communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use, what codec being used etc. In typical use, SIP sessions are simply packet streams of the Real-time Transport Protocol (RTP). RTP is the carrier for the actual audio or video content itself. 9
SIP Server requirement Proxy Registration Refer Redirect 10
Proxy Service The proxy server receives SIP requests and forwards them on behalf of the requester and consults a database, generically called a location services, that contains the current IP address of where the receiver stand with. The SIP Proxy is responsible to routing all SIP message to their destinations. 11
Registration Service Registration is one way that the proxy server can learn the current location of receiver. When initialization, at periodic intervals, user send a REGISTER messages to a SIP register server, the REGISTER messages associate SIP URI logged. The register writes the association, also called a binding to a database, called the location services, where it can be used by the proxy server. Often, a register and proxy is co-located and in normally is logically not physically. 12
The SIP Register handles the registration services for caller and receiver located. Detail of locating SIP Server in RFc-3263 13
Refer Service This extension provides a mechanism where one party (the referrer) provides a seconds party (also the referrer) with an arbitrary Uniform Resource Identifiers (URI) to reference. SIP Refer can be used to enable many applications, including call Transfer. SIP refer is reference to RFC-3892 14
SIP Inside SIP messages is similar to HTTP messages and shares some of its design principles: It is human readable and request-response structured. SIP proponents also claim it to be simpler than H.323. 15
SIP Request RFC-3261 RFC-3265 16
RFC-3261 SIP uses six type of require messages INVITE ACK BYE CANCEL OPTIONS REGISTER 17
REGISTER REGISTER: Registers the address listed in the To header field with a SIP server. 18
REGISTER 19
REGISTER 19
REGISTER 19
INVITE INVITE : Indicates a client being invited to participate in a call session. 20
INVATE 21
INVATE 21
INVATE 21
INVATE 21
ACK ACK: confirms that the client has received a final response to an INVITE request. 22
BYE BYE: Terminates a call and can be sent by either the caller or the callee. 23
CANCEL CANCEL: Cancels any pending searches but does not terminate a call that has already been accepted. 24
OPTIONS OPTIONS: Queries the capabilities of servers. 25
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
SIP message pass 26
RFC-3265 Extends the basic request messages to support notification. SUBSCRIBE NOTIFY 27
SUBSCRIBE SUBSCRIBE: Subscribes for a Event of Notification from the Notifier. 28
NOTIFY NOTIFY: Notify the subscriber of a new event. 29
SIP Response SIP responses are the codes used by Session Initiation Protocol for communication. They complement the SIP Requests, which are used to initiate action such as a phone conversation. 30
SIP Response type contents 1xx : Informational 2xx : Successful 3xx : Redirection 4xx : Client Failure 5xx : Server Failure 6xx : Global Failure 31
Informational 100 : Trying 180 : Ringing 181 : Call is being forwarded 182 : Queued 183 : Session progress 32
Successful 200 : OK 202 : Accepted ( Used for referrals ) 33
Redirection 300 : Multiple choices 301 : Moved permanently 302 : Moved temporarily 305 : Use proxy 380 : Alternative service 34
Client Failure 400 : Bad request 401 : Unauthorized (Only for Registers) 402 : Payment required 403 : Forbidden 404 : User not found 405 : Method not allowed 406 : Not acceptable 35
Client Failure 407 : Proxy authentication required 408 : Request timeout 410 : User gone 413 : Request entity too large 414 : Request URI too long 415 : Unsupported media type 416 : Unsupported URI scheme 36
Client Failure 420 : Bad SIP extension 421 : Extension required 423 : Interval too brief 480 : Temporarily unavailable 481 : Call / Transaction does not exist 482 : Loop detected 37
Client Failure 483 : Too many hops 484 : Address incomplete 485 : Ambiguous 486 : Busy here 487 : Request terminated 488 : Not acceptable here 38
Client Failure 491 : Request pending 493 : Undecipherable 494 : Security agreement required 39
Server Failure 500 : Server internal error 501 : Not implemented 502 : Bad gateway 503 : Service unavailable 504 : Server timeout 505 : Version not supported 506 : Message too large 40
Global Failure 600 : Busy everywhere 603 : Decline 604 : Does not exist anywhere 606 : Not acceptable 41
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
SIP call procedure 42
Summary In Function point of view: SIP Register and Proxy service administrate SIP messages. In Protocol point of view: SIP REGISTER and INVITE messages are the predominant messages used by the SIP protocol. 43
SIP clients traditionally use TCP and UDP 5060 to connect to SIP servers and other SIP endpoints. All Audio and Video communications are done over separate session protocols, typically RTP. 44
RTP Inside RTP - Real-time Transport Protocol RTP defines a good standardized packet format for delivering audio and video over the Internet. It was developed by the IETF and first published in 1996 as RFC-1889 which was obsoleted in 2003 by RFC-3550. 45
RTP Header Payload Type : 7 bit Sequence number : 16 bit Time stamp : 32 bit Synchronization source identifier : 32 bit Miscellaneous Field... 46
RTP Header 0 2 3 4 8 9 16 31 VER P X CC M P Type Sequence Time Stemp Synchronization Source Identifier Contributing Source ID Contributing Source ID... 47
RTP Header compress The minimal 12 bytes of the RTP header, combined with 20 bytes of IP header and 8 bytes of UDP header, create a 40 byte IP/UDP/RTP header. The RTP packet has a payload of approximately 20 to 150 bytes for audio applications that use compressed payloads. It is very inefficient to transmit the IP/UDP/ RTP header without compressing it. The RTP header compression compresses the IP/UDP/ RTP header in an RTP data packet from 40 bytes to approximately 2 to 5 bytes. 48
RTP Header Compress No Header Compression 20 byte 8 byte 12 byte 20 to 160 byte IP UDP RTP Payload Overhead IP/UDP/RTP Header Compression 3-5 20 to 160 byte Header Payload 49
RTP Header compress RTP header compression is a hop-by-hop compression scheme similar to RFC-1144 for TCP header compression. The RFC-2507 for IP header compression. Using RTP header compression can benefit both telephony voice applications running over slow links. The detail refer to RFC-2508 50
RTP/AVP RTP Audio and Video payload Profile detail in RFC-3551/RFC-1890. This profile defines aspects of RTP left unspecified in the RTP protocol definition. It is for use of the RTP, RCTP within Audio and Video multi-participant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences, and define a set of default mapping from payload type numbers to codec encoding. 51
RTP/AVP payload type Type Format Sampling Rate Rate 0 PCM u-law 8 KHz 64 Kbps 1 1016 8 KHz 4.8 Kbps 3 GSM 8 KHz 13 Kbps 4 G.723 8 KHz 7 LPC 8 KHz 2.4 Kbps 8 PCM a-law 8 KHz 64 Kbps 9 G.722 16 KHz 48-64 Kbps 14 MPEG-Audio 90 KHz 15 G.728 8 KHz 16 Kbps 18 G.729 8 KHz 26 Motion-JPEG Video 31 H.261 Video 32 MPEG-1 Video 33 MPEG-2 Video Detail update from http://www.iana.org/assignments/rtp-parameters 52
RTCP Inside RTCP - Real Time Control Protocol RTCP to handle the SDP described the RTP use multiple ports and crossed the NAT ports mapping problems, it is extension attribute to SDP. Detail refer to RFC-3605/RFC-2377 In normally use, the RTP will use odd port and RTCP will use the RTP port + 1, for describe and report that RTP session status. 53
The RTCP attribute is used to document the RTP port used for media stream, when that ports is not the next higher port number following the RTP port described in the media line(not continue port number). The RTCP attributes is a value attribute and follows the general syntax: a=attribute:value 54
SDP Inside SDP - Session Description Protocol is a format for describing streaming media initialization parameters. It has been published by the IETF as RFC-4566/ RFC-2327 SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. 55
SDP started off as a component of the Session Announcement Protocol (SAP), but found other uses in conjunction with RTP, SIP and just as a standalone format for describing multicast sessions. An SDP session description is entirely textual using the ISO-10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual field and attribute values MAY use the the full ISO-10646 character set. 56
SDP is be used in : Session initiation Streaming media Email and Web Multicast session announcement 57
SDP terms Conference Session Session Announcement Session Advertisement Session Description 58
Conference Conference : It is a set of two or more communicating users along with the software they are using. 59
Session Session : Session is the multimedia sender and receiver and the following stream of data. 60
Session announcement Session Announcement : A Session announcement is a mechanism by which a session description is conveyed to users in a proactive fashion, i.e. the session description was not explicitly requested by the user. 61
Session advertisement Session advertisement : Same as session announcement. 62
Session description Session description : A well defined format for conveying sufficient information to discovery and participate in a multimedia session. 63
SDP Messages SDP session description consists of a number of lines of text of the form : type=value Where type must be exactly one case-significant character and value is structured text whose format depends on type. 64
Session description v= protocol version o= originator and session identifier s= session name i=* session information u=* URI of description e=* email address 65
Session description p=* phone number c=* connection information b=* zero or more bandwidth information lines z=* time zone adjustments k=* encryption key a=* zero or more session attribute lines 66
Time description t= time the session is active r=* zero or more repeat times 67
Media description m= media name and transport address i=* media title c=* connection information b=* zero or more bandwidth information lines k=* encryption key a=* zero or more media attribute lines 68
SDP Example v=0 o=user1 2890844526 2890842807 IN IP4 192.168.64.4 s=sd seminar i=a seminar on the session description protocol u=http://www.here.com/sdp/sdp01.txt e=user1@here.com (User Who) c=in IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 VAT PCMU m=video 2232 RTP H261 m=whiteboard 32416 UDP WB a=orient:portrait Rewrite: (session (v 0)(o user1 2890844526 2890842807 IN IP4 192.168.64.4) (s Sd seminar)(i A Seminar on the session description protocol) (u http://www.here.com/sdp/sdp01.txt) (e user1@here.com (User Who)) (c IN IP4 224.2.17.12/127)(t 2873397496 2873404696)(a recvonly) (all (media (m audio 3456 VAT PCMU)) (media (m video 2232 RTP H261)) (media (m whiteboard 32416 UDP WB) (orient portrait) ) ) 69
Summary The SDP is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a Network Address Translated (NAT RFC-2766) device that also uses port mapping, the ordering of ports can be destroy by the translation. Use RTCP to resolve the problem. 70
SAP Inside SAP - Session Announcement Protocol SAP is a protocol for broadcasting multicast session information. A SAP listening application can listen to the wellknown SAP multicast address and construct a guide of all advertised multicast sessions. SAP was defined in RFC-2974 71
SAP typically uses SDP as the format of the session descriptions and the multicast sessions typically use RTP. 72
Quality of Service Because the Audio and Video is delay sensitive, so when transmit it on net, Quality of Service is more important then others traffic. Traffic QoS can use Marking / Filtering / Queueing methods to measure the traffic smoothly but will increase jitter. So if traffic jam on net, the delay jitter still can not permit, but if the traffic path can be reservation bandwidth for audio and video, then the service of quality will better. 73
RSVP RSVP is a resource reservation setup protocol designed for quality integrated services on Internet. RSVP is used by a host to request specific qualities of service from the network for particular application data streams of flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. Use RSVP to reservation bandwidth is be defined on RFC-2205/RFC-2750. 74
RSVP requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 / IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementation of RSVP will typically execute in the background, not in the data forwarding paths. 75
RSVP is not routing by itself; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing databases to obtain routes. In the multicast case, for example, a host sends RSVP messages to reserved resources along the delivery paths of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. 76
Reference Documents 77
VoIP Reference RFC-2543/3261 SIP: Session Initiation Protocol RFC-3263 SIP: Locating SIP servers RFC-3265 SIP: Specific event notification RFC-3892 SIP: Referred by mechanism RFC-2327/4566 SDP: Session Description Protocol RFC-1898/3550 RTP: A Transport Protocol for Real-Time Applications RFC-1144 Compressing TCP/IP headers for low-speed serial links RFC-2507 IP header compression RFC-2508 Compressing IP/UDP/RTP headers for low-speed serial links 78
RFC-3605 Real Time Control Protocol (RTCP) attribute in SDP RFC-2974 Session Announcement Protocol (SDP) RFC-3551 RTP Profile for Audio and Video (RTP/AVP) conferences with minimal control RFC-3555 MIME Type Registration of RTP Payload formats 79
Based Protocols RFC-768 User Datagram Protocol (UDP) RFC-791 Internet Protocol (IP) RFC-792 Internet Control Message Protocol (ICMP) RFC-793 Transmission Control Protocol (TCP) RFC-1112 Host Extenations for IP Multicasting (IGMP) RFC-1738 Uniform Resource Locators (URL) RFC-2460 IP Version 6 (IPv6) 80
QoS Reference RFC-2205 Resource Reservation Protocol (RSVP) RFC-1349 Type of Service in the Internet Protocol Suite (ToS) RFC-2474 Definition of the Differentiated Service Field (DS) in the IPv4 and IPv6 header RFC-2475 An Architecture for Differentiated Services RFC-2597 Assured Forwarding (AF) PHB Group RFC-2598 An Expedited Forwarding (EF) PHB RFC-3168 The Addition of Explicit Congestion Notification (ECN) to IP 81
IETF to ITU-T mapping RFC-3015 MEGACO Protocol Version 1.0 (ITU-T H.248) RFC-2805 Media Gateway Control Protocol Architecture and Requirement (MGCP) RFC-4612 Real-Time Facsimile (T.38) Audio/T38 MIME Sub-type Registration RFC-ietf-avt-2833bis-15 RTP Payload for DTMF Signals RFC-3047 RTP Payload format for ITU-T Recommendation G.722.1 82