SIP Request Methods
SIP PRACK (Provisional Acknowledgement) is a way to enable reliability for SIP 1xx provisional messages (excluding 100 Trying) like 180 ringing and 183 session in progress. PRACK messages are sent from the calling party to to called party, to acknowledge the receipt of a 1xx message. The called party will acknowledge and PRACK message with a 200OK.
180 Ringing –>
100rel support/required allows the calling or called party to show its support for, or requirement for PRACK messages, and is included in INVITE and subsequent 1xx messages.
The NOTIFY request typically contains modified session description.
During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity indicated in the Contact: header of the “opening” SUBSCRIBE request. Normally this will happen as a result of any change in the status of the service session for which the Requestor has subscribed. The receiving user agent server MUST acknowledge this by returning a final response (normally a “200 OK”).
SIP implements a three-way handshake.
- The caller sends an INVITE
- The callee sends an 200 OK to accept the call
- The caller sends an ACK to indicate that the handshake is done and a call is going to be setup
SIP Header Fields
The Request-Line-URI includes the destination of the call. It contains the same information as the To field, omitting the display name.
Every proxy in the request path adds to top of the “Via” the address and port on which it received the message, than forwards it onwards. When processing responses, each proxy in the return path processes the contents of the “Via” field in reverse order, removing its address from the top.
The “From” header field indicates the identity of the initiator of the request from the point of view of the PBX Server – similar in construction to email addresses (user@domain – where “user” is, for example, the extension number, and “domain” is the server domain or IP address). Like the “To” header field, it contains a URI and optionally a display name. It is used to determine which processing rules to apply to a request.
From the SIP RFC 3261: The “From” header field allows for a display name. A UAC (i.e a phone) SHOULD use the display name “Anonymous”, along with a syntactically correct, but otherwise meaningless URI (e.g. From: “Anonymous” <sip:email@example.com>), if the identity of the client is to remain hidden.
Typically, the host IP Address will be the internal IP address of the PBX Server.
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 URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 ), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme.
The To header field allows for a display name (e.g. To: “Target User” <sip:firstname.lastname@example.org>).
Typically, the “To” field contains a SIP URI that points to the first (next) hop (proxy) that will process the request, but not necessarily the SIP URI of the eventual recipient.
The “Contact” header field provides a single SIP URI that can be used to contact the sender of the INVITE for subsequent requests. The Contact header field MUST be present and contain exactly one SIP URI in any request that can result in the establishment of a dialog – in this case, specifically a SIP INVITE. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the sender is expecting to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs (in our case, meaning established calls).
This field lists, in comma-separated format, the SIP Methods that the caller can support and use. SIP defines the following methods: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE
Note: If you do not specify a port, the default sip port will be assumed (5060).
A telephone number is represented as a SIP URI in the form sip:<user info>@<domain>:<port>;user=phone. Port is optional, and if not specified the default of 5060 will be used.
The “user=phone” parameter indicates that the user portion of the URI (the part to the left of the @ sign) should be treated as a tel URI, so “sip:+email@example.com;user=phone” should be treated as tel:+6495005000″.
Tel URI parameters (such as phone-context) are included in the user info, not the SIP URI itself, i.e “sip:95005000;firstname.lastname@example.org;user=phone” is the same as “tel:95005000;phone-context=+64”
- RFC 2833
<– 202 Accepted
<– 200 OK
Unattended Transfer Example
Attended Transfer Example