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
Pushpendra,
I assume you are following the instructions on Read the Docs and have
configured the APT software source as shown under
http://clearwater.readthedocs.io/en/stable/Manual_Install.html#configure-the-apt-software-sources
?
Can you double check that you’ve added “deb
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
