1 / 38

Yeastar Technology Co., Ltd.

Enterprise Communication. Yeastar Technology Co., Ltd. www.yeastar.com. 1. 3. 2. 4. Protocol Introduction. Example Analysis. Protocol Message. Tool Use. SIP – Session Initiation Protocol. TCP/IP Protocol Stack . SIP – Protocol introduction.

oriel
Download Presentation

Yeastar Technology Co., Ltd.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. TCP/IPProtocol Stack

  4. SIP – Protocol introduction • 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. • 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. • 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. • Using textual encoding and decoding. • It’s based on the SMTP and HTTP protocols. • 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. SIP – Correlated protocol 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

  7. Protocol stack

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

  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

  16. SIP - Request Message Format Headers Parameter line

  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" <sip:502@192.168.5.139>;tag=1411642056 To: "502" <sip:502@192.168.5.139> Call-ID: 143870753@192.168.4.16 CSeq: 2301 REGISTER Contact: <sip:502@192.168.4.16:5029> 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. SIP - Response Message 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:

  20. SIP – Response Message

  21. SIP - Response Message Format Headers Parameter line

  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" <sip:502@192.168.5.139>;tag=1411642056 To: "502" <sip:502@192.168.5.139>;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. SIP – Header Fields Details 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.

  24. SIP – Header Fields Details 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.

  25. SIP – Header Fields Details 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.

  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. 1 3 2 4 Protocol Introduction Example Analysis Protocol Message Tool Use SIP – Session Initiation Protocol

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

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

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

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

  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

  38. Thank You!

More Related