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 18.104.22.168, 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:* email@example.com > *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