Hi Richard,
My application server is doing RCS Message Store and Forward, it have two
roles: Originating and Terminating.
When it act as terminating role(let's called it TPF) it provides
Store-and-Forward: it accepts the Invite request from the network
and act as below:
1. if the user is in registered state,
sends 200OK response to the network, sends a new Invite request to
the user;
2. if the user is not in registered state,
sends 200OK response to the network.
After the Sip session is established TPF store the MSRP messages it
received when the receiver is in unregistered state and
will send the message(s) to the receiver once he registers.
Now when I tested my application server with Clearwater the 200OK from TPF
let Clearwater believes that the transaction is finished and
Clearwater invalidats OID for the service chain and this makes my
application server can't execute the rest service after it sends 200OK back
to Clearwater's scscf.
In the TS spec I don't find any suggestion that this behavior should be
supported or should not be supported.
My understanding is that while the 200OK response does mean the SIP
transaction is done but it doesn't mean the service chain is done.
About when or what should trigger the invalidation of OID, maybe invalidate
OID once there is no more iFC is matched with the request for the
terminating session case?
Currently I'm using a walk around to make Clearwater continue to check the
rest iFCs:
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>52</Group>
<SIPHeader>
<Header>P-Served-User</Header>
<Content>.+\;sescase=orig\;.+</Content>
</SIPHeader>
</SPT>
The first time the request hits the terminating side the P-Served-User is
there, the second time this header is not there so this works.
But I'm hoping to have better solution for this issue.
Thanks
Anthony
On Wed, Feb 28, 2018 at 5:24 PM, Richard Whitehouse (projectclearwater.org)
<richard.whiteho...@projectclearwater.org> wrote:
> Anthony,
>
>
>
> Can you explain more about what your application server is doing, and why
> it’s responding on the ISC interface in this fashion?
>
>
>
> Can you point to anything in the TS specs which suggests that it’s
> supported for an AS to behave in this fashion?
>
>
>
> From Clearwater’s perspective, we need to invalidate the Original Dialog
> Identifier information at some point, and once we’ve received a 200 OK on
> the transaction, we don’t expect to hear anything more the Application
> Server as the 200 OK represents a final response for that SIP transaction.
>
>
>
> If the Application Server is allowed to send a SIP INVITE with a
> correlating ODI token to Clearwater at any point after we’ve sent it the
> request, we may need to keep that state around for an arbitrarily long
> period of time, which isn’t tenable.
>
>
>
>
>
> Richard
>
>
>
> *From:* Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org]
> *On Behalf Of *Anthony Lee
> *Sent:* 24 February 2018 01:53
> *To:* clearwater@lists.projectclearwater.org
> *Subject:* Re: [Project Clearwater] Is it a bug that Clearwater
> invalidate the ODI once it receives 200OK response?
>
>
>
> From TS 124.229 V12.6.0, the spec doesn't say anything about the 200OK
> response from the request.
>
> It only talks about the subsequent request should be co-related with the
> previous request by using ODI in route header.
>
> To me it looks like a bug.
>
>
>
> On Fri, Feb 23, 2018 at 2:21 PM, Anthony Lee <anthonyn...@gmail.com>
> wrote:
>
> In my case, there is a application service in terminating side doing
> message Store-And-Forward.
>
> So when the service receives an Invite it replies 200OK response
> immiediately and then it create a new Invite to the user.
>
>
>
> Since scscf invalidated the AS chain when it receives 200OK response the
> Invite request is matched with iFC again from the beginning instead just
> match with the rest iFCs. So it fail to send to the user.
>
>
>
> Is it a bug?
>
>
>
>
>
> Anthony
>
>
>
_______________________________________________
Clearwater mailing list
Clearwater@lists.projectclearwater.org
http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
