Thanks, Richard.
I just extracted the ServiceRoute header from the response of Register and
use it as Route of Invite.

Another question:
My Application has two roles: Originating and Terminating, I set up the
same service triggers(Originating, Term_Registered) for UeA and UeB;
The expected path will be UeA -> CSCF -> OriginAS -> CSCF -> TermAS ->UeB,
but now the path is UeA -> CSCF -> OriginAS -> CSCF -> TermAS -> CSCF ->
TermAS ...
Because the request from TermAS is always matched with iFC service trigger
as it is always Term( Term_Registered or Term_Unregistered).
I have to  removed the service trigger(Term_Registered) for UeB to make it
work.

What's the right solution?



On Mon, Feb 19, 2018 at 4:31 PM, Richard Whitehouse (projectclearwater.org)
<richard.whiteho...@projectclearwater.org> wrote:

> Anthony,
>
>
>
> 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 5.4.3.1, 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.
>
>
>
> Richard
>
>
>
> *From:* Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org]
> *On Behalf Of *Anthony Lee
> *Sent:* 19 February 2018 15:36
> *To:* clearwater@lists.projectclearwater.org
> *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 <anthonyn...@gmail.com>
> 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
Clearwater@lists.projectclearwater.org
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

Reply via email to