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

Thu Nov 9 11:35:12 CST 2006

I went back through 3261 and agree that it doesn't say to include  
RURI. I have memories of filing this as a bug (and having this  
conversation
on the SIP list several years ago), but I don't find it in the bug  
tracker now. I'll take it back through the SIP list again. But yeah -  
we should be
including the RURI.

RjS

On Nov 9, 2006, at 9:18 AM, Scott Godin wrote:

> It seems that including the RequestUri in the merged request  
> detection would fix all of these and maintain “actual” merge  
> detection.  Is there any reason not to include this (other than  
> it’s not what 3261 says to do)?
>
>
>
> Scott
>
>
>
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: Thursday, November 09, 2006 12:12 PM
> 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 .
>
>
>
> 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/01d5afc4/attachment.htm>