Indicating Change of Caller-ID
From Pbxnsip Wiki
There are certain situations when the caller-ID of a call needs to be changes. Examples include *69 or *66 (redial and call return), where the user-agent does not know a priori where the call will go.
UA with RFC 4916 support
If the user agent indicates support for RFC 4916, then the PBX uses that RFC. However, the Identity-related information are not provided.
UA without RFC 4916 support
SIP (RFC3261) does not permit the change of the To- and From-headers in an established dialog. Therefore, just changing the headers is no solution to the problem.
Using the Replaces header could be a solution to the problem. The PBX could initiate a new call that replaces the call which needs the caller-ID replacement. However, there are several reasons that make this approach problematic:
- Many user agents do not support the Replaces header or they do not support it properly.
- Using the Replaces header has side effects on the call-list of the user agents. Many user agents will show the incoming call as a new call and keep the old call in the call history.
- The media path must be re-negotiated. That means that there will be a short click sound during the replacement of the call.
Therefore, uses a new mechanism that only serves the purpose of changing the caller-ID on the display of the user agent. The user agent must indicate that it is able to receive these updates with a "Supported: callerid" in the INVITE request or a response to the INVITE. If this is the case, the system will send a INFO message in the dialog that has the format like in the example below:
INFO sip:123@test.com SIP/2.0 From: <sip:a@test.com>;tag=123 To: <sip:b@test.com>;tag=456 Call-ID: 123456789 CSeq: 1234 INFO Content-Length: … Content-Type: message/sipfrag From: "A" <sip:123@test.com> To: "B" <sip:456@test.com>
The body of the message contains a SIP message fragment (RFC3420) that contains the To- and From-headers as they should look like if it was possible to change the headers in a dialog (as if they had been received in the INFO request, so that the From/To direction is clear). Tags and other parameters should not be changed. The user agent should update the display and may change the local call history. However, it should not change the To- and From-headers of the dialog.
User agents that do not show the Supported header will not receive the INFO messages, because some user agents terminate the call upon receipt of a unknown media type.
