branch -- A field in VIA headers, identify a transaction.
tag -- A field in FROM or TO headers,
call-id -- globalunique identifier for a call.
dialog-id -- The combination of the To tag, From tag, andCall-ID completely defines a peer-to-peer SIP relationship between Alice andBob and is referred to as a dialog.
RESPONSE -- This response contains the same To, From,Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice’s softphone tocorrelate this response to the sent INVITE.
Contact Header -- Alicesend her Contact to Bob, and Bob response with 200 his Contact. After thisflow, Alice and Bob know each other, followed ACK/BYE message can betransferred between Alice and Bob directly, bypassing proxy servers. Hence, astateful PROXY
server does not need to keep DIALOG, it only need to keeptransaction, because followed BYE message is not necessary to be forwarded byit.
ACK -- Every INVITE/reInvite, there should be acorresponding ACK. Even if Bob reply 488 (Not acceptable Here), ACK is alsoreceived.
Record-Route -- In some cases, it may be useful for proxiesin the SIP signaling path to see all the messaging between the endpoints forthe duration of the session. For example, if the biloxi.com proxy server wishedto remain in the SIP messaging path beyond
the initial INVITE, it would add tothe INVITE a required routing header field known as Record-Route that containeda URI resolving to the hostname or IP address of the proxy. This informationwould be received by both Bob’s SIP phone and (due to the Record-Route
headerfield being passed back in the 200 (OK)) Alice’ssoftphone and stored for the duration of the dialog. The biloxi.com proxyserver would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Eachproxy can independently decide to receive subsequent
messages, and thosemessages will pass through all proxies that elect to receive it. Thiscapability is frequently used for proxies that are providing mid-call features.
REGISTER-- Registration is another common operation in SIP.Registration is one way that the biloxi.com server can learn the currentlocation of Bob. Upon initialization, and at periodic intervals, Bob’s SIPphone sends REGISTER messages to a server in the
biloxi.com domain known as aSIP registrar. The REGISTER messages associate Bob’s SIP or SIPS URI(sip:bob@biloxi.com) with the machine into which he is currently logged(conveyed as a SIP or SIPS URI in the Contact header field).
SIP Layer -- syntax and encoding, transport, transaction(Statelessproxies do not contain a transaction layer), transaction user layer.
SIP elements -- UAC,UAS, stateless&stateful proxy, registrar
session -- A session is a collection of participants, andstreams of media between them, for the purposes of communication.. A sessionmay consist several dialogs.
dialog -- A dialog is a peer-to-peer SIP relationshipbetween two UAs that persists for some time. A dialog is established by SIPmessages, such as a 2xx response to an INVITE request. A dialog is identifiedby a call identifier, local tag, and a remote tag.
Request-URI -- Request-URI may change, but FROM and TO donot(tag may be added).
VIA headers change -- VIA will be added one by one PROXY inrequest msg. VIA will be removed one by one PROXY in response msg.
UPDATE -- UPDATE allows a client to update parameters of asession (such as the set of media streams and their codecs) but has no impacton the state of a dialog. In that sense,it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initialINVITE
has been completed. This makes itvery useful for updating session parameters within early dialogs. (RFC3311 TheSession Initiation Protocol (SIP) UPDATE Method)
INFO -- The purpose of the INFO message is to carryapplication level information along the SIP signaling path. E.g. DTMF. It doesnot change the state of SIP calls. (INVITE, re-INVITE, BYE change states of SIPcalls. UPDATE is used to change parameters of
a session, most of the time it isparameters in SDP. Refer to RFC2976 (The SIP INFO Method)).
MESSAGE -- allows the transfer of Instant Messages viaSIP. (RFC3428 Session InitiationProtocol (SIP) Extension for Instant Messaging)
Loose Routing -- A proxy is said to be loose routing if itfollows the procedures defined in RFC3261 for processing of the Route headerfield. These procedures separate the destination of the request (present in theRequest-URI) from the set of proxies that
need to be visited along the way(present in the Route header field). A proxy compliant to these mechanisms isalso known as a loose router.
Strict Routing -- A proxy is said to be strict routing if itfollows the Route processing rules of RFC 2543 and many prior work in progressversions of this RFC. That rule caused proxies to destroy the contents of theRequest-URI when a Route header field was
present. Strict routing behavior isnot used in RFC3261, in favor of a loose routing behavior. Proxies that performstrict routing are also known as strict routers.