one transaction : same branches stack in Via; (INVITE,100,180,200) ACK is out of scope of the INVITE transaction of normal setup.
- (1)If the request is INVITE
- the final response is a 2xx response, The ACK is a separate transaction;
- the final response is a non-2xx, the transaction also includes an ACK to the response;
- (2) otherwise, Transaction comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client;
one call-leg: end-to-end, may contains many transactions; The CSeq spaces in the two directions of a call leg are independent.
one dialog/call: from, to, cal-id, to be exact, it should be the combination of the To tag, From tag, and Call-ID . the tag is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog. A dialog used to be referred as a ‘call leg’.
The Call-ID is an identifier, carried in the SIP messages, that refers to the call. It is a globally unique identifier of the call generated as the combination of a pseudo-random string and the softphone’s IP address.
A call may contain several dialogs. we can say a cal is a session.
Since a phone call (i.e. an SIP dialog) consists of several transactions, and SER (an open source Proxy) does not keep information about transactions throughout a particular phone call, the consequence is that SER does not know that a call is on-going, nor can SER calculate the length of an ended or active call. Neither can SER terminate a phone call. However, SER can store the times at which an INVITE (or ACK) and a BYE message are received and record this info together with the Call-Id. A billing application can then match the INVITE with the BYE and calculate the lengths of calls
The tags and the Call-Id field are generated by endpoint SIP phones and are maintained by them constantly during the phone conversation. Tag parameters are random strings, while Call-Id is generated by a combination of a random string and the originating phone’s host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between two SIP phones and is referred to as a dialog [rfc3261, p.12].
Within the scope of one transaction SIP requests and all replies follow the same signalling path. It is ensured by a stack of Via fields.
When processing SIP request messages each intermediary proxy adds its own Via field on top of the stack of Via header fields. Each Via field contains the IP address of the proxy and a branch parameter identifying the transaction (i.e. all messages in the transaction have the same branch parameter).
The replies are transmitted by the destination UA with the same stack of Via fields as they received by UA in the request message (recall that the stack of Via fields is summed up on the way from the originating UA to the destination UA). The top most Via field of reply message dictates the next hop where the message should be transmitted (i.e. the last proxy of the request before it arrived to UA). At each hop the proxy server removes its own Via field from the top and forwards the message according to the top most Via field of the reduced stack.
However, the proxies can request to maintain the signalling path during the dialog. Record-Route header is designed for these purposes. A stack of Record-Route headers works similarly as the stack of Via headers but is a little bit more complex. (1)Each proxy server (wishing to stay in the signalling path) adds on top of the Record-Route headers stack its IP address (or its domain name). (2)Record-Route headers are usually added by proxies only in the first request of the first transaction (i.e. in the INVITE message).
When processing the first request of the first transaction, each intermediary proxy adds its own Record-Route field on top of the stack of Record-Route header fields.when the destination UA receives a stack of Record-Route headers which is similar to the stack of Via headers. The destination UA will copy the stack of Record-Route headers from the request to all responses replied within the scope of the transaction. The Record-Route headers will not be removed (unlike the Via header) as the reply traverses back to the originating UA. Recall that replies are delivered back through a path dictated by the stack of Via headers. The Record-Route headers are therefore not required for determining the path of replies. Therefore the originating and destination User Agents will be in possession of the same stack of Record-Route headers at the end of the SIP dialog’s first transaction.
(Although the callee phone 309 learned the direct contact of the originating phone 308 from the Contact field of the INVITE request, and the calling phone 308 learned the direct contact of the callee phone from the Contact field of the 200 OK reply (see the message above), the User Agents give a priority to Record-Route instructions and will not use the available direct contact information.)
The endpoint User Agents form Route header stacks from the received Record-Route header stacks. The Route header stack of the destination UA is the copy of the Record-Route header stack (only the header name is changed from “Record-Route:” to “Route:”). The Route header stack of the originating UA is the copy of the Record-Route header stack but in the reversed order.
The Route header stack added to request messages dictates the path of the message. Each time an intermediary proxy receives a message with its own IP in the top most Route header field, the proxy will remove its Route field from the stack and will forward the request to the next proxy listed in the stack. The routing according to the Route fields with removals of top most Route fields is called loose routing. Using the stack of Route fields (for maintaining the signalling path) during the phone conversation is the obligation of User Agents. They follow that during the entire duration of the phone conversation the request messages will be transmitted by both User Agents with the stacks of Route fields (associated to the current phone conversation). The proxies only provide the Record-Route headers once in the call setup transaction.
All requests sent from A to B within a dialog, independent of the method, have increasing CSeq, by value of 1, with two exceptions: 1. ACK for an INVITE has the same cseq as the invite 2. cancel for a request has the same cseq as request
for register authentication, the server challenges with the header field WWW-Authenticate and the user responses with the header field Authorization. For call setup, the proxy server challenges with a different header field Proxy-Authenticate, and the user responses with the header field Proxy-Authorization
Understanding SIP exchanges by experimentation
other sip docs