I need to correct my last email: The expected path should be: UeA->pCscf->sCscf->originAs->sCscf->termAs->pCscf->UeB.
Now as the invite forwarded by sCscf always contains route header which points back to sCscf so the termAs keep send it back to it and becomes a loop. I guess termAs need to send invite to configured iCscf which would know which pCscf to use. Am I right? Am I right On Feb 19, 2018 17:59, "Anthony Lee" <anthonyn...@gmail.com> wrote: > 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 126.96.36.199, 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:* firstname.lastname@example.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