| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
If the UA's register with your proxy and are only reachable
via their AOR - then using Record-Routing on the proxy is the way to go.
You may want to take a look at repro - it is a proxy built
ontop of resiprocate. Repro already supports record routing - you could
just extend repro to add your monitoring code.
Scott From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Steven Coule Sent: Monday, March 13, 2006 12:32 PM To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx Subject: [reSIProcate] Routing of signalling via proxy - opinions? I am developing a SIP proxy to
monitor SIP call signalling using reciprocate and need to force all call
signalling traffic via my proxy to maintain an accurate call state
model. For outbound calls from a UA, the UA
can be pointed towards the proxy, so that is straightforward. For inbound calls
to any UA that I need to monitor using my proxy, there needs to be some method
for forcing call signalling to my proxy rather than directly to the UA. For
example, my proxy could sit logically between an Asterisk PBX and a UA for that
PBX, or between a E1->SIP gateway and an array of
UA’s. As far as I understand, there are a
couple of approaches I can use to achieve this .. 1)
Use the maddr= parameter. By forcing
the UA to register with my proxy, I can manipulate the REGISTER by adding the
maddr= parameter before forwarding the REGISTER to the real registrar. In theory
at least, this should force the inbound calls to be routed via my proxy by the
Asterisk / SIP server. 2)
Using the RFC3581 mechanism for NAT
traversal appears to provide a method of forcing a call signalling path via a
specific proxy using the Record-Route and rport= parameter.
Have I missed anything? Which method
is preferred?
Steve |