Hello, guys!
Good day to you!
This post is about the SIP Request/Method INVITE message headers explained. Please read further down.
Below you will find a typical INVITE request message:
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9h**bK74bf9
Max-Forwards: 70From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76slTo: Bob <sip:bob@biloxi.example.com>Call-ID: 88511@atlanta.example.com
CSeq: 2 INVITEContact: <sip:alice@client.atlanta.example.com;transport=tcp>Diversion: Carol <sip:carol@atlanta.example.com>;privacy=off;reason=no-answer;counter=1;screen=noRemote-Party-ID: Alice <sip:alice@atlanta.example.com>P-Asserted-Identity: Alice <sip:alice@atlanta.example.com>P-Charge-Info: <sip:eve@atlanta.example.com>P-Source-Device: 2.XX.XX.12
Content-Type: application/sdp
Content-Length: 151X-BroadWorks-DNC: network-address=sip:+3210@127.0.0.101;user=phoneUser-Agent: X-Lite release 1104o stamp 56125
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-c=IN IP4 192.X.X.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Request-Line-URI:
INVITE sip:bob@biloxi.example.com SIP/2.0
The Request-Line-URI includes the destination of the call. It contains the same information as the To field, omitting the display name.
Via:
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9h**bK74bf9
Max-Forwards: 70
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 most important thing is to know the difference between the Via and the Contact header. While the Via header tells the other user agent where to expect future responses; the Contact header indicates where the user agent expects future requests to be sent (other SIP methods).
From:
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
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:10000@10.172.0.2>), 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.
To:
To: Bob <sip:bob@biloxi.example.com>
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 [9]), 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:101@10.172.0.2>).
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.
Call-ID
Call-ID: 3848276298220188511@atlanta.example.com
The Call-ID header field is a unique ID identifying the SIP call. All messages containing this call-id will be assigned to the same SIP call.
Contact:
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).
Diversion:
Diversion: Carol <sip:carol@atlanta.example.com>;privacy=off;reason=no-answer;counter=1;screen=no
The diversion header contains the redirection information of the call. It includes the contact information of the device that forwards the INVITE, and also the reason for diversion.
Remote Party ID:
Remote-Party-ID: Alice <sip:alice@atlanta.example.com>
This SIP header is considered obsolete, but is still used to convey the calling telephone number and source IP address.
P-Asserted Identity:
P-Asserted-Identity: Alice <sip:alice@atlanta.example.com>
The P-Asserted-Identity header field is an important SIP header used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. This header is commonly used in call centers who need to present the calling number of its customer, rather than it actual telephone number.
Allow:
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.
Definitions
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
For more detailed information related to SIP, you can also read RFC3261.
Thanks for reading!
