IMS - Forwarding calls flow in SIP - SDP negotiation

Question

I'm trying to understand how forwarding should work in an IMS deploy. Forwarding is performed by an AS in the middle of the SIP path, for example when the original called subscriber doesn't answer the call. In that case, the AS cancels the call (sends a CANCEL), and sends a new INVITE to the forwarded user. Before sending the CANCEL, however, the original called party has already issued his SDP answer in a reliable manner (183 with 100rel).

In the new INVITE, the SDP offer from the original calling party is used, and the forwarded user sends his own SDP answer, that obviously, differs from the original called party. the AS, when receiving this answer, and since it already sent the answer from the original called party, instead of just relaying this new answer, sends an UPDATE to the calling party, with the new answer. The UPDATE is accepted by the calling party and later on the call is established.

What concerns me is that according to RFC 3264, section 8 "Modifying the Session":

When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP.

In this case, looking at the trace, the SDP issued in the UPDATE is completely different, including the o= line, as it comes from a different agent. Should the AS manipuate the SDP of the new SDP answer to hide the fact that it comes from another UA? Is there another more standard way for this flow?

Thanks for your insight.

Answer 1

What concerns me is that according to RFC 3264, section 8 "Modifying the Session":

When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP.

Provided this is the same SIP endpoint or B2BUA. see below the rational.

In this case, looking at the trace, the SDP issued in the UPDATE is completely different, including the o= line, as it comes from a different agent. Should the AS manipuate the SDP of the new SDP answer to hide the fact that it comes from another UA? Is there another more standard way for this flow?

UPDATE method can serve several purpose :

1. Change the signaling information (let's say SIP headers)
2. Change the media information (let's say SDP fields)
3. Update both at the same time.

You are in the third case, the SIP endpoint has changed so the SDP must be different.

From the AS point of view, 99% of the time the AS must be transparent to those changes and act as a pure SIP proxy BUT there are some specific cases where it may act as a B2BUA and hide that from the caller using RTP proxy.