1. LOGO www.yeastar.com Yeastar Technology Co., Ltd. Enterprise Communication

2. SIP – Session Initiation Protocol Protocol Introduction 1 Example Analysis 3 Protocol Message 2 Tool Use 4

3. OSITCP/IPCorresponding Protocol Application TFTP FTP SNMP SMTP DNS Telnet SIP Presentation Session Transport TCP UDP NetworkInternetIP ICMP ARP Data LinkNetworkHDLC PPP SLIP Physical TCP/IP Protocol Stack

4. SIP – Protocol introduction 1.SIP （ Session Initiation Protocol) is the application layer control protocol for multimedia communications on IP networks, it is used to create, modify, and terminate a session process which has one or more participants. 2.SIP protocol can be used to initiate a session, also used to invite members to join the session which has been established in other ways. 3.Adopting transaction mechanism and operation method of each request triggers the Server. A request and a response constitute a transaction, the transactions are independent of each other. 4.Using textual encoding and decoding. 5.It’s based on the SMTP and HTTP protocols. 6.SIP protocol is only responsible for setting up the call (Signalling) only.

5. SIP – Correlated protocol SIP does not describe and transfer the multimedia information. To complete the call, you also need the help of two protocols: 1. SDP （ Session Description Protocol ） is responsible for setting the media attribute. For example, setting the session port (port) and encoding (codec) 2. RTP （ Real-time Transport Protocol ） is the voice in a call or the video in a video call. SRTP （ Secure RTP) Since RTP can be intercepted and decoded easily by any network capture. SRTP uses AES as encryption to protect the voice.

6. RFC(Request for Comments) LUT SIP - RFC 3261 (There are many extended SIP RFC, and the functions are increasing now. ） SDP - RFC 4566 RTP - RFC 3550 SRTP - RFC 3711 SIP – Correlated protocol

7. Protocol stack

8. SIP – Session Initiation Protocol Protocol Introduction 1 Example Analysis 3 Protocol Message 2 Tool Use 4

9. User-Agent UA(User Agent) represents a terminal system. It consists of two parts: User Agent Client A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. User Agent Server A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction.

10. Transaction and dialog Transaction SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. We can use branch to identify different transaction. Dialog Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543. We can use Call-ID to indentify different dialog.

11. Transaction and dialog

12. SIP Message SIP is a text-based protocol and uses the UTF-8 char set. A SIP message is either a request from a client to a server, or a response from a server to a client. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation. Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.

13. SIP - Request Message SIP requests are distinguished by having a Request-Line for a start line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP SIP-Version CRLF Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods.

14. SIP - Request Message Request-URI: The Request-URI is a SIP or SIPS URI or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in "<>“. SIP elements MAY support Request-URIs with schemes other than "sip" and "sips", for example the "tel" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP- Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference.

15. SIP - Request Message Request message The meaning of the message INVITE Initiate a session request, invite users to join a session, the session description is contained in the message body. For two-party call, the caller indicated the acceptable media type and parameters in the session description. The callee must show the media type which does it want to accept in the message body of the successful response and also instruct the media which will be send. If you receive an invitation to attend the meeting, the callee can determine the user has joined the conference according to the Call-ID or the identity of the session description, and return the success response message. ACK Confirmed receive the final response for INVITE request. The message only can be used with INVITE message. BYE End the session. CANCEL Cancel the uncompleted request, the completed request (ie receive a final response for the request) is not affected REGISTER Register OPTIONS query the server ability

16. SIP - Request Message Format Command name Request URI Protocol version Call-id: value Via: value From: value To: value Contact: value Cseq: value Content-Length: value Max-Forward: value Content-Type: value CRLF SDP Parameter line Headers

17. SIP – Request Message Format REGISTER sip:192.168.5.139 SIP/2.0 Via: SIP/2.0/UDP 192.168.4.16:5029;branch=z9hG4bK273563898 From: "502" ;tag=1411642056 To: "502" Call-ID: 143870753@192.168.4.16 CSeq: 2301 REGISTER Contact: Authorization: Digest username="502", realm="asterisk", nonce="3a156c7a", uri="sip:192.168.5.139", response="1ffdb7809cda0624100a0524af26944c", algorithm=MD5 Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE Max-Forwards: 70 User-Agent: Yealink SIP-T28P 2.50.0.50 Proxy-Require: com.nortelnetworks.firewall Expires: 300 Mac: 001565111886 Line: 4 Content-Length: 0

18. SIP - Response Message SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status- Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request.

19. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response", any response with a status code between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows six values for the first digit: SIP - Response Message

20. SIP – Response Message Serial numberStatus codeMessage capability 1xxProvisional request received, continuing to process the request 2xxSuccess the action was successfully received, understood, and accepted 3xxRedirection further action needs to be taken in order to complete the request 4xxClient Error the request contains bad syntax or cannot be fulfilled at this server 5xxServer Error the server failed to fulfill an apparently valid request 6xxGlobal Failure the request cannot be fulfilled at any server

21. SIP/Protocol versionResponse header Call-id: value Via: value From: value To: value Contact: value Cseq: value Content-Length: value Max-Forward: value Content-Type: value CRLF SDP SIP - Response Message Format Parameter line Headers

22. SIP – Response Message Format SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.4.16:5029;branch=z9hG4bK273563898;received=192.168.4.16 From: "502" ;tag=1411642056 To: "502" ;tag=as76ac4fea Call-ID: 143870753@192.168.4.16 CSeq: 2301 REGISTER Server: Asterisk PBX SVN--r1972M Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7ce05bb3" Content-Length: 0

23. 1. The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected 2. The From header field indicates the logical identity of the initiator of the request, possibly the user’s address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. SIP – Header Fields Details

24. 3. The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. 4. The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. SIP – Header Fields Details

25. 5. The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. 6. The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. SIP – Header Fields Details

26. SIP – Common Expended Protocols As SIP is a protocol in the continuous development, there are many of the expanded protocols. If need to know, please read related RFC documents for more detail: http://www.voip-info.org/wiki/view/SIP

27. SIP – Session Initiation Protocol Protocol Introduction 1 Example Analysis 3 Protocol Message 2 Tool Use 4

28. the example package SIP Phone Register 401 Unauthorized Register 200 OK MyPBX SIP – Register Flow

29. SIP – Call Flow MyPBXSIP PhoneASIP PhoneB INVITE 5 100 Trying 6 INVITE with sdp1 7 100 Trying 8 180 Ringing 9 10 200 OK sdp2 12 200 OK sdp2 11 INVITE with sdp1 1 100 Trying 2 407 3 ACK 4 the example package ACK

30. SIP – Others 1.Options ： query the server capabilities 2.Subscribe ： subscribe UA status 3.Notify ： notify UA status Please look at the example package

31. SIP – Session Initiation Protocol Protocol Introduction 1 Example Analysis 3 Protocol Message 2 Tool Use 4

32. MyPBX CLI – SIP debug

33. SIP debug

34. Tool - Wireshark

35. Real-time view sip package

36. SIP Conversation Analysis

37. SIP – Conversation Analysis