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