SIPERB SBC calling out

[gudge25]

hi there
on a free account after registration outbound
I can see outbound call attempts

but SIPERB SBC is not doing next step = authentication why ?

[InnovateAsterisk]

Hi, I see, yes - the image above shows the INVITE that you receive from us, and on the left is the remaining sequence of messages, showing that you are responding with the 401 Unauthorised, and my SBC is sending the ACK, but not actually sending the subsequent INVITE containing the digest authentication.

Let me perform some tests on my side, and i'll get back to you.

[InnovateAsterisk]

I see the issue. Please try again.

[gudge25]

sorted - now i can see subsequent INVITE
Please advise
where I can check settings for the Asterisk side to be able to use Asterisk for Outbound calls.

FYI
passwords with more than 25 symbols are cutted

[InnovateAsterisk]

passwords with more than 25 symbols are cutted

Yes, this is a limitation of the OpenSIPS proxy Service. It must also be said that relying solely on a password is not a good security strategy. We specifically use static IP Address allocations for the SBC array. (You are on SBC_1) it will always have the same IP address. Please apply ip firewall rules to only allow traffic from our address, especially on port 5060.

We will make sure that the UI can only accept 25 characters too, thanks for pointing that out.

where I can check settings for the Asterisk side to be able to use Asterisk for Outbound calls.

If you have a hosted PBX, and are using the Outbound Connections - this means that you are "registering" your Siperb account as if you were a typical desk phone/client. This means there is no further settings to apply after the registration. Simply dial the endpoint in the same was as if there was a Yealink desk phone registered.

P.S. Also note that we have updated the Settings Window today! 🎉

[InnovateAsterisk]

We noticed some freed back from other customers about a the transcoding setting. Firstly, there was inconsistent call handling caused from a routing issue - we have now fixed!.

At the same time it occurred to us that there was some confusion over the use of the transcoding feature, so Im, putting this message here for you and others to clear this up.

Siperb Call Transcoding

Siperb takes an unusual approach to the connections. We are using UDP for the register signalling, much like a regular SIP registration that a desktop phone would use, but, the INVITE that the browser phone generates is sent pretty much as-is to your registered endpoint.
This means the invite will be sent from the browser with the requirements of a webrtc enabled endpoint expecting to setup a DTLS-SRTP media stream with ICE candidates etc. In other words, on your Asterisk box it will be expected to be received by an endpoint with webrtc=yes, in its config. This is the part that gets most people stuck, as typically if an endpoint is using UDP transport for the registration flow, it will not be set to webrtc=yes.

It’s perfectly acceptable to specify transport=udp and webrtc=yes - I realise this seems odd. But it does work well. (transport and media don't really have anything to do with each other.)

What does this mean for you?

If you don't have the webrtc=yes flag on, then your endpoint can only send or receive regular RTP calls, and this means you will have to use our transcoding service. Using the transcoding option is a quick fix tho, and not optimal. Using our transcoding server means that all media is sent to our transcoding server in Ireland, and back again - It will add latency.
(If you cannot enable webrtc in the endpoint config, then you don't really have another option.)

The switch for Transcoding is “disabled” for now - but we will be running a promo until the end of March 2025 to use the transcoder for free. Thereafter it will become a paid for feature. 🚀

💥 Also note: we will introduce a “direct connection” service soon, that will provision all the webrtc details to the browser phone, meaning you can connect directly to your own Asterisk Websocket port, and signal directly.

[gudge25]

I can confirm now - outbound is working from Asterisk PBX

but I cannot call back because your SIPP PROXY
ignore OPTIONS

[InnovateAsterisk]

Please leave the connection enabled on your side, I don't see the OPTIONS attempts.

[InnovateAsterisk]

I have a test account with Voipfone, and their accounts register and stay registered fine.

The one thing to note is that the OPTIONS reply doesn’t tel you what you may doing wrong and doesn’t respond at all in these cases - this is for security.

The one thing I can tell you is that we don’t respond to being pinged (or anything really) on our ip address - you must refer to use via the correct FQDN.

[gudge25]

Sorry for confusing you
let me describe
1- I'm registered

2- after I'm registered, the asterisk will be sent back

ARE YOU ALIVE packages on IP from where I'm registered

if there is no reply it will mask. as Unavail and no further calls will be routed to that extension so VM will be used

Contact: 226/sip:226@52.50.165.204:5060;x-ast-orig-host 8cc983d861 Unavail nan

Here is an example off a successful ARE YOU ALIVE and 200 ok

Please advise

[InnovateAsterisk]

The hope was to block any traffic directed to us as an IP address, meaning you would not be able to ping us on:
Contact: 226/sip:226@52.50.165.204:5060;x-ast-orig-host 8cc983d861,
but rather on:
Contact: 226/sip:226@eu-west-1-sbc-1.siperb.com:5060;x-ast-orig-host 8cc983d861. (As you can see your contact should use the FQDN.)

The difference being that bot's and scanners wouldn't know to use our address, and this cuts out a lot of spam traffic.

For now, I have lifted this restriction - but will have to monitor the spam. If need be, i'll have to implement the restriction again. (You should be able to get Asterisk to use FQDN's rather than IP addresses.)

I can see your endpoint is now getting the response back to the OPTIONS ping.

[gudge25]

oh i see what you mean
after i set
rewrite_contact = no

and now I can see
Contact: 226/sip:226@eu-west-1-sbc-1.siperb.com 7cea821429 Avail 278.286

and now OPTIONS are sending with URI

I tested and everything seems to work
SORTED THANKS

[InnovateAsterisk]

Glad it's working!

Btw... If you are not using the transcoding server, your calls will be peer-to-peer (where the one "peer" is your Asterisk Server and the other is the users browser). We are doing a promotion at the moment to allow users to try the transcoding for free - but in truth it's better that the media is sent peer-to-peer in any case. There is a KB article on this that describes this in details.

Some of the reasons why you may want to use the transcoder is that:

• It's more flexible - if you are not able to enable webrtc=yes, or you want to use regular phone on this endpoint from time to time.
• It's more secure - you are required to lock down inbound ports to a single IP address. (you would open a single accept UDP rule to our transcoder)