[reSIProcate] Routing of signalling via proxy - opinions?

[Scott Godin]

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 at envox.com] 
Sent: Thursday, March 16, 2006 5:25 AM
To: Scott Godin; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Routing of signalling via proxy - opinions?



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.


Steve

 

  _____  

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: 13 March 2006 18:43
To: Steven Coule; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Routing of signalling via proxy - opinions?

 

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 at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Steven
Coule
Sent: Monday, March 13, 2006 12:32 PM
To: resiprocate-devel at list.sipfoundry.org
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?


Thanks,

 

Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060316/56e12584/attachment.htm>