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

[Robert Sparks]

And this is a problem - this is neither a loop nor a merge - it is  
two real requests the TU should handle.
The redirection is a red-herring from a black-box functionality point  
of view (if there are artifacts from having
sent the redirection to the first request causing the loop we can fix  
the code so there's not). But this should
be handled no differently at the TU level than having the an invite  
forked by a previous proxy to A and B
both of which land at me. If A arrives first and I reject it (with  
any error response - think 404 instead of 3xx
for a moment), then B shows up, my TU needs to handle B as an  
independent request, not treat it as a merge.

(To be complete in the description - if a proxy P1 forked to P2 and  
P3, and each of those forwarded the request
to A at my TU, then the second one arriving I should reject with a  
482 - that's the actual merge case).

RjS

On Nov 9, 2006, at 8:55 AM, Scott Godin wrote:

> The scenario you describe with the PSTN gateway boils down to the  
> same merge request detection issue.  The problem is possible either  
> with forking or with recursive redirecting proxies.
>
>
>
> I’ll try to reword Steven’s original description – but I’ll use a  
> PSTN gateway instead of a B2BUA for simplicity.
>
> Steps:
>
> 1.        Call comes in from PSTN to gateway.
>
> 2.       Gateway passes the call to a recursive redirecting proxy.
>
> 3.       Proxy recursively redirects to another endpoint on the  
> same gateway.
>
> 4.       The gateway receives a copy of the invite it sent out, but  
> this time with a different request uri and a loop is detected.
>
>
>
> Scott
>
>
>
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: Thursday, November 09, 2006 11:49 AM
> To: Scott Godin
> Cc: Steven Coule; resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] Call routed back to reSIProcate by SipX  
> PBX after 302temp moved .
>
>
>
> Scott -
>
>
>
> Could you re-sketch the problem for me (an example of the RURI and  
> VIas of both of the arriving requests would help).
>
>
>
> I'm pretty sure you always want the RURI as part of that check (if  
> someone is running a pstn gateway using resip and a message
>
> forks to two different PSTN numbers through that gateway, the  
> second one mustn't get 482ed) , but before we dive into it, lets get
>
> a concrete example to work against.
>
>
>
> RjS
>
>
>
> On Nov 9, 2006, at 5:54 AM, Scott Godin wrote:
>
>
>
>
> 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
>
>
>
>

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