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@xxxxxxxxxxx]
Sent: Friday, November 10, 2006 11:19 AM
To: Scott Godin
Cc: Steven Coule; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx]
Sent: Thursday, November 09, 2006 12:35 PM
To: Scott Godin
Cc: Steven Coule; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx]
Sent: Thursday, November 09, 2006 12:12 PM
To: Scott Godin
Cc: Steven Coule; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxx]
Sent: Thursday, November 09, 2006 11:49 AM
To: Scott Godin
Cc: Steven Coule; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
Behalf Of Steven Coule
Sent: Wednesday, November 08, 2006 9:22 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel