RFC 4916

Connected Identity in the Session Initiation Protocol (SIP)

📅 published June 2007, from ietf

RFC 4916: Connected Identity in the Session Initiation Protocol (SIP) 🎀

okay bestie, this is RFC 4916, and it's a Standards Track spec from June 2007 🌸

The vibe check:

Authors: J. Elwell from Siemens Enterprise Communications Limited 💜
Category: Standards Track ✨
Date: June 2007 📅
Updates: RFC 3261 (SIP) 🦋
Obsoletes: the title block doesn't list anything it obsoletes
Working group: Network Working Group 🧚

Status of This Memo 🌈

This one is an Internet standards track protocol for the Internet community, and the author literally wants you to talk about it and send improvements 🫶 Check the current edition of "Internet Official Protocol Standards" (STD 1) to see where this protocol stands. Distribution is unlimited, so share it 💅

Copyright Notice 💜

Abstract ✨

So, the big idea 🔥 A SIP User Agent (UA) that gets a dialog-forming request can send its identity back to the other UA using a request going the reverse direction, and an Authentication Service can sign that identity 🔐 Retargeting changes the Request-URI, so the User Agent Server (UAS) can end up with a different identity than the one in the To header field 👀 The same trick can show a change of identity mid-call too, like when something happens in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). 🦋

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Overview of Solution . . . . . . . . . . . . . . . . . . . . .  4
4.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Behaviour of a UA that Issues an INVITE Request
        Outside the Context of an Existing Dialog  . . . . . . . .  6
  4.2.  Behaviour of a UA that Receives an INVITE Request
        outside the Context of an Existing Dialog  . . . . . . . .  6
  4.3.  Behaviour of a UA Whose Identity Changes during an
        Established INVITE-initiated Dialog  . . . . . . . . . . .  7
  4.4.  General UA Behaviour . . . . . . . . . . . . . . . . . . .  7
    4.4.1.  Sending a Mid-Dialog Request . . . . . . . . . . . . .  7
    4.4.2.  Receiving a Mid-Dialog Request . . . . . . . . . . . .  8
  4.5.  Authentication Service Behaviour . . . . . . . . . . . . .  8
  4.6.  Verifier Behaviour . . . . . . . . . . . . . . . . . . . .  9
  4.7.  Proxy Behaviour  . . . . . . . . . . . . . . . . . . . . .  9
5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  5.1.  Sending Connected Identity after Answering a Call  . . . . 10
  5.2.  Sending Revised Connected Identity during a Call . . . . . 16
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
7.  Security considerations  . . . . . . . . . . . . . . . . . . . 21
8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 23

1. Introduction 🌸

okay so SIP (RFC 3261 [1]) starts sessions, but it also tells both ends who they're talking to 🫶 Users need that info to decide how to handle a call that SIP starts. The person who answers can be different from the first person called because of call forwarding, call distribution, or call pick-up 📞 And once a call is up, someone can get swapped for a different identity through call transfer, call park and retrieval, and similar stuff 🔄 Sometimes there are reasons not to reveal these identities, but having a way to share them is still super desirable ✨

This document extends the From header field so it can carry "connected identity" info (the identity of the connected user) in either direction within an existing INVITE-initiated dialog 💅 It can be used to convey:

the callee identity to a caller when a call is answered;
the identity of a potential callee prior to answer; or
the identity of a user that replaces the caller or callee following a call rearrangement such as call transfer carried out within the PSTN or within a back-to-back user agent (B2BUA) using third party call control techniques.

Note that the use of standard SIP call transfer techniques, involving the REFER method, leads to the establishment of a new dialog and hence normal mechanisms for caller and callee identity apply. 🦋

The identity of the responder in a response (commonly called "response identity") is totally out of scope for this doc 🙅‍♀️

Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS. Providing identity in a separate request allows normal authentication techniques to be used. 🔐

2. Terminology 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 💖

This spec also defines some extra terms, so pay attention 👑

caller: the user of the UA that issues an INVITE request to initiate a call.
caller identity: the identity (Address of Record) of a caller.
callee: the user of the UA that answers a call by issuing a 2xx response to an INVITE request.
callee identity: the identity (Address of Record) of a callee.
potential callee: the user of any UA to which an INVITE request is targeted resulting in formation of an early dialog, but because of parallel or serial forking of the request, not necessarily the user that answers the call. 🧚
connected user: any user involved in an established call, including the caller, the callee or any user that replaces the caller or callee following a call re-arrangement such as call transfer. ✨
connected identity: the identity (Address of Record) of a connected user. 💜

3. Overview of Solution 🦋

So the main move is a mid-dialog request that provides connected identity 💅 The User Agent Client (UAC) for that request puts its identity in the From header field. For the auth part, the Identity header field (RFC 4474 [3]) gets added by a suitable Authentication Service sitting on the path of the mid-dialog request 🔐 Unless the UAC handles it, the Authentication Service is expected to be at a proxy that record routes and is able to authenticate the UAC.

A request going the opposite way from the INVITE, either before or right when the call gets answered, can show the potential callee or callee identity 📞 A request going the same way as the INVITE before answer can show a change of caller 🔄 A request in either direction after answering can show a change of the connected user 🌈 In every case, a dialog (early or confirmed) has to exist before one of these requests can be sent. ⭐

This solution uses the UPDATE method (RFC 3311 [4]) for the request, or the re-INVITE method in some circumstances 🎀 To send the callee identity, the UAS for the INVITE request sends the UPDATE request after sending the 2xx response to the INVITE and after receiving an ACK request. To send the potential callee identity, RFC 3262 [5] is expected to be supported 🙌 In that case, the UAS for the INVITE sends the UPDATE request after receiving and responding to a PRACK request (which happens after sending a reliable 1xx response to the INVITE). The UPDATE request could conceivably be used for other stuff too, for example, it could be used during an early dialog to send the potential callee identity at the same time as a Session Description Protocol (SDP) offer for early media 🧚 To show a connected identity change during an established call, either the UPDATE method or the re-INVITE method can be used. The re-INVITE method would be used if required for other purposes (for example, when a B2BUA does transfer using Third Party Call Control (3PCC) techniques, it has to issue a re-INVITE request without an SDP offer to solicit an SDP offer from the UA). 🦋

This solution changes the URI (not the tags) in the To and From header fields of mid-dialog requests and their responses, compared with the matching values in the dialog forming request and response 💅 Changing the To and From header field URIs was contemplated in Section 12.2.1.1 of RFC 3261 [1], which says:

"Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543 [6], which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification."

So this document deprecates mandatory reflection of the original To and From URIs in mid-dialog requests and their responses, which is a change to RFC 3261 [1] 🫶 It doesn't make any provision for proxies that can't handle a URI change, since changing the URI has been expected for a long time 🕰️ To cover any UAs that can't handle a URI change, there's a new option tag "from-change" that gives a positive indication of support in the Supported header field 🌸 If you only send a request with a changed From header field URI to targets that have indicated support for this option, you don't need to put this option tag in a Require header field ✨

Beyond letting the From header field URI change mid-dialog to reflect connected identity, this document also says that a UA which got a connected identity in the URI of the From header field of a mid-dialog request has to use that URI in the To header field of any later mid-dialog request it sends 💖

If there's no suitable Authentication Service on the path of the mid-dialog request, the UAS gets an unauthenticated connected identity (meaning no matching Identity header field). The implications of this are discussed in Section 7 🔐

4. Behaviour 🎀

4.1. Behaviour of a UA that Issues an INVITE Request Outside the Context of an Existing Dialog 💅

When a UA issues an INVITE request outside an existing dialog, a UA compliant with this specification MUST include the "from-change" option tag in the Supported header field 🙌

Note that sending the "from-change" option tag does not guarantee that connected identity will be received in subsequent requests. 🙈

4.2. Behaviour of a UA that Receives an INVITE Request outside the Context of an Existing Dialog ✨

Okay bestie, so the moment a UA gets an INVITE request, it MUST put the from-change option tag in the Supported header field of any dialog-forming response 💖. Heads up though: sending that tag does NOT guarantee you'll get the connected identity when the caller changes 😭. It's a vibe check, not a promise.

After an early dialog exists, if the from-change tag showed up in a Supported header field, the UA MAY send an UPDATE request (RFC 3311 [4]) on that same dialog 🦋. There's a catch, though: it's only allowed once the UA has sent a reliable provisional response to the INVITE and has received and answered a PRACK request. Once a full dialog is formed (after the 2xx final response to the INVITE), the rules get stricter. If from-change was received and no UPDATE has gone out on the early dialog yet, the UA MUST issue an UPDATE request on that same dialog 👑. Either way, that UPDATE MUST carry the callee's (or potential callee's) identity in the URI of the From header field, or an anonymous identity if anonymity is required 🎀.

Sending a fresh request is worth it even when the URI matches the To header field URI from the INVITE 🙈. It lets the Authentication Service assert authentication for that identity, and it also tells the peer UA that the connected identity is the same as the one in the INVITE's To header field URI.

4.3. Behaviour of a UA Whose Identity Changes during an Established INVITE-initiated Dialog 🌸

Here's the deal: if from-change was received in a Supported header field during an INVITE-initiated dialog, and the identity tied to the UA changes (say, because of a transfer) compared with the last identity in the From header field of a request that UA sent, the UA MUST send a request on that same dialog containing the new identity in the URI of the From header field (or an anonymous identity if anonymity is required) 🔥. For this, the UA MUST use the UPDATE method, unless a re-INVITE is being used at the same time for other reasons 🧚.

4.4. General UA Behaviour 💅

4.4.1. Sending a Mid-Dialog Request

When a UA sends a mid-dialog request, it MUST follow the requirements of RFC 4474 [3] when filling in the From header field URI, including the provisions for anonymity 🫶.

This lets an Authentication Service on the path of the mid-dialog request insert an Identity header field. Main character energy 👑.

When a UA sends a mid-dialog request, it MUST fill the To header field URI with the current remote URI for that dialog. That value can change under the rules in Section 4.4.2 of this document, instead of being locked in at the start of the dialog like RFC 3261 [1] says 🦋.

After a UA sends a request with a revised From header field URI (revised compared with the URI in the From header field of the previous request on this dialog, or with the To header field of the received dialog-forming INVITE if nothing has been sent yet), it MUST keep using that same URI in the From header field of any future requests on the same dialog, unless the identity changes again 💖. The UA also MUST be prepared to receive the revised URI in the To header field of later mid-dialog requests. It MUST ALSO keep being ready to receive the old URI, at least until a request arrives with the revised URI in its To header field 🌈.

Mid-dialog requests can get rejected under RFC 4474 [3] if the UAS doesn't accept the connected identity 😬. If the UAC gets a 428, 436, 437, or 438 response to a mid-dialog request, it SHOULD treat the dialog as terminated when the request was dialog-terminating 💀. For any other request, it SHOULD take no action ⭐.

Trying again or sending any other mid-dialog request will probably get the same response 🙃, since the UA has no control over what the Authentication Service does.

4.4.2. Receiving a Mid-Dialog Request

If a UA gets a mid-dialog request from its peer, it can use the identity in the From header field URI (for example, by showing it to the user) 🎀. The UA MAY tell signed identities apart from unsigned ones 🌸. For a signed identity, the UA SHOULD invoke a Verifier (see Section 4.6) if it can't rely on there being a Verifier on the path of the request 🔍.

If a UA gets a mid-dialog request from its peer where the From header field URI differs from the one in the previous request on that dialog, or from the one in the To header field of the original INVITE, AND the UA sends a 2xx response, then the UA MUST update the remote URI for this dialog, as defined in RFC 3261 [1] 💜. That new value then shows up in the To header field of later requests the UA sends, following Section 4.4.1 🦋. If the UA sends any other final response, it MUST NOT update the remote URI for this dialog 🙅.

4.5. Authentication Service Behaviour 🔐

An Authentication Service MUST behave according to RFC 4474 [3] when it's dealing with mid-dialog requests ✨.

RFC 4474 doesn't say what to do when the identity in the From header field is one the UAC isn't allowed to assert 🫣. So it's up to local policy whether to reject the request or forward it without an Identity header field. That policy can also be different for mid-dialog requests than for other requests.

When UAs follow this specification, the Authentication Service should (subject to the normal authentication rules) be able to authenticate the sender as the entity named in the From header field, so it can provide a signature for that identity 🫶. Compare that with UAs that don't support this specification 💀: there, retargeting and mid-dialog identity changes can make the From header field an unreliable way to tell who actually sent the request.

4.6. Verifier Behaviour 🕵️‍♀️

When it's dealing with mid-dialog requests, an Authentication Service MUST behave according to RFC 4474 [3], updated as described below 💅.

RFC 4474 [3] says it's a matter of policy whether to reject a request with a 428 (Use Identity Header) response when the request has no Identity header field 🙈. A UA MAY use a different policy for mid-dialog requests than it uses for other requests 🌈.

4.7. Proxy Behaviour 🧚

A proxy that receives a mid-dialog request MUST be ready for the To header field URI and/or the From header field URI to differ from the ones in the dialog-forming request and response 💖.

A proxy that can provide an Authentication Service for mid-dialog requests MUST record route if Supported: from-change is in the dialog-forming request the proxy got from the UAC 👑.

5. Examples 📞

In the examples below, several messages have unfolded lines longer than 72 characters 😭. Those are captured between tags. To get the single unfolded line back, you directly concatenate all the lines between the tags, throwing away any line-feeds or carriage returns 🎀.

In the examples, the domain example.com is assumed to have the private key below (in PEM format) 🔑. The Authentication Service uses that private key to generate the signature in the Identity header field 🦋.

5.1. Sending Connected Identity after Answering a Call 📲

In this example, Carol's UA was reached through retargeting at the proxy 🔁. So her identity (AoR) is NOT the same as the one in the To header field of the INVITE she received (Bob) 👀. Carol's UA puts her identity in the From header field of an UPDATE request 💜. The proxy also runs an Authentication Service, so it adds Identity and Identity-Info header fields to that UPDATE request ✨.

Alice's UA        PROXY +          Carol's UA
              Authentication
                 Service

      INVITE(1)            INVITE(2)
  ---------------->   ---------------->

       200(4)                200(3)
  <----------------   <----------------

       ACK(5)                ACK(6)
  ---------------->   ---------------->

      UPDATE(8)            UPDATE(7)
  <----------------   <----------------

       200(9)                200(10)
  ---------------->   ---------------->

INVITE (1):

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

INVITE (2):

INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
<allOneLine>
Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1
3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT
p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
</allOneLine>
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 (3):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
<allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>

Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (5):

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0

ACK (6):

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.
1
</allOneLine>
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0

UPDATE (7):

UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0

Heads up, bestie 🫶 The URI in the From header field is different from the one in the To header field of the INVITE request/response 👀 BUT the tag is still the same one that showed up in the INVITE response. So the tag is the thing to match on, not the URI 💅

UPDATE (8):

UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 69
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
<allOneLine>
Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t
ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9
KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (9):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.
0.2.2
</allOneLine>
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

200 (10):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
3
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

5.2. Sending Revised Connected Identity during a Call 🎀

Okay, so picture this: Alice and Bob are on a call, but Bob is hiding behind a B2BUA (he's not shown in the diagram, so no peeking 🙈). Bob's identity gets sent over in an UPDATE request. Then the B2BUA does call transfer with third party call control (3PCC) stuff, as described in RFC 3725 [7] (think a click-to-dial app running the show 📞). Now Alice is connected to Carol (also not shown, sorry bestie), and a re-INVITE request goes out so the session can be renegotiated 🔄. The B2BUA acts as the Authentication Service, so it's the one that generates the Identity header field in the re-INVITE request, to authenticate Carol's identity 🔐.

Here's the whole vibe in one picture ✨:

Alice's UA        B2BUA

      INVITE(1)
  ---------------->

       200(2)
  <----------------

       ACK(3)
  ---------------->

      UPDATE(4)
  <----------------

       200(5)
  ---------------->

    re-INVITE(6)
  <----------------

       200(7)
  ---------------->

       ACK(8)
  <---------------

INVITE (1):

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 (2):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
1
</allOneLine>
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (3):

ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

UPDATE (4):

UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO
UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c
D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (5):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.
2.2
</allOneLine>
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

re-INVITE (6):

INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
<allOneLine>
Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp
al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U
3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
</allOneLine>
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (7):

SIP/2.0 200 OK
<allOneLine>
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.
2.2
</allOneLine>
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (8):

ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154

v=0
o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
s=Session SDP
c=IN IP4 ua3.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

6. IANA Considerations 🦋

Here's the IANA bit: this spec registers a brand new SIP option tag, following the guidelines in Section 27.1 of RFC 3261 [1] ✨.

This document defines the SIP option tag "from-change" 💜.

The following row has been added to the "Option Tags" section of the SIP Parameter Registry:

+------------+------------------------------------------+-----------+
| Name       | Description                              | Reference |
+------------+------------------------------------------+-----------+
| from-change| This option tag is used to indicate that | [RFC4916] |
|            | a UA supports changes to URIs in From    |           |
|            | and To header fields during a dialog.    |           |
+------------+------------------------------------------+-----------+

7. Security considerations 🔐

RFC 4474 [3] digs into the security considerations for the Identity header field in a lot of detail, and all of those same considerations apply when you use the Identity header field to authenticate a connected identity in the From header field URI of a mid-dialog request 🫶.

Okay, serious moment, bestie 💀 A From header field URI in a mid-dialog request that has no valid Identity header field (or other means of authentication), either in this request or in an earlier request on this dialog, cannot be trusted (except in very closed environments). It's expected to be handled the same way as a From header field in a dialog-initiating request that isn't backed up by a valid Identity header field. That said, it's recommended not to reject a mid-dialog request just because the Identity header field is missing, since that would mess with the ongoing call. A missing valid Identity header field can change what info gets shown to the user, and a UA can clear the call if policy or user preference says so.

A signed connected identity in a mid-dialog request (a URI in the From header field along with a valid Identity header field) tells you about the peer UA in a dialog 👀. For the UA that was the UAS in the dialog-forming request, this identity isn't necessarily the same as the one in the To header field of that dialog-forming request. That's because of retargeting while the dialog-forming request was being routed. A signed connected identity says nothing about whether that retargeting was legit; it just reflects what the retargeting produced. History information (RFC 4244 [8]) can give extra hints about how the connected user got reached 🕵️‍♀️.

Likewise, when a signed connected identity shows a change of identity during a dialog, it tells you nothing about why that change happened or whether it's legitimate 🙃.

Using the sips URI scheme can cut down on the chances of attacks where inappropriate connected identity info gets sent, either at call establishment time or during a call 🔒✨.

Anonymity can be needed by the user of a connected UA 🙈. For anonymity, the UA is expected to fill in the URI in the From header field of a mid-dialog request the way RFC 4474 [3] describes 🧚.

8. Acknowledgments ✨

Huge thank-you to my besties who gave super valuable comments 🫶 Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani, Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, Shida Schubert, Ya-Ching Tan, and Dan Wing. You all are literally the reason this spec is so iconic 👑

9. References

9.1. Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📚
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 🪪
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. 🔄
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. 🛎️

9.2. Informative References

[6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 🕰️
[7] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC 3725, June 2002. 🎭
[8] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. 🗂️

Author's Address 🎀

John Elwell
Siemens Enterprise Communications Limited
Technology Drive
Beeston, Nottingham  NG9 1LA
UK

Phone: +44 115 943 4989
EMail: john.elwell@siemens.com

Full Copyright Statement 💜

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from

ietf: rfc4916 2007-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms