Connect to Metronet on premise SBC using PJSIP

Asterisk Asterisk SIP
1

I will be connecting an Asterisk 18 system to a on premise Metronet session border controller. I have read the interop guide and it looks pretty straight forward except the SBC does not require authentication. I have searched all over the Internet and have not found a guide or example pjsip.conf on how to configure PJSIP to connect to a trunk without authentication.

I would appreciate it if someone could provide a good resource on how to do this.

Thanks,

2

You don’t set an auth on the endpoint, or outbound registration if that’s being done. That’s all. Even if you did set an auth, the remote side wouldn’t challenge and so it would never be used.

3

jcopl, thanks for the quick reply. If I understand you correctly, my pjsip.conf should look something like the following - which is just the usual pjsip endpoint config just without an auth or aor section. If this is correct, what tells PJSIP it needs to make outgoing connections?

; Metronet SIP Trunk
[transport-udp-metronet]
type=transport
protocol=udp
bind=192.168.150.2:5060
local_net=192.168.150.0/30

[metronet]
type=endpoint
transport=transport-udp-metronet
context=Inbound
direct_media=no
allow=!all,ulaw

Also, is there anyway to test the SBC configuration before it is installed? Currently I have a SIP phone connected as my “trunk” to test my dialplan - but I wasn’t able to setup it up without authentication.

4

The AOR section defines how to contact something. Without it you would need to specify it on the Dial string.

With an AOR:

[metronet]
type=aor
contact=sip:192.168.150.50

[metronet]
type=endpoint
transport=transport-udp-metronet
context=Inbound
direct_media=no
allow=!all,ulaw
aors=metronet

PJSIP/18005551111@metronet for dial string.

Without:

PJSIP/metronet/sip:18005551111@192.168.150.50

With 192.168.150.50 being a dummy address for the SBC.

The most you could do is send a call out and watch the SIP traffic go and get no response.

5

Thanks! Looks pretty straight forward, but I would feel a lot better if I could test it before the cut-over.

6

I have completed the migration to Metronet and thought I would post my pjsip.conf here in case it helps someone else:

; Metronet SIP Trunk
[udp-inbound]
type=transport
protocol=udp
bind=192.168.150.2:5060
local_net=192.168.150.0/30

; Metronet SIP Trunk
[udp-inbound]
type=transport
protocol=udp
bind=192.168.150.2:5060
local_net=192.168.150.0/30

[metronet-inbound]
type=aor
max_contacts=1
contact=sip:1234567@192.168.150.2

[metronet-inbound]
type=identify
endpoint=metronet-inbound
match=192.168.150.1
match=192.168.150.2

[metronet-outbound]
type=endpoint
transport=udp-inbound
context=Outbound
direct_media=no
allow=!all,ulaw
aors=metronet-outbound

[metronet-outbound]
type=aor
contact=sip:192.168.150.1

[metronet-outbound]
type=identify
endpoint=metronet-outbound
match=192.168.150.1
match=192.168.150.2
7

This should not be duplicated.

I cannot think of a valid reason to have both of these, although I suppose there could be obscure cases. In this case, you don’t want max_contacts.

Also, I cannot think of a reason why you would have 1234567@, as you will always override it, except for qualify, and it doesn’t sound right for qualify.

The first of these is unreferenced, and the second references a nonexistent endpoint. Having separate inbound and outbound sections was a work round for a limitation of chan_sip. It often isn’t necessary for chan_sip, and I can’t think of a valid use for chan_pjsip.

Having two type=identify sections with matches for the same address will result in indeterminate (implementation dependent) behaviour.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.