PJSIP - anonymous endpoint, dialing via proxy

Hi,

I’m in the process of migrating our Asterisk configuration from chan_sip to PJSIP, and have run into a problem with the way we do dial strings.

For some background, we’re using a very simple “bare bones” Asterisk configuration with chan_sip configured with insecure=invite, and a dialplan which just throws new channels into stasis. We have SIP proxies and registrars which manage registration and authentication where needed, and we orchestrate and manage our calls via ARI. Asterisk is not using any real-time configuration or pre-configured users.

We have multiple SIP proxies in front of the Asterisk services, and we dial in and out via these proxies. Our software which is orchestrating calls via ARI is also aware of all the proxies involved, and the various routes to/from our Asterisks and the outside world.

Now the problem. Using chan_sip, we could build dial strings which looked something like this:

SIP/target-host/target-user/outbound-proxy

This does the following for us:

  • Creates an INVITE with a URI which looks like sip:target-user@target-host
  • Sends the INVITE via outbound-proxy

This all works marvelously. We also have variations which append custom Route: headers for more complicated routing scenarios, using magical __SIPADDHEADER5n variables along with the ARI channel creation request (not even sure how this is going to interact with PJSIP, yet, one thing at a time).

I currently have an anonymous endpoint defined as follows in pjsip.conf:

[anonymous]
type=endpoint
transport=transport-udp
context=my-stasis-context
allow=all

This works for accepting inbound calls, and making outbound calls using an endpoint/dialstring of pjsip/anonymous/sip:target-user@target-host.

So my question is, how may I (or can I even) achieve the equivalent of our current chan_sip style dial strings, which allow software to determine the outbound_proxy dynamically at runtime, without the need for database reliance and the like?

I just noticed that if I construct an endpoint with an outbound_proxy in pjsip.conf (for testing, this is impractical in my use-case), and dial using PJSIP/anonymous/sip:target-peer@target-host, the outbound INVITE SIP URI is simply sip:outbound-proxy (the To: header is target-peer@target-host though), rather than the chan_sip format noted above as sip:target-user@target-host. This is both with and without an AoR of either sip:user@proxy or sip:proxy.

This can possibly be worked around at our outbound-proxy level with some URI rewriting, although I’d prefer to keep these changes limited to Asterisk configuration as much as possible, and some changes to our software where needed.

I should also note I’m using an Asterisk build pulled from the git master branch.

If you want to use loose routing (where the request URI is preserved) then you need to add ;lr to the end of the outbound proxy URI.

Example:
outbound_proxy=sip:proxy.voip.com;lr

As for control from the dialplan, this isn’t currently possible. The Dial string for PJSIP is extremely simple and EVERYTHING requires an endpoint. It would theoretically be possible to construct an ephemeral endpoint from the dialplan and use that, but noone has done so or experimented with it.

Hi,

Thanks for the reply, I’ll try with loose routing.

Since endpoints are absolutely required per proxy I need to route via, I think I found the solution to my problems in https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration.

I should be able to construct endpoints dynamically at runtime, and then dial them when required.

Thanks!

Yup! That should work fine.

Hi I followed these instructions but Asterisk complains when it parses out the outbound_proxy information
Using Realtime ps_endpoints Table.
I have an endpoint configured with outbound_proxy as having sip:proxy_url;lr
Asterisk says "as outbound proxy URI ‘lr’ is not valid"
Thanks much

When putting it in a database you should be able to leave out the , the \ is used in configuration files to escape the next character. Without it the configuration file would consider the “;lr” a comment.

Thanks for response. Found out that I needed to put ^3Blr for ASCII characters. Seems to work.