No, it’s not the originating dialog identifier, or at least not solely the ODI 
token. This can’t be used, as the ODI is only added by the S-CSCF when the call 
is sent to an application server.

TS 24.229 is the correct spec to use here – see section, and it 
identifies three different ways the S-CSCF should do this.

-          The S-CSCF can use information included on the Service-Route which 
was sent in response to the REGISTER, e.g. a specific user part, parameter or 
port to identifying an originating request, and compare it to the topmost Route 
header, or the port it was received upon

-          The S-CSCF can look at whether the request contains the “orig” 
parameter in the topmost Route header.

-          If neither of these match, the S-CSCF should assume it’s terminating.

For Clearwater, the Service-Route header that Clearwater responds to messages 
contains an “orig” parameter. As such Clearwater essentially uses whether the 
request contains the orig parameter.


From: Clearwater [] On 
Behalf Of Anthony Lee
Sent: 19 February 2018 15:36
Subject: Re: [Project Clearwater] How does Clearwater decide if the session 
case is originating or terminating?

Please forget my testcase, it turns out that I put SessionCase as 1 in SPT for 
term_registered while it should be 2.

But it would be great if someone could answer the question in the title.

From the 3gpp technical spec I read it seems like its is the original dialog 
identifier that s-cscf  placed that let the s-cscf determined what's the 
session case.
Am I right?

On Sun, Feb 18, 2018 at 11:08 PM, Anthony Lee 
<<>> wrote:
I have a test that sends a request from user a to user b, a and b both have a 
iFC that point to a application server, for different session case a different 
server parameter is used.
Now from the sprout log I see that for the request sent from a it ask for b's 
profile and the session case is term ,why?

Should it be originating for a, and then when application server send it back 
to scscf, then apply for b terminating?

Clearwater mailing list

Reply via email to