This article explains the main fields included in a SIP INVITE, which is sent to set-up a VoIP call. A SIP INVITE message contains typically between 4 and 6 header entries with contact information inside them. Different devices or providers use these headers in different ways and therefore, an understanding of the “normal” scope of these headers, together with a close analysis of log messages, will help to understand the cause of certain issues, and also to configure devices or providers in the 3CX Management Console so as to be identified correctly. The image below shows a typical SIP INVITE.
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
SIP URI – A SIP URI is a user’s SIP phone number. The SIP URI resembles an e-mail address and is written in the following format: SIP URI = sip:x@y:Port