Hi Janek, So far as we can see, there’s no definitive statement in the specs on ODI lifetimes.
Looking in the latest version of TS 24.229 (section 5.7.5, describing app servers implementing third-party call control) there’s the following: The AS performing 3rd party call control acts as a B2BUA. There are two kinds of 3rd party call control: - Routeing B2BUA: an AS receives a request, terminates it and generates a new request, which is based on the received request. - Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS, or an AS receives a request and initiates a new request that is logically connected but unrelated to the incoming request from the originating user (e.g. the P-Asserted-Identity of the incoming request is changed by the AS). AS can initiate additional requests and associate them with a related incoming request. When the AS acting as an initiating B2BUA receives a request and initiates a new request that is logically connected but unrelated to the incoming request from the originating user, the AS can include an original dialog identifier in the Route header field for the S-CSCF that it learned from the incoming request, per service logic needs. In your case, the initial request (but not the dialog) has been terminated, as it has received a final response (the 200 OK) - so the AS is acting as a Routeing B2BUA. Only an AS acting as an initiating B2BUA should include an ODI in a new request, so I wouldn’t expect there to be an ODI in a new request from your AS. That said, given that there’s nothing that says we should be rejecting a request with an ODI token that doesn’t correlate, we’re going to change Sprout so that it allows these requests, and processes them as if they didn’t contain ODI tokens (tracked at: https://github.com/Metaswitch/sprout/issues/536) Ellie From: Jasio Kololski [mailto:[email protected]] Sent: 07 May 2014 08:57 To: Eleanor Merry Cc: [email protected] Subject: Re: [Clearwater] Sprout refusing to route the redirected call after answer Hi Ellie, I don't think the actual call is ended at the time when INVITE has been 200OKed and ACKed. I think it should last for the time of the entire call - until BYE. Do you have any recommendation that supports this behavior of sprout? The reason for SCSCF to accept "old" ODI is that for the user this is still the same call, it just has been answered by the AS and then continued as if the call has been forwarded. Another way of doing this would be OOTB request which is not widely supported. Regards, Janek On Tue, May 6, 2014 at 7:58 PM, Eleanor Merry <[email protected]<mailto:[email protected]>> wrote: Hi Janek, The ODI token (encoded in the Route header, e.g. Route:<sip:odi_5oc20yv/[email protected]:5054;lr>) is invalidated once the original INVITE completes - so Sprout intentionally rejects INVITEs with an ODI that it can't correlate to an AS chain. Are you expecting/needing the S-CSCF to accept the INVITE with an old ODI (and if so, why)? If not, are you able to remove the ODI on a forwarded INVITE if you have already sent a final response to that INVITE? Ellie -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Jasio Kololski Sent: 05 May 2014 12:47 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] Sprout refusing to route the redirected call after answer Hello Community, I have found following interesting behaviour of sprout: Suppose I have a PSI sitting somewhere on AS that answers the call (e.g. IVR) and after some time it forwards the call. Redirected INVITE is being rejected by sprout as it claims that odi is not found. Please see log snippet below. Regards, Janek 05-05-2014 11:20:31.784 Debug pjsip: sip_endpoint.c Processing incoming message: Request msg INVITE/cseq=638488486 (rdata0x17338a8) 05-05-2014 11:20:31.784 Verbose stack.cpp:226: RX 1504 bytes Request msg INVITE/cseq=638488486 (rdata0x17338a8) from UDP 10.193.153.20:33837<http://10.193.153.20:33837>: --start msg-- INVITE sip:[email protected]<mailto:sip%[email protected]>;user=phone SIP/2.0 Via:SIP/2.0/UDP 10.193.153.20;branch=z9hG4bKjdfriascfuw.-11o46re-10.193.153.115V5054-0-638488486-944020771-1399288831818- From:"296 user"<sip:[email protected]<mailto:sip%3a%[email protected]> ;user=phone>;tag=944020771-1399288831818- To:<sip:[email protected]<mailto:sip%[email protected]>;user=phone> Call-ID:[email protected]<mailto:Call-ID%[email protected]> CSeq:638488486 INVITE Contact:<sip:10.193.153.20:5060<http://10.193.153.20:5060>> P-Asserted-Identity:"296 user"<sip:[email protected]<mailto:sip%3a%[email protected]>>,"296 user"<tel:+12201234296> Privacy:none Diversion:"CW IVR"<sip:[email protected]<mailto:sip%3a%[email protected]>;user=phone>;user-id=" [email protected]<mailto:[email protected]> ";privacy=off;answered-count=1;reason=deflection;answered;counter=1 Route:<sip:odi_5oc20yv/[email protected]:5054;lr> P-Charging-Vector:icid-value="Zjk4YmRkMzZiOGExNGNjODI5YWE0OTlmNzc5ZjBjNDA.";icid-generated-at=10.193.153.116 P-Charging-Function-Addresses:ccf=cdf.domain.com<http://cdf.domain.com> Supported:100rel Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE Accept:application/media_control+xml,application/sdp,multipart/mixed Max-Forwards:10 Content-Type:application/sdp Content-Length:250 v=0 o=jdfriascfuw 52 2 IN IP4 10.193.3.173 s=- c=IN IP4 10.193.3.173 t=0 0 m=audio 34654 RTP/AVP 3 110 8 0 98 101 a=rtpmap:110 speex/8000 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv --end msg-- 05-05-2014 11:20:31.784 Debug stack.cpp:411: Queuing cloned received message 0x7fb3983d22b8 for worker threads 05-05-2014 11:20:31.784 Debug stack.cpp:189: Worker thread dequeue message 0x7fb3983d22b8 05-05-2014 11:20:31.784 Debug pjsip: sip_endpoint.c Distributing rdata to modules: Request msg INVITE/cseq=638488486 (rdata0x7fb3983d22b8) 05-05-2014 11:20:31.784 Debug stateful_proxy.cpp:246: Proxy RX request 05-05-2014 11:20:31.784 Error stateful_proxy.cpp:462: Original dialog lookup for odi_5oc20yv/dn not found 05-05-2014 11:20:31.784 Debug pjsip: tdta0x7fb3c02f Destroying txdata Request msg INVITE/cseq=638488486 (tdta0x7fb3c02fc8a0) 05-05-2014 11:20:31.784 Debug acr.cpp:48: Created ACR (0x7fb3c015f6f0) 05-05-2014 11:20:31.784 Error stateful_proxy.cpp:710: Reject INVITE request with 400 status code 05-05-2014 11:20:31.784 Debug pjsip: endpoint Response msg 400/INVITE/cseq=638488486 (tdta0x7fb3c02fc8a0) created 05-05-2014 11:20:31.784 Info pjutils.cpp:1376: Cloning header! 140409328241960 05-05-2014 11:20:31.784 Info pjutils.cpp:1376: Cloning header! 140409328242200 05-05-2014 11:20:31.785 Debug pjsip: sip_resolve.c Target ' 10.193.153.20:5060<http://10.193.153.20:5060>' type=UDP resolved to '10.193.153.20:5060<http://10.193.153.20:5060>' type=UDP (UDP transport) 05-05-2014 11:20:31.785 Verbose stack.cpp:242: TX 694 bytes Response msg 400/INVITE/cseq=638488486 (tdta0x7fb3c02fc8a0) to UDP 10.193.153.20:5060<http://10.193.153.20:5060>: --start msg-- SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 10.193.153.20;received=10.193.153.20;branch=z9hG4bKjdfriascfuw.-11o46re-10.193.153.115V5054-0-638488486-944020771-1399288831818- Call-ID: [email protected]<mailto:[email protected]> From: "296 user" <sip:[email protected]<mailto:sip%3a%[email protected]> ;user=phone>;tag=944020771-1399288831818- To: <sip:[email protected]<mailto:sip%[email protected]> ;user=phone>;tag=z9hG4bKjdfriascfuw.-11o46re-10.193.153.115V5054-0-638488486-944020771-1399288831818- CSeq: 638488486 INVITE P-Charging-Vector: icid-value="Zjk4YmRkMzZiOGExNGNjODI5YWE0OTlmNzc5ZjBjNDA.";icid-generated-at=10.193.153.116 P-Charging-Function-Addresses: ccf=cdf.domain.com<http://cdf.domain.com> Content-Length: 0 --end msg-- _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
