Inbound Registration Issue – No SIP Response

Asterisk Asterisk SIP
1

Hello everyone,

I’m trying to configure Siperb Inbound Registration with an Issabel PBX running Asterisk 18.19.0 and chan_sip.

The goal is to use Siperb Proxy Registration Mode for mobile push notifications.

Siperb connection:

Asterisk is configured with:

register => <SIPERB_USERNAME>:@eu-west-1-sbc-1.siperb.com

The registration appears correctly in:

sip show registry

and shows:

Host Username Refresh State
eu-west-1-sbc-1.siperb.com:5060 120 Request Sent

However, it never changes to Registered.

Asterisk SIP debug shows that the REGISTER is actually being sent:

REGISTER sip:eu-west-1-sbc-1.siperb.com SIP/2.0
Via: SIP/2.0/UDP 196.218.112.42:5060;…
Contact: sip:s@196.218.112.42:5060
Expires: 120

The REGISTER is retransmitted several times and eventually times out.

There is no SIP response from the Siperb SBC:

  • No 401
  • No 403
  • No 200 OK
  • No other SIP response

The important part is that I have verified the network path on the FortiGate firewall.

The PBX is:
192.168.0.10

The public IP used for this traffic is:
196.218.112.42

FortiGate debug flow confirms:

192.168.0.10
→ 52.50.165.204:5060/UDP
→ SNAT 196.218.112.42
→ WAN port2

The packet is allowed by the firewall policy and leaves through the correct WAN interface.

A packet capture on the WAN interface also shows:

196.218.112.42:<random_port>
→ 52.50.165.204:5060 UDP

So from the Asterisk/FortiGate side, the REGISTER appears to be leaving correctly.

The Siperb connection dashboard remains:

State: UNKNOWN
Contact: UNKNOWN
Offline

I have also confirmed that DNS resolves correctly:

eu-west-1-sbc-1.siperb.com → 52.50.165.204

and Asterisk can resolve the hostname.

My question is:

For a Siperb Inbound Registration using chan_sip, is there anything else required in the chan_sip configuration besides the register => line?

Could there be a specific From/To domain, peer configuration, or Siperb-specific setting required before the SBC will respond to the REGISTER?

Or does the absence of even a 401 response indicate that the REGISTER is not reaching the Siperb SBC / connection?

Any guidance would be greatly appreciated.

2

Look at your own capture again. Your Via says 5060, the packet leaves on a random port. That’s the whole thing right there. The SBC reads the Via and answers back to 5060, your FortiGate has no session open on that port, packet dies on the way in. That’s why you get nothing instead of a 401.

So the REGISTER is getting there. It’s the answer that’s dying, and it’s dying on your side.

Nine times out of ten that’s the SIP ALG. Kill the sip session helper and the VoIP profile, set your NAT so 5060 stays 5060 on the way out, retest.

Also your register line has no password in it. Won’t matter until the 401 finally shows up, then it will.

And you’re on chan_sip. It’s gone in 21, so whatever you build here you get to build again.

3

Hi,
Yes, Siperb is strict on the SIP messaging, especially on new inbound requests. For new request methods like REGISTER, INVITE and MESSAGE, the Request line is inspected, and if incorrectly formatted, its just dropped.

For Inbound Registration Connections - you will need to address the Server by its name. so if you are registering with eu-west-1-sbc-1.siperb.com then your Register request line must be sip:eu-west-1-sbc-1.siperb.com

NOTE: I copied and pasted bits from my working version - so I have made some assumptions, but you should get the general idea.

REGISTER sip:{{SIPERB_SBC}}:5060 SIP/2.0
Via: ...
From: <sip:{{SIPERB_USERNAME}}@{{SIPERB_SBC}}>;tag=246b34b9
To: <sip:{{SIPERB_USERNAME}}@{{SIPERB_SBC}}>
Call-ID: 0d17fad5-3912-40d9-87d3-21924d6b6f43
CSeq: 1 REGISTER
Contact: <sip:{{SIPERB_USERNAME}}@192.168.0.1:5060;line=zbxhink>
Expires: 300
...
Content-Length:  0

Something like the above was from:
PJSIP.conf

endpoint_identifier_order=username,ip,anonymous

[single_aor](!)
max_contacts=1
qualify_frequency=120
remove_existing=yes

[userpass_auth](!)
auth_type=userpass

[basic_endpoint](!)
context=from-extensions
rtp_timeout=0 ; NB!
direct_media=no
disallow=all
rtp_keepalive=2 ; NB!
trust_id_outbound=yes
rewrite_contact=yes
force_rport=yes
rtp_symmetric=yes

[phone_endpoint](!)
allow=opus,ulaw,alaw,g722,gsm,vp9,vp8,h264

[webrtc_endpoint](!)
allow=opus,alaw,ulaw,vp9,vp8,h264
webrtc=yes

; == Users

[User1](basic_endpoint,phone_endpoint)
type=endpoint
callerid="User One" <100>
outbound_auth=User1
aors=User1
from_user={{SIPERB_USERNAME}}
from_domain={{SIPERB_SBC}}
[User1](single_aor)
type=aor
contact=sip:{{SIPERB_USERNAME}}@{{SIPERB_SBC}}:5060
[User1](userpass_auth)
type=auth
username={{SIPERB_USERNAME}}
password={{SIPERB_SECRET}}

; == Register ===

[User1_registration]
type=registration
transport=udp_transport
outbound_auth=User1
server_uri=sip:{{SIPERB_SBC}}
client_uri=sip:{{SIPERB_USERNAME}}@{{SIPERB_SBC}}
contact_user={{SIPERB_USERNAME}}
endpoint=User1
line=yes
retry_interval=60
expiration=120

Where:
{{SIPERB_SBC}} = “eu-west-1-sbc-1.siperb.com”
{{SIPERB_USERNAME}} = “(the username provided the connection page)”
{{SIPERB_SECRET}} = “the password provided int he connection page)”

4

The OP has truncated the Via line. By default, Asterisk will add an rport parameter,which says ignore the Via line information and reply to the address and port from which the request was received.

Also I find the term “inbound registration” confusing, as I would call what is being attempted here outbound registration, and I think that is the terminology that FreePBX also uses.

5

Sure, the “Connections” as they are called, are something to get your head around, but put simply it is from the perspective of the Siperb SBC… so an Inbound Connection is… “you send your register message inward to us.”. This is basically the same as every Voice Carrier or TISP. Its basically up to you to register with us and since the REGISTER message is initiated from within your own network, the REGISTER should reach us. We give you the server address, username and password, and you configure the register on your Asterisk Box.

[Asterisk] === REGISTER ===> firewall || ===> [Siperb]

In turn, we use another, unrelated register to the Mobile App, so the flow becomes:

[Asterisk] === REGISTER ===> firewall || ===> [Siperb] <=== REGISTER === [Mobile App]

There is also an “Outbound Connection”, where Siperb, is initiating the REGISTER outward towards your network. This is where you enter your details into our backend, and its up to us to register, and keep this connection open. Generally people are more used to this approach (that the “Client” needs to register with the server). This is of course more tricky to manage on a network level, as it would involve some form of port opening and port forwarding. Something not many are willing or even able to do. Hence, the two approaches.

[Asterisk] <=== firewall || <=== REGISTER ==== [Siperb]

We still use the second unrelated register from the mobile app to Siperb (your sip details are never provisioned) :

[Asterisk] <=== firewall || <=== REGISTER ==== [Siperb] <=== REGISTER === [Mobile App]
6

Thanks for the clarification.

I have verified the configuration and the REGISTER request is being sent to the SBC hostname exactly as recommended:

REGISTER sip:eu-west-1-sbc-1.siperb.com SIP/2.0

The current setup is:

  • Connection type: Inbound Registration

  • SBC: eu-west-1-sbc-1.siperb.com

  • UDP/5060

  • Allow Source IP: 196.218.112.42/32

  • Asterisk 18.19.0 / chan_sip

  • Issabel IP: 192.168.0.10

  • Public/NAT IP: 196.218.112.42

The REGISTER contains the correct Siperb username in both From and To:

From: <sip:USERNAME@eu-west-1-sbc-1.siperb.com>
To:   <sip:USERNAME@eu-west-1-sbc-1.siperb.com>

However, the actual Contact generated by chan_sip is:

Contact: <sip:s@196.218.112.42:5060>

Our Register String in Issabel is configured with the username after the /:

USERNAME:PASSWORD@eu-west-1-sbc-1.siperb.com:5060/USERNAME

So there appears to be a difference between the configured Register String and the Contact actually generated by Asterisk.

The other important point is that I have verified the FortiGate NAT/session:

192.168.0.10:5060
    → SNAT 196.218.112.42:5060
    → 52.50.165.204:5060

The FortiGate session shows the REGISTER packets leaving successfully, but zero reply packets are received from the SBC.

There is also no SIP session-helper on UDP/5060 and no VoIP profile on the firewall policy.

Could you please confirm whether Contact: sip:s@196.218.112.42:5060 would be rejected by the Siperb SBC for an Inbound Registration, or whether you specifically require the Contact user to be the Siperb username?

If the latter is required, could you please provide the exact chan_sip Register String format you expect for Asterisk 18?

Thanks.

7

This is an Asterisk forum. As far as Asterisk is concerned, this is is an outbound registration.

chan_sip is no longer supported, by the main Asterisk project. The only supported version of Asterisk that contains it will change to security fixes only in less than four weeks from now, and chan_sip is deprecated and has community support only, in that version. Asterisk 18 was end of life just short of two years ago.

This is such a stable and not uncommonly used feature, that I find it difficult to believe it could be broken in an un-forked version from any time in the last decade. Can you provide the configuration values from the .conf file generated by Issabel (assuming it is a FreePBX fork) and the REGISTER request from the the Asterisk full log, with “sip set debug on”, set, and the full log enabled.

Even if s@ were being sent, the registration would still be valid, and Asterisk would accept, and respond to, an incoming INVITE, although possibly with a 404 response. As long as the domain part is correct, Siperb should accept it, and even if it didn’t it should have responded, as the request would be syntactically valid.

8

Just about any version of Asterisk should be able to register with Siperb. It could be something on the router, let’s see. Raise a support ticket, just email your details of what you have and the config so far, and we can take it from there. (Support At Siperb)

9

Hi,
I actually opened a support ticket with Siperb quite some time ago regarding this exact issue, but unfortunately I haven’t received any response yet.

That’s why I’m following up here and trying to troubleshoot it with the community.

If you could please check the ticket or help escalate it with the support team, I would really appreciate it.

Thanks.

10

Hi,
You don’t have any open tickets. You can see this by opening the Siperb app and going to Settings > Support, and switching to the Support Tickets Tab.

My support agent drew this up for the chan_sip.conf
(its not tested because i don’t have any chan_sip instances running)

; sip.conf
register => <USERNAME>:<PASSWORD>@eu-west-1-sbc-1.siperb.com/<USERNAME>
;                                                            ^^^^^^^^^^
;   the trailing /<USERNAME> sets the Contact user — fixes the "s@" you saw

[siperb]
type=peer
host=eu-west-1-sbc-1.siperb.com
port=5060
defaultuser=<USERNAME>
fromuser=<USERNAME>
fromdomain=eu-west-1-sbc-1.siperb.com   ; the SBC host, NOT your xxx.siperb.com domain
secret=<PASSWORD>
insecure=port,invite
nat=force_rport,comedia                 ; so our 401/200 returns through the FortiGate
qualify=yes
directmedia=no
disallow=all
allow=ulaw,alaw
context=from-siperb
12

Hi, I really need your help with this because we are currently blocked by this issue.

We have already contacted support several times by email, and we also submitted requests through the Support section in the application. The application gives us a ticket number and says the request was submitted successfully, but when we check our support tickets afterward, there is no ticket visible.

I also want to clarify where we are technically now, so we don’t keep changing things on our side unnecessarily.

Our Issabel/Asterisk server is sending REGISTER requests to:

SBC: eu-west-1-sbc-1.siperb.com
IP: 52.50.165.204
UDP/5060
Public source IP: 196.218.112.42

The FortiGate confirms that the traffic is being SNATed correctly from 192.168.0.10 to 196.218.112.42 and is being sent to the SBC.

However, Asterisk remains at “Request Sent” and we receive absolutely no SIP response from the SBC.

We also tested the same SBC from another external network previously, with the source IP restriction temporarily removed, and still received no SIP response.

I’m only looking for a basic confirmation from your side about the connection status and whether the REGISTER requests are reaching the SBC.

If you can confirm that the REGISTER is reaching your side, we can continue troubleshooting the authentication/configuration from there.

And if possible, please help us locate the support ticket that we submitted through the application, because it appears to disappear after submission.

Thanks a lot for your help.

13

Your ncat/nc probes are reaching us (but these packets are dropped/ as they are not SIP).

ERROR:core:receive_msg: Unable to parse msg received from [196.218.112.42:37149] 
ERROR:core:parse_msg_opt: message=<Ncat: Version 7.70 ( https://nmap.org/ncat )>

However that is the only traffic that we get from your IP. No sign of a REGISTER - leave the register attempting.