Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.3  Procedures at the I-CSCFWord‑p. 219

5.3.0  General |R14|

When sending a failure response to any received request, depending on operator policy, the I-CSCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "i-cscf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.

5.3.1  Registration procedure

5.3.1.1  General

During the registration procedure the I-CSCF shall behave as a stateful proxy.

5.3.1.2  Normal procedures

When the I-CSCF receives a REGISTER request, the I-CSCF shall verify whether or not it has arrived from a trusted domain. If the request has not arrived from a trusted domain, the I-CSCF shall complete the processing of the request by responding with 403 (Forbidden) response. Otherwise, the I-CSCF starts the user registration status query procedure to the HSS as specified in TS 29.228.
If the REGISTER request does not include an Authorization header field and private user identity, the I-CSCF shall derive the private user identity from the public user identity being registered, contained in the To header field, by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters.
Prior to performing the user registration query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228. As a result of the query the I-CSCF gets the Redirect-Host AVP.
If the user registration status query response from the HSS includes a valid SIP URI, the I-CSCF shall:
  1. replace the Request-URI of the received REGISTER request with the SIP URI received from the HSS in the Server-Name AVP;
  2. optionally include the received Redirect-Host AVP value in the P-User-Database header field as defined in RFC 4457; and
  3. forward the REGISTER request to the indicated S-CSCF.
If the user registration status query response from the HSS includes a list of capabilities, the I-CSCF shall:
  1. select a S-CSCF that fulfils the indicated mandatory capabilities - if more than one S-CSCFs fulfils the indicated mandatory capabilities the S-CSCF which fulfils most of the possibly additionally indicated optional capabilities;
  2. replace the Request-URI of the received REGISTER request with the URI of the S-CSCF;
  3. optionally, include the received Redirect-Host AVP value in the P-User-Database header field as defined in RFC 4457; and
  4. forward the REGISTER request to the selected S-CSCF.
When the I-CSCF receives a 2xx response to a REGISTER request, the I-CSCF shall forward the 2xx response to the P-CSCF.
Up

5.3.1.3  Abnormal casesWord‑p. 220
In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 403 (Forbidden) response to the UE.
If the HSS sends a negative response to the user registration status query request, the I-CSCF shall send back a 403 (Forbidden) response.
If the user registration status query procedure cannot be completed, e.g. due to time-out or incorrect information from the HSS, the I-CSCF shall send back a 480 (Temporarily Unavailable) response to the UE.
If a selected S-CSCF:
  • does not respond to the REGISTER request and its retransmissions by the I-CSCF; or
  • sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request;
and:
  • the REGISTER request did not include an "integrity-protected" header field parameter in the Authorization header field;
  • the REGISTER request did include an "integrity-protected" header field parameter in the Authorization header field with a value set to "no" in the Authorization header field;
  • the REGISTER request did include an "integrity-protected" header field parameter in the Authorization header field with a value set to other than "no" and the I-CSCF supports S-CSCF restoration procedures; or
  • the REGISTER request did not include an Authorization header field and the I-CSCF supports S-CSCF restoration procedures;
then:
  • if the I-CSCF has received the list of capabilities from the HSS, the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same registration procedure; or
  • if the I-CSCF has received a valid SIP URI from the HSS because the S-CSCF is already assigned to other UEs sharing the same public user identity, it will request the list of capabilities from the HSS and, on receiving these capabilities, the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same registration procedure.
If a selected S-CSCF does not respond to a REGISTER request and its retransmissions by the I-CSCF and none of the conditions specified above in this case are fulfilled, the I-CSCF shall send back a or 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261.
If the I-CSCF cannot select a S-CSCF which fulfils the mandatory capabilities indicated by the HSS, the I-CSCF shall send back a 600 (Busy Everywhere) response to the user.
Up

5.3.2  Initial requestsWord‑p. 221

5.3.2.1  Normal procedures

The I-CSCF may behave as a stateful proxy for initial requests.
Upon receipt of a request, the I-CSCF shall perform the originating procedures as described in subclause 5.3.2.1A if the topmost Route header field of the request contains the "orig" parameter. Otherwise, the I-CSCF shall continue with the rest of the procedures of this subclause.
When the I-CSCF receives a request, the I-CSCF shall verify whether it has arrived from a trusted domain or not. If the request has arrived from a non trusted domain, then the I-CSCF shall remove all P-Charging-Vector header fields and all P-Charging-Function-Addresses header fields the request may contain.
For all SIP transactions identified:
  • if priority is supported, as containing an authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;
the I-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the I-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
The I-CSCF shall discard the P-Profile-Key header field, if the I-CSCF receives the P-Profile-Key header field in a SIP request or response.
When the I-CSCF receives, destined for a served user or a PSI, an initial request for a dialog or standalone transaction the I-CSCF shall:
1)
if the Request-URI includes:
  1. a pres: or an im: URI, then translate the pres: or im: URI to a public user identity and replace the Request-URI of the incoming request with that public user identity; or
  2. a SIP-URI that is not a GRUU and with the user part starting with a + and the "user" SIP URI parameter equals "phone" then replace the Request-URI with a tel-URI with the user part of the SIP-URI in the telephone-subscriber element in the tel-URI, and carry forward the tel-URI parameters that may be present in the Request-URI; or
  3. a SIP URI that is a GRUU, then obtain the public user identity or an identity of the UE that represents the functionality within the UE that performs the role of registrar from the Request-URI and use it for location query procedure to the HSS. When forwarding the request, the I-CSCF shall not modify the Request-URI of the incoming request;
2)
remove its own SIP URI from the topmost Route header field, if present; and
3)
check if the domain name of the Request-URI matches with one of the PSI subdomains configured in the I-CSCF. If the match is successful, the I-CSCF resolves the Request-URI by an internal DNS mechanism into the IP address of the AS hosting the PSI and does not start the user location query procedure. Otherwise, the I-CSCF will start the user location query procedure to the HSS as specified in TS 29.228 for the called PSI or user, indicated in or derived from the Request-URI. Prior to performing the user location query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228.
When the I-CSCF receives any response to such a request, the I-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.
When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, then the I-CSCF shall apply the procedures described in RFC 4028 clause 8.
In case the I-CSCF is able to resolve the Request-URI into the IP address of the AS hosting the PSI, then the I-CSCF shall:
1)
store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. If no P-Charging-Vector header field was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260. The I-CSCF shall insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameter. The I-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The I-CSCF shall not include the type 3 "term-ioi" header field parameter. Based on local policy, the I-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier; and
2)
forward the request directly to the AS hosting the PSI.
Upon successful user location query, when the response contains the URI of the assigned S-CSCF, or the URI of an AS hosting the PSI, the I-CSCF shall:
1)
insert the URI received from the HSS as the topmost Route header field;
2)
store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the P-Charging-Vector header field in the P-Charging-Vector header field. If no "icid-value" header field parameter was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260;
2A)
based on local policy, add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;
3)
optionally, include the received Redirect-Host AVP value in the P-User-Database header field as defined in RFC 4457;
3A)
if the Wildcarded Identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded identity value in the P-Profile-Key header field as defined in RFC 5002; and
4)
forward the request based on the topmost Route header field.
Upon successful user location query, when the response contains information about the required S-CSCF capabilities, the I-CSCF shall:
1)
if overlap signalling using the multiple-INVITEs method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, route the new INVITE to the same next hop as the previous INVITE request; otherwise
2)
select a S-CSCF according to the method described in TS 29.228;
3)
insert the URI of the selected S-CSCF as the topmost Route header field value;
4)
execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location query, when the response contains the URI of the assigned S-CSCF);
5)
optionally, include the received Redirect-Host AVP value in the P-User-Database header field as defined in RFC 4457;
6)
if the Wildcarded Identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded identity value in the P-Profile-Key header field as defined in RFC 5002; and
7)
forward the request to the selected S-CSCF.
Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if the Request-URI is a tel URI containing a public telecommunications number as specified in RFC 3966, the I-CSCF may support a local configuration option that indicates whether or not request routeing is to be attempted. If the local configuration option indicates that request routeing is to be attempted, then the I-CSCF shall perform one of the following procedures based on local operator policy:
1)
forward the request to the transit functionality for subsequent routeing; or
2)
invoke the portion of the transit functionality that translates the public telecommunications number contained in the Request-URI to a routeable SIP URI, and process the request based on the result, as follows:
  1. if the translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the home network, or the I-CSCF may send an appropriate SIP response to the originator, such as 404 (Not Found) or 604 (Does not exist anywhere). When forwarding the request to a BGCF or any other appropriate entity, the I-CSCF shall leave the original Request-URI containing the tel URI unmodified:
    1. if overlap signalling using the multiple-INVITEs method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, the I-CSCF shall route the new INVITE to the same next hop as the previous INVITE request; and
    2. additional procedures apply if the I-CSCF supports NP capabilities and these capabilities are enabled by local policy, and the database used for translation from an international public telecommunications number to a SIP URI also provides NP data (for example, based on the PSTN Enumservice as defined by RFC 4769 or other appropriate data bases). If the above translation from an international public telecommunications number to a SIP URI failed, but NP data was obtained from the database, then the I-CSCF shall replace the tel-URI in the Request-URI with the obtained NP data, prior to forwarding the request to the BGCF or other appropriate entity. The URI is updated by the I-CSCF by adding the NP parameters defined by RFC 4694 to the tel-URI in the Request-URI: an "npdi" tel-URI parameter is added to indicate that NP data retrieval has been performed, and if the number is ported, an "rn" tel-URI parameter is added to identify the ported-to routeing number. The I-CSCF shall perform these procedures if the tel-URI in the received Request-URI does not contain an "npdi" tel-URI parameter. In addition, the I-CSCF may, based on local policy, perform these procedures when the tel-URI in the received Request-URI contains an "npdi" tel-URI parameter indicating that the NP data has been previously obtained; or
  2. if this translation succeeds, then replace the Request-URI with the routeable SIP URI and process the request as follows:
    • determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header field if present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination address is of an IP address type other than the IP address type used in the IM CN subsystem), the I-CSCF shall:
      1. if the I-CSCF supports indicating the traffic leg as specified in RFC 7549 and required by local policy, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI; and
      2. forward the request to the destination address via an IBCF in the same network;
    • if network hiding is needed due to local policy, put the address of the IBCF to the topmost Route header field;
    • route the request based on SIP routeing procedures; and
    • if overlap signalling using the multiple-INVITE method is supported as a network option, and if the I-CSCF receives an INVITE request outside an existing dialog with the same Call ID and From header as a previous INVITE request during a certain period of time, route the new INVITE to the same next hop as the previous INVITE request.
Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if local operator policy does not indicate that request routeing is to be attempted, then, the I-CSCF shall return an appropriate unsuccessful SIP response. Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if if the Request-URI is a SIP URI, the I-CSCF shall also return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) or 604 (Does not exist anywhere) in the case the user is not a user of the home network.
Upon an unsuccessful user location query when the response from the HSS indicates that the user is not registered and no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 480 (Temporarily unavailable) response if the user is recognized as a valid user, but is not registered at the moment and it does not have services for unregistered users.
When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route header field pointing to itself, the I-CSCF shall determine from the entry in the Route header field whether it needs to do HSS query. In case HSS query not is needed, then the I-CSCF shall:
  1. remove its own SIP URI from the topmost Route header field; and
  2. route the request based on the Request-URI.
When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one Route header field, the I-CSCF shall:
  1. remove its own SIP URI from the topmost Route header field; and
  2. forward the request based on the topmost Route header field.
When the I-CSCF receives a response to an initial request (e.g. 183 (Session Progress) response or 2xx response), the I-CSCF shall store the values from the P-Charging-Function-Addresses header field, if present. If the next hop is outside of the current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header field prior to forwarding the message.
When the I-CSCF receives any response to the initial request for a dialog or standalone transaction containing a "term-ioi" header field parameter in the P-Charging-Vector header field from the AS hosting the PSI, the I-CSCF shall:
  1. remove all received "orig-ioi" and "term-ioi" header field parameters from the forwarded response;
  2. insert the stored "orig-ioi" header field parameter if received in the request; and
  3. insert a type 2 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response.
When the I-CSCF, upon sending an initial INVITE request to the S-CSCF, receives a 305 (Use Proxy) response from the S-CSCF, the I-CSCF shall forward the initial INVITE request to the SIP URI indicated in the Contact field of the 305 (Use Proxy) response, as specified in RFC 3261.
Up

5.3.2.1A  Originating procedures for requests containing the "orig" parameter |R7|Word‑p. 225
The procedures of this subclause apply for requests received at the I-CSCF when the topmost Route header field of the request contains the "orig" parameter.
The I-CSCF shall verify for all requests whether they arrived from a trusted domain or not. If the request arrived from a non trusted domain, then the I-CSCF shall respond with 403 (Forbidden) response.
If the request arrived from a trusted domain, the I-CSCF shall perform the procedures below.
For all SIP transactions identified:
  • if priority is supported, as containing an authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;
the I-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the I-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
If the I-CSCF receives the P-Profile-Key header field in a SIP request or response the I-CSCF shall discard the P-Profile-Key header field.
When the I-CSCF receives an initial request for a dialog or standalone transaction the I-CSCF will start the user location query procedure to the HSS as specified in TS 29.228 for the calling user, indicated in either:
  1. the P-Served-User header field, if included in the request; or
  2. the P-Asserted-Identity header field, if the P-Served-User header field is not included in the request.
Prior to performing the user location query procedure to the HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228.
When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, the I-CSCF shall apply the procedures described in RFC 4028 clause 8.
When the response for user location query contains information about the required S-CSCF capabilities, the I-CSCF shall select a S-CSCF according to the method described in TS 29.228.
If the user location query was successful, the I-CSCF shall:
1)
insert the URI of an AS hosting the PSI, or the URI of the S-CSCF - either received from the HSS, or selected by the I-CSCF based on capabilities - as the topmost Route header field appending the "orig" parameter to the URI of the S-CSCF;
2)
store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. If no P-Charging-Vector header field was found, then insert the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260;
2A)
based on local policy, add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;
3)
optionally, include the received Redirect-Host AVP value in the P-User-Database header field as defined in RFC 4457;
4)
if a wildcarded identity value is received from the HSS in the Wildcarded-Identity AVP and the I-CSCF supports the SIP P-Profile-Key private header extension, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002; and
5)
forward the request based on the topmost Route header field.
Upon an unsuccessful user location query, the I-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) response or 604 (Does not exist anywhere) response in the case the user is not a user of the home network.
When the I-CSCF receives any response to the above request, and forwards it to AS, the I-CSCF shall:
  • store the values from the P-Charging-Function-Addresses header field, if present. If the next hop is outside of the current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header field prior to forwarding the message; and
  • insert a P-Charging-Vector header field containing the type 3 "orig-ioi" header field parameter, if received in the request, and a type 3 "term-ioi" header field parameter in the response. The I-CSCF shall set the type 3 "term-ioi" header field parameter to a value that identifies the sending network of the response and the type 3 "orig-ioi" header field parameter is set to the previously received value of type 3 "orig-ioi" header field parameter.
Up

5.3.2.2  Abnormal casesWord‑p. 226
In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 404 (Not Found) response to the UE.
Upon successful user location query, when the response contains the URI of the assigned S-CSCF, if the I CSCF is unable to contact the assigned S-CSCF, as determined by one of the following:
  • the S-CSCF does not respond to the service request and its retransmissions by the I-CSCF; or
  • by unspecified means available to the I-CSCF;
and:
  • the I-CSCF supports S-CSCF restoration procedures;
then:
  • the I-CSCF shall explicitly request the list of capabilities from the HSS and, on receiving these capabilities, the I-CSCF shall select a new S-CSCF, based on the capabilities indicated from the HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same terminating procedure. Re-selection shall be performed until SIP transaction timer expires as specified in RFC 3261.
Upon successful user location query, when the response contains information about the required S-CSCF capabilities, if the I-CSCF is unable to contact a selected S-CSCF, as determined by one of the following:
  • the S-CSCF does not respond to the service request and its retransmissions by the I-CSCF; or
  • by unspecified means available to the I-CSCF;
then:
  • the I-CSCF shall select a new S-CSCF, based on the capabilities indicated from the HSS. The newly selected S CSCF shall not be one of any S-CSCFs selected previously during this same terminating procedure. Re-selection shall be performed until SIP transaction timer expires as specified in RFC 3261.
If the I-CSCF receives a negative response to the user location query, the I-CSCF shall send back a 404 (Not Found) response.
If the I-CSCF receives a CANCEL request and if the I-CSCF finds an internal state indicating a pending Cx transaction with the HSS, the I-CSCF:
  • shall answer the CANCEL request with a 200 (OK) response; and
  • shall answer the original request with a 487 (Request Terminated) response.
With the exception of 305 (Use Proxy) response, the I-CSCF may recurse on a 3xx response only when the domain part of the URI contained in the 3xx response is in the same domain as the I-CSCF. For the same cases, if the URI is an IP address, the I-CSCF shall only recurse if the IP address is known locally to be a address that represents the same domain as the I-CSCF.
Up

5.3.3Void

5.3.4Void

5.3.5  Subsequent requests |R13|Word‑p. 227
When the I-CSCF receives a subsequent request, the I-CSCF shall verify whether it has arrived from an entity within the trust domain or not. If the request has not arrived from an entity within the trust domain, then the I-CSCF shall remove all P-Charging-Vector header fields, if present.
If no P-Charging-Vector header field was found in the received subsequent request, then insert the P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog.
When the I-CSCF receives any response to the subsequent request, the I-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.
When the I-CSCF receives a subsequent request directly forwarded to the AS hosting the PSI, the I-CSCF shall insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameter, if the received request including a P-Charging-Vector header field. The I-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The I-CSCF shall not include the type 3 "term-ioi" header field parameter.
When the I-CSCF receives any response to the subsequent request from the AS hosting the PSI, if the received response containing a "term-ioi" header field parameter in the P-Charging-Vector header field, the I-CSCF shall:
  1. remove all received "orig-ioi" and "term-ioi" header field parameters from the forwarded response;
  2. insert the stored "orig-ioi" header field parameter if received in the request; and
  3. insert a type 2 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response.
Up


Up   Top   ToC