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

[Robert Sparks]

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 at list.sipfoundry.org  
>> [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf  
>> Of Steven Coule
>> Sent: Wednesday, November 08, 2006 9:22 AM
>> To: resiprocate-devel at list.sipfoundry.org
>> 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 at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061109/7b878a1f/attachment.htm>