reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Call routed back to reSIProcate by SipX PBX after 302temp moved .

No, this is a fundamental use case for any endpoint TU (see the gateway example I sent earlier).

RjS

On Nov 9, 2006, at 6:30 AM, Byron Campen wrote:

Yuck... now this is interesting. This fundamental problem rears its head whenever a UA redirects, and there is a proxy that will recursively redirect. We have just seen what happens in the B2BUA case, but if an endpoint does this, it is very possible that the request will land on that UA again, even if no B2BUAs are involved. Maybe recursive redirection at a proxy is not such a hot idea after all...

Best regards,
Byron Campen

Hmm – that is an interesting problem.  Resip/dum is behaving to spec – UA’s are supposed to do merge request detection in this way.  But this detection causes problems for B2BUA’s in the scenario you described.  Maybe we should have an option for B2BUA’s that allows including the request URI in merge request detection.

 

I’d be interested to hear from others on what they think/know is correct solution to this is.

 

BTW:  You mentioned that if you include the request uri in the merge request matching, then you still get a loop detected – I don’t quite understand why that is happening.

 

Scott

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Steven Coule
Sent: Wednesday, November 08, 2006 9:22 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Call routed back to reSIProcate by SipX PBX after 302temp moved .

 

We have a problem with reSIProcate when operating as a B2BUA between UACs and a proxy IP PBX such as SipX.

 

The scenario is:

 

The standard INVITE call flow is from  (1) UAC1 -> (2) B2BUA -> (3) SipX -> (4) B2BUA -> (5) UAC2

 

Our B2BUA is registrar for UAC1 and UAC2, and the B2BUA also registers to SipX with the ids of UAC1 and UAC2. SipX therefore believes both UAC1 and UAC2 are at the B2BUA … There is only one B2BUA, (2) and (4) represent flows through the B2BUA.

 

This works ok for a normal call. However if at step 4, the INVITE from SIPX to B2BUA is rejected with a 302 to redirect the call to UAC3 (also registered through our B2BUA) , SipX then sends another INVITE to the B2BUA with an updated URI for UAC3 but with the To & From headers unchanged.

 

reSIProcate then returns an error 482 request merged to SipX  … there was some commented out code in MergedRequestKey which appeared to check for a change in the request URI but adding this check again did not resolve the issue, 482 was still returned.

 

We are wondering whether the problem is caused because we haven’t cancelled stage (5) before returning the 302 to SipX …

 

Any ideas as to why this happens?  I have an ethereal trace available if that helps!

 

Steve Coule

 

Envox Worldwide

 

Envox Worldwide – A Global Leader in Voice Solutions

www.envox.com

 

 

_______________________________________________
resiprocate-devel mailing list

_______________________________________________
resiprocate-devel mailing list