[OpenSIPS-Users] OpenSIPS ALG
Robert Dyck
rob.dyck at telus.net
Fri May 22 18:38:20 CEST 2009
Knowing the status of a registration attempt would be useful. One would not
necessarily remove the local registration if the external attempt failed.
Local calling would still be possible. As well a remote family member for
example could take advantage of such dual registration and could take calls
that came through a service provider or calls that originated on the LAN.
Using dynamic DNS acquaintances could also call into the LAN without going
through a service provider. The UA only concerns itself with the username not
the domain. Using aliases and fixed IP addresses on the LAN you can even ring
individual phones.
I use my proxy much as I have described. I am currently back and forth between
two residences. Using an SPA3000 and my proxy, my PSTN calls ring at both
places. As well my wife and I call each other without going through the PSTN
or a voip service provider although the service provider handles the
voicemail.
I see myself as a SIP promoter. A good way for a beginner to get experience is
to set up a home or small office system. As I said before I understand that
Opensips must cater to the service provider but nurturing the newbies is
good. They are the future.
On Friday 22 May 2009, Bogdan-Andrei Iancu wrote:
> Hi Robert,
>
> Interesting points of view :).
>
> But there is a huge difference between a proxy acting as a mid-registrar
> (with no auth knowledge, no user knowledge, but simply following the
> master registrar decisions in a blind way) and proxy doing actually
> account and registrar management (like you described in the scenario
> with hiding registrations).
>
> I'm not saying is not possible, but the question is where a proxy stops
> and where an ALG starts :).
>
> Anyhow, I will add on the TODO list the possibility to do a register at
> reply time, so that we can use opensips as mid-registrar.
>
> Regards,
> Bogdan
>
> Robert Dyck wrote:
> > I like the idea that we could maintain a local registrar that accurately
> > reflects the remote registration. I would go so far as to say that it
> > would be useful to be able to optimize opensips as an ALG. Some people
> > could use a proxy as an edge device on a LAN. You could have several
> > phones with the same user name register with a service provider. Some
> > service providers limit the number of contacts per AOR. This would have
> > the side effect of keeping the signaling associated with forking on the
> > LAN. By detecting local calls, media could also be kept on the LAN. Such
> > an edge device might have a dynamic IP address. It would be helpful if
> > opensips could conveniently be setup to fix the contacts. Using the
> > received address does not work when the phones are on the same LAN as the
> > proxy.
> >
> > Opensips has a bias toward service providers. This is quite
> > understandable. However I feel with a bit of tweaking it could serve as
> > an ALG for the home owner or a small business.
> >
> > On Wednesday 13 May 2009, Bogdan-Andrei Iancu wrote:
> >> Hi Jeff,
> >>
> >> theoretically yes, because you have all the needed information
> >> (hmm...maybe except the NAT status from request, but you can store it
> >> via transaction)....Practically, the save() function does expect to
> >> receive a request only, so it must be changed to work with a reply also.
> >>
> >> Regards,
> >> Bogdan
> >>
> >> Jeff Pyle wrote:
> >>> I've thought a lot about this as well, although I haven't taken it
> >>> nearly as far as John has.
> >>>
> >>> A thought: is it possible to do a save() in the reply route, only upon
> >>> a 200 OK from the end registrar?
> >>>
> >>>
> >>> - Jeff
> >>>
> >>> On 5/12/09 5:09 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro>
wrote:
> >>>> Hi John,
> >>>>
> >>>> This mid-registrar approach may work but it is not 100% correct as
> >>>> OpenSIPS (as mid-registrar) does not obey the actions of the final
> >>>> registrar (Asterisk). Ex:
> >>>> - Asterisk may forbid the registration and you already saved the
> >>>> registration on OpenSIPS
> >>>> - Asterisk may change the Expire time while to saved the
> >>>> registration with the expire sent by client.
> >>>>
> >>>> Anyhow, ignoring this aspects, lets go further :) :
> >>>>
> >>>> 1) is the registration scenario working ok? if not what is the exact
> >>>> problem (some trace will help).
> >>>>
> >>>> I will wait for you answer before moving further with the calling
> >>>> stuff.
> >>>>
> >>>> Regards,
> >>>> Bogdan
> >>>>
> >>>> John Morris wrote:
> >>>>> After several days of playing with OpenSIPS 1.5.0 and RTPProxy 1.2.0,
> >>>>> I have a partially working SIP+RTP ALG configuration, and have gotten
> >>>>> stuck. I could use some general advice from the list.
> >>>>>
> >>>>> The company has an Asterisk/FreePBX server on an internal network,
> >>>>> and the CEO wants to use a SIP phone from outside. Because the sip
> >>>>> alg iptables module isn't working, and in preparation for another
> >>>>> project, I started investigating OpenSIPS for use as a border proxy
> >>>>> to connect phones across NAT (and, the next project, to route a SIP
> >>>>> trunk over a VPN from the network of a DSL+phone company that
> >>>>> intermittently blocks SIP traffic in hopes of plugging revenue
> >>>>> leaks).
> >>>>>
> >>>>> The network looks like this:
> >>>>>
> >>>>> SIP UA <-> home NAT gateway <-> Internet <-> OpenSIPS server/NAT
> >>>>> router <-> Asterisk
> >>>>>
> >>>>> The standard opensips.cfg file doesn't work as is. The SIP phone
> >>>>> needs to register to the Asterisk server directly. In addition, it
> >>>>> seems there is extra logic needed to support multiple network
> >>>>> interfaces (mhomed=1 only partially solves the problem).
> >>>>>
> >>>>> The way I've gone with this in testing is to relay REGISTERs to
> >>>>> Asterisk, but after a save("location","0x02") to enable a
> >>>>> lookup("location") on messages originating from the PBX. The phone
> >>>>> is configured with an outbound proxy, and all packets to the proxy
> >>>>> matching "uri==myself" are thrown away. This worked great on the
> >>>>> single-interfaced, internal test installation. Now that there are
> >>>>> multiple interfaces involved, things are breaking again; ACKs and
> >>>>> BYEs are sent out the wrong interface, and RTPProxy is behaving
> >>>>> strangely in bridged mode.
> >>>>>
> >>>>> There seem to be no good configuration examples for either
> >>>>> multi-homed proxies or for proxies that relay REGISTERs. This makes
> >>>>> me think that I'm going about this the wrong way.
> >>>>>
> >>>>> Also, I have looked at other software, like siproxd, opensbc and uh,
> >>>>> that other b2bua that functions as an SBC, but none of those seem to
> >>>>> allow this REGISTER pass-through function.
> >>>>>
> >>>>> What is the best approach for this scenario? The above approach of
> >>>>> relaying REGISTERs to Asterisk? Is there maybe another approach
> >>>>> where phones register to OpenSIPS directly, and OpenSIPS in turn
> >>>>> somehow sends another REGISTER to Asterisk? Or am I missing the idea
> >>>>> completely?
> >>>>>
> >>>>> I'd appreciate general pointers about how to proceed. I've been
> >>>>> putting some Asterisk and FreePBX tutorials and CentOS RPMs on
> >>>>> http://www.zultron.com, mostly aimed at small office-like
> >>>>> environments. Looking through various lists, this seems a highly
> >>>>> sought-after configuration. If I succeed, I'll document it in hopes
> >>>>> of filling the gap in this sort of example.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Users mailing list
> >>>>> Users at lists.opensips.org
> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at lists.opensips.org
> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list