Hierarchy of Procedure
At the heart of SIP’s robustness is its structured hierarchy, which governs how messages are exchanged, sessions are established, and calls are managed. This hierarchy is composed of three fundamental layers: messages, transactions, and dialogs. This hierarchical structure is what allows SIP to handle complex communication scenarios with resilience and flexibility. Understanding this hierarchy is key to appreciating how SIP facilitates the rich tapestry of features we expect from modern communication systems
Followings are the components of SIP Hierachy
- Messages : messages form the foundation of SIP interactions. These are the individual SIP requests (such as INVITE or BYE) and responses (like 200 OK or 404 Not Found) that agents use to communicate. Each message is a discrete action or reaction in the SIP protocol, carrying specific commands or status information.
- Dialog/Session : this is concept (a call processing unit) in Signaling part and set up on a endpoint-to-endpoint basis. A dialog can be identified by the combination of To tag, From tag, and Call-ID. (For example, the whole SIP Registration process can be a Dialog and the whole VoLTE call setup process
can be another Dialog. A transaction is a sequence that starts with a request sent from one user agent, followed by potential provisional responses, and concluded by a final response. This mechanism ensures that every action initiated by a request is completed, either successfully or with an error.
- Transation : Transaction is a concept in Signaling part and set up on a hop-by-hop basis. A transaction is identified by Branch value in Via Header.(branch value will change for every single Request-Response round trip). For instance, Request/ACK/BYE are regarded as different transactions. Beside, one single
transaction is not terminated until a final response to initial request is received (2xx, 3xx response). Within each single transaction, the direction of transaction indicated by From & To Header Field will never change; but transaction direction might be different among transactions. (We often try to figure out the direction of a transaction of a message by looking at 'from', 'to', but it can easily mislead you or confuse you because 'from', 'to' header does not change within a transaction regardless of
message direction). A dialog is a peer-to-peer SIP relationship that is established by a transaction (usually an INVITE) and persists until it is explicitly terminated (typically with a BYE). Dialogs represent full-fledged SIP sessions, which might consist of multiple transactions over their lifetime. They maintain the state of the participants' interaction, enabling the management of features such as call hold, call transfer, and session modification.
|
|