The values in the "resource-share" header field field are defined as follows: The Resource-Share header field contains the "origin", "rules" and "timestamp" header field parameters.

The "origin" header field parameter is used to identify the source of the resource sharing information. The values in the "origin" header field field are defined as follows:

The "rules" header field parameter carries one or more rules for resource sharing. Each rule is included in the same order as the corresponding m-line in the SDP offer/answer and consists of the following parts:

The "timestamp" header field parameter indicates when the application server determined the resource sharing rules and is used to determine the most applicable resource sharing option. The value is a counter unique for each user and is increased and inserted in the header field each time the application server includes a Resource-Share header field in a request or response involving a UE registered by the user. When the P-CSCF receives a Resorce-Share header field, the P-CSCF extracts and stores the extracted resource sharing rule along with the value of the received "timestamp" header field as follows:

1. if a resource sharing rule identified by the sharing key is not already stored, store the extracted resource sharing rule along with the value of the received "timestamp" header field;
2. if a resource sharing rule identified by the sharing key is already stored with a lower timestamp value than the value of the received "timestamp" header field, replace the stored resource sharing rule with the extracted resource sharing rule along with the value of the received "timestamp" header field; or
3. if a resource sharing rule identified by the sharing key is stored with a higher timestamp value than the value of the received "timestamp" header field, discard the extracted resource sharing rule.

The "timestamp" header field can be reset to "0" when none of the UEs registered by the user is involved in a session any longer.

The following subclauses describe examples on how:

• the P-CSCF indicates in the REGISTER request that P-CSCF supports receiving information about resource sharing;
• the application server sends information about potential resource sharing to the P-CSCF; and
• the P-CSCF extracts resource sharing information for media-streams.

When P-CSCF receives a REGISTER request from a UE served by the P-CSCF, the P-CSCF can include a Resource-Share header field indicating that the P-CSCF supports receiving information about resource sharing. The example 1 shows the coding when the P-CSCF indicates that the P-CSCF is interested in receiving information about resource sharing in a REGISTER request.

When the application server receives a request or response containing an initial SDP offer/answer with media streams subject for resource sharing, the application server includes the Resource-Share header field with the value "media-sharing" and includes a "origin" header field parameter set to "session-initiator" or "session-receiver" depending on if the application server is serving the user that initiated the session invitation or if the application server is serving the user receiving the session invitation. The application server includes resource sharing information in a "rules" header field parameter with one resource sharing rule per media stream in the same order the corresponding m-line appears in the SDP. Each resource sharing rule is constructed as follows:

1. if the media stream is subject for resource sharing, the application server:
   • includes a "new-sharing-key" part;
   • if it is the INVITE request and the request will be sent to more than one UE, includes an "existing-resource-sharing-list" part containing one or more sharing keys already in use in other sessions involving UEs that potentially can receive the session invitation due to the forking of the INVITE request; and
   • includes a "directionality" part indicating in which direction resources sharing can apply; or
2. if the media stream can never be shared, includes an empty string.

Finally, the application server includes a "timestamp" header field parameter with a value higher than included in any other Resource-Share header field involving any of the UEs registered by the user. The example 1 shows the Resource-Share header field when included in the initial SDP answer on the originating side. The SDP answer contains two media streams and both media streams are subject to resource sharing. The example 2 shows the Resource-Share header field when included in the initial SDP offer on the terminating side. The user has several UEs registered where three UEs are already involved in sessions with media streams subject to resource sharing. The SDP offer contains three media streams where only the first and third media stream is subject to resource sharing identified by K2,K3 and K4 for the first media stream and K21, K22 and k23 for the third media stream in already ongoing sessions. The fact that the second media stream is not subject to resource sharing is indicated as an empty string in second position in the comma delimited list of resource sharing rules in the "rules" header field parameter. The example 3 shows the Resource-Share header field when included in a SIP request or SIP response on the originating side when an application server indicates that resources can not be shared due to some service specific reason. This indication can be included already from the beginning of the session or at any point during a session if the SIP proxy or UA determines that resource sharing is not possible any longer.

When the P-CSCF receives an initial SDP answer destined for the served UE in a request or response containing the Resource-Share header field, the P-CSCF extracts the resource sharing rules for each media stream from the "rules" header field parameter in the same order that the corresponding m-line appear in the SDP. The P-CSCF stores and uses the value in the "new-sharing-key" to identify the resource sharing rule for a media stream. When the P-CSCF receives an initial SDP offer destined for the served UE in a request, the P-CSCF extracts the resource sharing rules for each media stream from the "rules" header field parameter in the same order that the corresponding m-line appear in the SDP. For each extracted resource sharing rule the P-CSCF checks if the UE is involved in any session using a sharing key in the "existing-sharing-key-list" to identify a media-stream, and

• if the UE is involved in a session using a sharing key in the "existing-sharing-key-list" to identify a media-stream, the P-CSCF stores and uses that sharing key value to identify this resource sharing rule for the media stream in this session; or
• if none of the sharing keys in the "existing-sharing-key-list" is used by any session involving the UE or if the "existing-sharing-key-list" is empty, the P-CSCF stores and uses the value in the "new-sharing-key" to identify this resource sharing rule for this media stream in this session.

If the P-CSCF receives a Resource-Share header field with the value "no-media-sharing" for media streams where resource sharing is already applied due to receipt of a Resource-Share header field with the value "media-sharing" prior to receiving "no-media-sharing" value, the SIP proxy stops media sharing as specified in TS 29.214 Annex A.