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:[email protected]] On Behalf Of Anthony Lee Sent: 24 February 2018 01:53 To: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
