Hi Ellie Thank for the reply.
In my setup, the IFC will forward all the INVITE to the AS, so when the 2nd INVITE (after redirection) is arrived to SPROUT, it will be forwarded as expected. Is there anything I can set in SPROUT to distinguish the 2nd INVITE is a redirection INBVITE, or should I make the AS to detect the different between 1st INVITE and 2nd INVITE? - paul ________________________________________ From: Eleanor Merry [[email protected]] Sent: Saturday, June 14, 2014 1:57 AM To: Paul Sun Cc: [email protected] Subject: RE: 302 Response - S-CSCF on handling SIP redirection Hi Paul, Looking at RFC3261, 21.3.3 suggests that the To header shouldn't be rewritten on a 302: 21.3.3 302 Moved Temporarily The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. If the URI cached from the Contact header field fails, the Request- URI from the redirected request MAY be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available. Hope this helps, Ellie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Sun Sent: 12 June 2014 01:50 To: [email protected] Subject: [Clearwater] 302 Response - S-CSCF on handling SIP redirection Hi I would like to seek help on SIP INVITE redirection. In my setup, I use Clearwater as S-CSCF and OpenIMS HSS as HSS, I have configured mobicents as AS. In my testing scenarios, when the INVITE arrived S-CSCF, it redirects to AS, and the AS will check the TO and FROM, if it is not qualified in some conditions, AS response 302 with a new Contact URI. S-CSCF forward this response back to the UE (Zoiper), and UE also generate a new INVITE where the Request URI is filled with what is provided from Contact URI on 302 Response. But I found that the TO field is still pointing to the old called ID. Is it correct? Or there is a problem on the 302 Response? Please help - PS _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
