Address in IMS/SIP Messages

One of the most confusing thing in analyzing and troubleshooting IMS/SIP related issue is to understand all the correlations of various addresses in multiple messages. If these correlations are not properly implemented, you would get such a famous/notorious error message "404 Not Found".

In short, in a common scenario: When you make a call, the URL in the Request Line is who you're calling, the Via header shows the path the request has taken, the From header is you, the To header is the person you're calling, and the Contact header is where you can be reached directly. This system of different addresses allows SIP to be very flexible and support a wide range of communication scenarios, including those in complex networks and across different devices.

Let's clarify on several different types of addresses we see :

• URL in Request Line:
• This URL indicates the recipient of the SIP request. For an INVITE request, it would be the address of the person you are trying to call. It's like addressing a letter to someone; it tells the SIP network where you want your message to go.
• Via:
• The Via header(s) trace the path of the request through the network. Each SIP proxy that forwards the request adds its own address to the Via headers. This way, responses can follow the same path back to the sender. Think of it as the postmarks on a letter that show each post office it has been through.
• NOTE : Regarding this, there is another note with further details on this.
• From:
• The From header shows who the request is from, essentially the initiator of the SIP session. It also includes a 'tag', which is a unique identifier for this session from the sender's side. This is like the return address on an envelope, letting the recipient know who sent the message.
• To:
• The To header specifies the intended recipient of the message. In the initial request, it doesn't contain a 'tag', but as the dialog progresses, a 'tag' is added to help identify the session. It's the address where you're sending the message, much like the address you write on the front of an envelope.
• Contact:
• The Contact header tells other SIP entities how to reach the user directly, providing a URI that points to the sender's current location (which can be different from the address in the From header). If you move during a dialog, your Contact header will update to reflect your new location, much like leaving a forwarding address if you move to a new house.

NOTE :How the address of 'To' and 'url in request line' would differ ?

In SIP (Session Initiation Protocol), the "To" header and the "Request-URI" (URL in the request line) serve different purposes, although they might contain similar or even the same information in certain scenarios.

In other words, While the Request-URI and "To" header might look similar at first glance, especially in simple calls directly from one user agent to another, their roles are distinct. The Request-URI is used for routing the request through the network to the current location of the recipient, while the "To" header identifies the intended recipient of the request and remains constant for the duration of the dialog.

• Request-URI:
• The Request-URI is the first line of a SIP request. It indicates the user or service to which the request is being sent. This is the primary address that determines the request's destination and routing through the SIP network.
• In an INVITE request, the Request-URI typically contains the address of the user being called. It is used by SIP proxies to route the request to the recipient's current location as known by the SIP registration system.
• The Request-URI can change throughout the path of the request as it gets proxied to different locations, especially in scenarios involving SIP registrars or redirect servers.
• To Header:
• The "To" header specifies the intended recipient of the message, not necessarily the address where the message is sent. It is used to indicate the user or service for which the request is ultimately intended.
• In contrast to the Request-URI, the "To" header remains the same throughout the dialog, regardless of how the request is routed. It identifies the recipient across the entire dialog and is used for dialog identification, often including a tag parameter after the initial request/response exchange.
• Example Scenario:
• If a user is registered with a SIP service and has multiple possible contact addresses, the Request-URI might point to a SIP proxy or registrar responsible for that user, which will then route the request appropriately based on the user's current location.
• The "To" header will specify the user's SIP URI directly and will not change, regardless of the user's location or any intermediaries involved in routing the request.

NOTE :How the address of 'From' and 'url in Contact header' would differ ?

The "From" header and the "Contact" header in SIP (Session Initiation Protocol) messages also serve different purposes and can contain different information. The "From" header is about the identity of the user as they want to be known in the SIP session, while the "Contact" header is about where and how to send messages to reach the user directly. The "From" header is more about SIP identity, and the "Contact" header is about actual reachability.

• From Header:
• The "From" header indicates the originator of the request. It represents the identity of the user who initiated the SIP message. This header is used throughout the dialog to identify the initiating party and typically does not change once the dialog has been established.
• The "From" header also carries a 'tag', which is a unique identifier for the dialog from the initiator's perspective.
• The address in the "From" header is generally the user's SIP URI that they wish to present to the other party, which might be a 'public' address that doesn't reveal the user's actual location or contactable address.
• Contact Header:
• The "Contact" header provides a direct URI at which the User Agent (UA) sending the message can be reached for subsequent messages within the dialog. It's essentially telling the other party, "Here's how you can get back to me directly."
• During registration, a UA sends its "Contact" header to inform the SIP server of its actual current location, which can be an IP address or a domain that resolves to the UA. This address is used for routing future SIP messages directly to the UA, bypassing the initial lookup process.
• The "Contact" header is especially important for mobile users or when a user is logged in through multiple devices. It can change from one registration to another as the user moves or switches devices.
• Example Scenario:
• Suppose a user is registered with a SIP provider and makes a call from their work phone. The "From" header might contain their public SIP URI like sip:user@example.com, which is the address they present to others.
• The "Contact" header will contain a URI that points directly to their work phone, like sip:user@work-ip-address, which may be an internal network address or a temporary location that the SIP server can use to send any SIP requests directly to the user's work phone for the duration of the registration.

< REGISTER / INVITE >

In this communication flow, the addresses serve specific roles: the Request-URI directs the message through the network, the "From" header identifies the sender, the "To" header specifies the intended recipient, and the "Contact" header indicates where the sender can be reached directly. These addresses ensure that SIP messages are correctly routed and that the session participants are properly identified throughout the dialog.

NOTE : See if this make a clearer sense to you based on the explanation above.

NOTE : Why (2) is same as (6) and (3) is same as (7) ? it looks counter intuitive to me.

In SIP (Session Initiation Protocol), the "From" and "To" headers have specific meanings and uses, and their values being the same in both the initial request and the response is by design.

In the context of a SIP dialog, the "From" and "To" headers maintain the continuity and state of the dialog. They are not used to indicate the direction of the message flow (who is sending and who is receiving) as might be done in traditional letter correspondence. Instead, they are used to maintain the context of the ongoing SIP dialog or transaction.

So, it is not counterintuitive once you understand that in SIP, the "From" and "To" headers are not about the direction of the current message, but rather about maintaining the consistency of the dialog or transaction context. This consistency is important for SIP proxies and user agents to route responses correctly and manage dialogs and transactions.

• (2) From and (6) From:
• The "From" header indicates the originator of the SIP request. When UA1 sends the REGISTER request, it populates the "From" header with its own SIP URI.
• The "200 OK" response uses the "From" header to refer back to the same originator of the request, which is UA1. The "From" header in the response doesn't change because it's still referring to the party that initiated the SIP transaction.
• (3) To and (7) To:
• The "To" header indicates the intended recipient of the SIP request. In the REGISTER request, the "To" header also contains UA1's SIP URI, as UA1 is registering itself with the SIP server (CSCF).
• The "200 OK" response includes the "To" header to refer back to the same SIP URI that was in the original REGISTER request. It confirms to whom the response is intended. In a REGISTER transaction, the "To" and "From" headers will often be the same because a user agent is registering its own address.

According to 3GPP 34 229-1 V10.2.0 (2013-07) A.1

According to 3GPP 34 229-1 V10.2.0 (2013-07) A.2.9

< SUBSCRIBE / NOTIFY >

This flow shows the process where UA1 subscribes to certain events related to UA2 and is then notified by the CSCF when those events occur. The "Contact" header's role is crucial for direct communication in response to the subscription, while the "From" and "To" headers in the NOTIFY request maintain the identities of the notifying entity and the intended recipient. The "Request-URI" facilitates the correct routing of these SIP messages within the network.

NOTE : Why (2) is same as (7) and (3) is same as (8) ? it looks counter intuitive to me.

In the context of SIP (Session Initiation Protocol) messaging for a SUBSCRIBE/NOTIFY transaction, the "From" and "To" headers maintain consistency across requests and responses for a given dialog. This is by design and is key to how SIP handles message dialog state and transaction correlation.

It may seem counterintuitive because we typically expect a "response" to reverse the "From" and "To" compared to the "request". However, in SIP, the "From" and "To" headers are used to maintain the context of the dialog, not to indicate the direction of the message flow. The "From" header always reflects the initiator of the dialog, and the "To" header always reflects the intended recipient as defined at the start of the dialog. This consistency is crucial for maintaining the dialog state and for SIP proxies and user agents to correctly handle and route the messages within a dialog.

• (2) From and (7) From:
• The "From" header indicates the originator of the request. When UA1 sends the SUBSCRIBE request, it populates the "From" header with its own address.
• For the subsequent NOTIFY request that UA1 receives, the "From" header still represents the originator of the SUBSCRIBE dialog, which is UA1. This is because the NOTIFY is part of the same dialog initiated by the SUBSCRIBE request. Thus, (2) and (7) are the same.
• (3) To and (8) To:
• The "To" header indicates the intended recipient of the request. In the SUBSCRIBE request from UA1, the "To" header contains the address of UA2, the party about which UA1 wants to receive notifications.
• In the NOTIFY request, the "To" header still represents UA2 because the NOTIFY is informing UA1 about an event pertaining to UA2. The NOTIFY is a response to the original SUBSCRIBE request, and within the same dialog, the "To" and "From" headers do not change. Thus, (3) and (8) are consistent.

< INVITE / BYE(MT) >

I don't think I need to put any further explanation on this. You may try with your own explanation based on the two examples shown above.

< From / To for whole VoLTE Sequence >