While following IMS over LTE technology, RFC specifications base SIP study seems necessary to understand how IMS works in detail. It could be way different from 3GPP specifications, but it would be worth going through some of them.
Let me get started with one of most popular trapezoid example in RFC3261. This Figure 1 on right hand side comes from 4 Overview of Operation in RFC3261. And the left hand side one is draw by myself based on 24.2 Session Setup, which describe full detailed SIP message about Figure 1. As you can see these 2 trapezoids look quite different but I would rather follow 24.2 Session Setup with my chart from now on.
Go through SIP Dialog
Since Alice's softphone does not know the location of Bob's SIP phone or SIP servers in biloxi.com domain, the softphone sends INVITE to it's SIP server that servers Alice's domain, atlanta.com. The address of atlanta.com SIP server could have been configured in Alice's softphone or discovered by DHCP. The atlanta.com proxy server receives INVITE request, processes it, and send 100 Trying response back to Alice's softphone. This 100 Trying response tells the caller that INVITE has been received an the atlanta.com proxy is working on her behalf to route the INVITE to the destination.
The atlanta.com proxy server locates the proxy server at biloxi.com domain through DNS lookup, which is not in the chart. As a result, the IP address of biloxi.com proxy server is obtained and the INVITE request is forwarded by atlanta.com proxy. The biloxi.com proxy server receives INVITE and responses with 100 Trying back to atlanta.com to indicate it was received. Generally the callee's proxy server (biloxi.com in this case) consults a database to locate the callee.
As soon as Bob's SIP phone receives the INVITE and alerts Bob to incoming call from Alice so that Bob can decide whether to answer the call. This makes Bob's phone ring while sending a 180 Ringing response, which is routed back through the 2 proxies.
Bob decides to answer the call in this example. When he picks up the handset, a 200 OK response is sent to indicate that the call has been answered. This 200 OK contains SDP media description of session type that Bob is willing to establish with Alice. Then the requester responses ACK to 200 OK and this ACK is directly routed to the callee. After this, media session has now established and real media can be transmitted, we say.
At the end of the call, Bob hangs up first, which generate a BYE message. This BYE is routed directly to the caller, Alice bypassing those proxies. Alice confirms the receipts of BYE with 200 OK response, which terminates the session and the BYE transaction.
So far, narrowing down some related header fields would be helpful. Here is the final detailed SIP message on the trapezoid below.
# References
# References
- RFC3261 4 Overview of Operation
- RFC3261 24.2 Session Setup