| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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] 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] 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] 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 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 _______________________________________________ resiprocate-devel mailing list
|