Request-URI Clause Samples
Request-URI. The Request-URI in the SIP INVITE returned/ propagated back from the Application Server will contain the destination party address. The Application Server may, as part of the service it is providing, have modified this destination party address. If the propagated INVITE contains a different destination address than the INVITE sent to the Application Server, and the Application Server was invoked for terminating services then. ⮚ If the propagated INVITE is received by the SB/SCIM it will not engage any further applications for the original terminating user and will immediately propagate the INVITE with the new destination party address back to the S-CSC. ⮚ If the propagated INVITE is received by the S-CSC then it will not engage any further applications for the original terminating user. o If the new destination address is registered on the S-CSC then it will check the service profile to determine if any terminating services need to be invoked for the subscriber identified by new destination address. o If the new destination address is not registered on the S-CSC then it performs originating side session routing and forwards the INVITE on to the S-CSC handling the registration of the subscriber identified in the new destination address, or in the case of the subscriber not being registered an appropriate S-CSC.
Request-URI. The Request-URI of the INVITE sent to the Media Resource Broker indicates the media resources being requested. The MRB MUST support the annc, conf and dialog resources defined in RFC4240. For conf allocations then all concurrently active sessions with the same conference id value will be allocated to the same physical media server. It is the responsibility of the sending client to ensure all requests sharing the same conference-id are directed to the same Media Resource Broker instance. The following additional parameters MAY be included in the Request-URI to further influence the action of the Media Resource Broker. This parameter is used in conjunction with the conf= Request-URI (from RFC4240) in order to instruct the Media Resource Broker the ultimate size of the conference being requested so an appropriate number of ports can be reserved. This parameter is not propagated to the Media Server itself. This parameter can be used to indicate to the Media Resource Broker that multiple requests should be allocated to the same physical Media Server. All concurrently active sessions that share the same unique id should be resolved to the same physical Media Server. This parameter is redundant for conf allocations and is not propagated to the Media Server itself. It is the responsibility of the client issuing the request to ensure both the uniqueness of the <unique id> and to ensure that all requests using the same <unique id> are directed to the same Media Resource Broker instance. This parameter can be used to indicate a request for a specific media server (identified by the <media server id>). How Media Servers are identified through the Media Server Id is left to individual implementations. The parameter is not propagated to the Media Server itself. This parameter allows the definition of custom media capabilities. When custom capabilities are used then the Media Resource Broker must be configured with the capabilities supported by each Media Server under its allocation control. The request will be resolved to a Media Server supporting all the requested custom capabilities, if not all the capabilities can be supported then the request is rejected. The parameter is not propagated to the Media Server itself.
Request-URI. The Request-URI is set to the resource that the Application Server is subscribing to, i.e. the public user identity of the user that was received in the To header of the secondary REGISTER.
Request-URI. The Request-URI of the REGISTER MUST contain the SIP URI of the AS or SB / SCIM (the S-CSC obtains this from the iFC of the subscribers service profile).