Hi all Do you know how I can configure the OpenIMS FoHSS to identify the 1st INVITE and 2nd IN VITE based on the domain name in the Request-URI?
Can I use sip:*@example1.com? - PS -----Original Message----- From: Eleanor Merry [mailto:[email protected]] Sent: Wednesday, June 18, 2014 5:57 PM To: Paul Sun Cc: [email protected] Subject: RE: 302 Response - S-CSCF on handling SIP redirection Hi Paul, I recommend you add this function in your AS. If your IFCs are set to forward all INVITEs to the AS then Sprout can't distinguish between the two INVITEs. If there are sufficient differences between the 1st and 2nd INVITEs then you potentially change your IFCs so that it only sends the first INVITE to the AS - whether this is possible will depend on the INVITEs though. Ellie -----Original Message----- From: Paul Sun [mailto:[email protected]] Sent: 13 June 2014 21:00 To: Eleanor Merry Cc: [email protected] Subject: RE: 302 Response - S-CSCF on handling SIP redirection 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
