[reSIProcate] Call routed back to reSIProcate by SipX PBX after 302temp moved .
Robert Sparks
rjsparks at nostrum.com
Fri Nov 10 11:05:49 CST 2006
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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061110/c1ac5c9f/attachment.htm>
More information about the resiprocate-devel
mailing list