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

Fri Nov 10 11:13:03 CST 2006

One approach is to require that a value for this option be provided on
creation of the MasterProfile. I agree with Robert's suggested default
value here.

On 11/10/06, Robert Sparks <rjsparks at nostrum.com> wrote:
> Well, what I said below was to default to include, but after walking across
> the harbor (the hotel buildings here at IETF are really spread out),
> I convinced myself that _most_ of the users of DUM are likely to assume that
> it wouldn't be, so I'll change my position. Default to not including it
> and put red-flashing lights in the doxygen that will catch the eye of
> someone trying to build automaton/gateways to put it back in. Let me know
> where that is when you're done and I'll go back in and add a little prose to
> the comment :)
>
> RjS
>
>
> On Nov 10, 2006, at 8:23 AM, Scott Godin wrote:
>
>
>
> Just to be clear you think the default should be to include or exclude the
> Request Uri in the merge detection?
>
>
>
>
>
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: Friday, November 10, 2006 11:19 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 .
>
>
>
> I could accept such an option, but it would need to be off by default and
> heavily documented.
>
>
>
>
>
> The only way this should happen is if the phone _asked_ for two different
> URIs at some point
>
>
> (by registration or configuration of a peer). It's an acceptable application
> layer policy to treat
>
>
> those as the same, and the flag you're talking about is exactly stating that
> policy decision.
>
>
>
>
>
> RjS
>
>
>
>
>
> On Nov 10, 2006, at 6:14 AM, Scott Godin wrote:
>
>
>
>
>
> I found some older discussions on this same subject:
>
> http://www1.ietf.org/mail-archive/web/sip/current/msg10443.html
>
> http://www.atm.tut.fi/list-archive/sip/msg06721.html
>
>
>
> It seems to me that a single UA phone device would want the merge detection
> as specified in 3261 – ie. why ring for the same call on 2 different lines?
> But UA's that handle multiple identities or route calls differently based on
> request-uri (ie. B2BUA's, MediaServers, Gateways, etc) would want to include
> the request uri in the merge detection.  I can make this an option in the
> DUM master profile, if we agree this is a good idea.
>
>
>
> Scott
>
>
>
>
>
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: Thursday, November 09, 2006 12:35 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 .
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>