| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Using a prototype with the Radvision
stack, the Asterisk was ignoring the maddr parameter which should (in my belief
of the theory at least) cause calls from the Asterisk to be routed via my
Proxy. It didn’t work, and the maddr parameter seemed to be deliberately
ignored in the code – it could be patched, but I’m looking for the
most compatible solution of inserting my monitoring/call control solution into a
SIP environment. I’m not sure if we can configure an
outbound proxy for SIP phones registered to the Asterisk – I didn’t
think this was the case but will take another look. The Route header is worth a try. I noted
in 3261 that the Record-Route header is to be deliberately ignored if present
in a REGISTER, but that doesn’t apply to a Route header. I guess
the key here is whether the Asterisk (or other) server will store the Route
present in the REGISTER request and use it to route calls to the UA’s via
my Proxy. You mention using a Route header embedded
in the URI … from reading the specs, it looks like this could work. The
Path Extension RFC 3327 header also seems like another option to look into –
from reading the spec it perhaps looks most likely to work. I’ll take a look at repro and Asterisk
to see whether the Path is supported … Thanks for your help ..
From:
Scott Godin [mailto:slgodin@xxxxxxxxxxxx] Record-route will only help for messages
that go through your proxy - if the INVITE is not even hitting your proxy, then
you will need some other mechanism to tell Asterick to send all requests
through you. I don't know asterick at all but maybe you can configure
your proxy as an outbound proxy on asterick? So that it will route
all requests through you first. Or...I'm not 100% sure if this is possible
or not - but you could try adding an embedded Route header to the Contact Uri
of Registrations that pass through you. Scott From:
Steven Coule [mailto:Steven.Coule@xxxxxxxxx] I wasn’t intending my proxy to be
the registrar, merely to route the REGISTER requests to the registrar in
addition to the normal proxying behaviour of the call signalling. As an example scenario, I want to sit my
proxy logically between an Asterisk PBX (registrar) and the SIP phones it uses
so that all calls can be monitored using my proxy. The tricky bit seems to be forcing the
Asterisk to route calls to the SIP phones via my proxy. It appears to ignore
the maddr parameter and send the INVITEs directly to the phones. Do you think
Record-Route will solve this? Thanks for the tip about repro, I’ve
downloaded it and am taking a look.
From:
Scott Godin [mailto:slgodin@xxxxxxxxxxxx] 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 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 |