The domain name
in the REQUEST-URI must be resolved to determine the IP address of the I-CSCF
providing access into the destination network. The I-CSCF must then determine how
to route the INVITE to the proper S-CSCF.
However, the REQUEST-URI does not necessarily provide the identity of the subscriber??™s
public user identity (depending on the method of routing used). The P-CSCF
relies on the P-PREFERRED-IDENTITY header to identify the public user identity to
be used for the session request. If there is no header, the P-CSCF then uses the first
ROUTE header, which should be populated with the default public user identity for
the session.
The P-CSCF must then validate the request by comparing the RECORD-ROUTE
headers with the route list that the P-CSCF created when the subscriber registered
with the network. Each individual entry is examined individually to determine if the
address listed in the message is part of a legitimate route. If the two do not match, it
is possible that the message is coming from another source other than the subscriber,
and the request is therefore rejected. The P-CSCF will send a 400 Bad Request response
to the originator.
This is yet another security feature provided by the P-CSCF. The P-CSCF can route
the message based on the route headers stored from the registration, which would
result in the message being routed to the proper subscriber, but ultimately being rejected
by the subscriber device because the message did not come from the device (it
is fraudulent).
Pages:
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274