SIP User Documentation Chapter 1
PREVIOUS CHAPTER | TOC | NEXT CHAPTER
The Session Initiation Protocol (SIP) is a text-based application-layer communications protocol for signaling and controlling multimedia communication sessions. The HPE SIMULAP SIP Plugin and a corresponding SIP stack allow you to manage all signaling-related elements of a SIP message exchange.
The key SIP concepts can be summarized as follows:
SIP messages are sent between endpoints to govern establishment, termination and other essential elements of a call. There are two different types of SIP messages: requests and responses.
A request is a SIP message sent from a client to a server, for the purpose of invoking a particular operation.
The first line of a request contains a method, defining the nature of the request (for example INVITE, ACK or BYE), and a Request-URI, indicating where the request must be sent (for example user2@server2.com).
The following lines are a set of header fields (for example To, From, or Call-ID).
The message body is used to convey information about the media session (port numbers, protocols, codecs), and it is encoded in another protocol format, for example, Session Description Protocol (SDP).
A response is a SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.
The first line of a response contains a Status-Code (for example, 100) and a Reason-Phrase (for example, Trying). The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user.
The header fields and the message body are similar to those in a request.
If the caller sends information about the media session in the body part of the INVITE request, the answer must be included in the body part of the 2xx response. If media information is not included in the INVITE, the negotiation must be included in the 2xx response and the ACK.
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, 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 considered as a separate transaction.
A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The term refers to the signaling part of a call, that is, the process of setting up and controlling a session.
The following SIP methods are related to a new dialog:
INVITEREGISTERNOTIFYSUBSCRIBEREFERPUBLISH
A session is an exchange of data, including voice or video. The term refers to the media part of a call flow. A multimedia session, for example, a multimedia conference, is a set of multimedia senders and receivers and the data streams flowing from senders to receivers.
Multiple dialogs can be involved in the control of a single session.
A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. A caller may have connections to a number of callees at a time during a call. The term covers a media session and all the corresponding SIP signaling dialogs.
The following figure shows a normal SIP call flow and the role of some other protocols during the call. The signaling part of the call between user agent A and user agent B contains a single SIP dialog that consists of three SIP transactions.
HPE SIMULAP SIP Plugin supports the following standard SIP methods:
ACKBYECANCELINVITEOPTIONSREGISTERNOTIFYSUBSCRIBEMESSAGEREFERINFOPRACKUPDATEPUBLISH
Even though SIP is a flexible protocol that allows extending the standard list of methods, HPE SIMULAP SIP Plugin does not support this feature in the current release.
The HPE SIMULAP SIP Plugin is closely linked to the SIP stack. Messages sent through an Apache JMeter scenario must be aligned with the SIP protocol. Call flow and routing headers must be configured according to SIP RFCs.
IETF's RFC #3261 defines dialog, transaction, and the routing management of SIP messages at the stack level. If you develop a scenario that does not comply to these specifications, the call flow cannot be successfully simulated, because the SIP stack does not allow the sending of non-compliant messages through the network. For example, the final response to an INVITE request cannot be sent if the SIP server does not use the default 5060 local port, and the destination port for the ACK is not specified in the Contact header of the final response message.
However, if an error is caused by a SIP header that is related to the application part, for example, the Call-Info header, the SIP stack allows the sending of the message, and the error is managed by the remote application and by the scenario itself. Media session information in the message body can also cause a similar error. The stack allows the sending of the message, but if no media format is supported by the server, it can refuse the call on its own.
As for request and response message headers, the same constraints apply to the Apache JMeter scenarios that apply to the SIP stack API:
- The
Request-URI,From, andToheaders are mandatory to fill when sending a SIP method related to a new dialog (that is, when sendingINVITE,REGISTER,NOTIF,SUBSCRIBE,REFER, orPUBLISHrequests).
Other mandatory headers are set automatically if you do not define them in the scenario.-
CSeq is initialized to
1, and then incremented by1for further requests. - Call-ID is set to an opaque token by the stack.
-
Max-Forwards is set to
10. - Via is set using the SIP node configuration parameters.
-
CSeq is initialized to
- For all the other SIP methods, no headers are mandatory to fill when sending a request.
- For SIP responses, no headers are mandatory to fill (except for the Contact header in final responses to
INVITErequests if the local port is not5060).