| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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 |