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 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