The previous posts were –
SIP Message Samples:
The following samples show the message exchange between two User Agents for the purpose of setting up a voice call. SIP user firstname.lastname@example.org invites SIP user email@example.com to a call for the purpose of discussing lunch. Alice sends an INVITE request containing an SDP body. Bob replies with a 200 OK response also containing an SDP body.
Request Message Line
|INVITE sip:firstname.lastname@example.org SIP/2.0||Request line: Method type, request URI (SIP address of called party), SIP version.|
|Via: SIP/2.0/UDP||Address of previous hop. It contains the local address of alice (initiator)i.e. mssys.com where it is expecting the responses to come.|
|Max Forward : 70||It is used to limit the number of hops that this request may take before reaching the recipient (Here is 70). It is decreased by one at each hop. It is necessary to prevent the request from traveling forever in case it is trapped in a loop.|
|From: Alice <sip:email@example.com>||User originating this request|
|TO : Bob< sip:firstname.lastname@example.org>tag=1928301774;||User being invited, as specified originally. It also optionally contains a tag which is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog.|
|Call-ID: 2388990012@alice_ws.mssys.com||Globally unique ID of this call. It is generated as the combination of a pseudo-random string and the softphone’s IP address.|
|CSeq: 1243 INVITE||Command sequence. Identifies transaction. It contains an integer and a method name. When a transaction starts, the first message is given a random CSeq. After that it is incremented by one with each new message. It is used to detect non-delivery of a message or out-of-order delivery of messages.|
|Contact< sip:email@example.com >||It contains a SIP or SIPS URI that is a direct route to alice. It contains a username and a fully qualified domain name(FQDN). It may also have an IP address. (Via field is used to send the response to the request. Contact field is used to send future requests. That is why the 200 OK response from user2 goes to user1 through proxies. But when user2 generates a BYE request (a new request and not a response to INVITE), it goes directly to user1 bypassing the proxies)|
|Subject: Lunch today.||Call subject and/or nature.|
|Content-Type: application/SDP||Type of body—in this case SDP.(This is beyond the scope of SIP and is controlled by SDP which will be discussed later )|
|Content-Length: 182||Number of bytes in the body. If the transport type is UDP, then the Content-Length header is not mandatory. It is, however, mandatory for TCP.|
|Blank line marks end of SIP headers and beginning of body.|
SIP/2.0 200 OK
Via: SIP/2.0/UDP site4.server2.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP site3.server1.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds;received=192.0.2.1
To: user2 <sip:firstname.lastname@example.org>;tag=a6c85cf
From: user1 <sip:email@example.com>;tag=1928301774
CSeq: 314159 INVITE
—- User2 Message Body Not Shown —-
The header fields that follow the status line are similar to those in a request. I will just mention the differences-
There are more than one via field. This is because each element through which the INVITE request has passed has added its identity in the Via field. Three Via fields are added by softphone of user1, server1 the first proxy and server2 the second proxy. The response retraces the path of INVITE using the Via fields. On its way back, each element removes the corresponding Via field before forwarding it back to the caller.
Note that the To field now contains a tag. This tag is used to represent the callee in a dialog.
It contains the exact address of user2. So user1 doesn’t need to use the proxy servers to find user2 in the future.
It is a 2xx response. However responses can be different depending on particular situations.
Next post related to SIP –