Configure an extension that registers against kamailio via websocket

Asterisk Asterisk Endpoints
1

Good morning,

I’ve configured mi kamailio to register extensions via websocket, and then resend the register SIP message to asterisk. This seems to work propperly and the extension appear to be register in asterisk but when i try to make a call to that extension or from that extension asterisk always reponds with 488 and this error on console (res_pjsip_session.c:937 handle_incoming_sdp: 2032: Couldn’t negotiate stream 0:audio-0:audio:sendrecv (nothing))
This seems to be a problem with SDP, but i can’t figure out what’s the problem.
Asterisk is using Realtime, and kamailio only changes SIP headers but RTP traffic doesn’t go through kamailio

Any help will be much appreciated

2032 endpoint:
asterisk18*CLI> pjsip show endpoint 2032

Endpoint: <Endpoint/CID…> <State…> <Channels.>
I/OAuth: <AuthId/UserName…>
Aor: <Aor…>
Contact: <Aor/ContactUri…> <Hash…> <RTT(ms)…>
Transport: <TransportId…> <BindAddress…>
Identify: <Identify/Endpoint…>
Match: <criteria…>
Channel: <ChannelId…> <State…> <Time…>
Exten: <DialedExten…> CLCID: <ConnectedLineCID…>

Endpoint: 2032 Not in use 0 of inf
Aor: 2032 1
Contact: 2032/sip:2enhtce8@IP_PUBLICA_KAMAILIO:5060;x-ast 991f96b186 NonQual nan
Transport: transporte_extension udp 0 0 0.0.0.0:5081

ParameterName : ParameterValue

100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (opus|g722|alaw|ulaw)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : 2032
asymmetric_rtp_codec : false
auth :
bind_rtp_to_media_address : false
bundle : true
call_group :
callerid :
callerid_privacy : allowed_not_screened
callerid_tag :
codec_prefs_incoming_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow
connected_line_method : invite
contact_acl :
context : from_kamailio
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : true
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_auto_generate_cert : No
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : false
force_rport : true
from_domain :
from_user :
g726_non_standard : false
geoloc_incoming_call_profile :
geoloc_outgoing_call_profile :
ice_support : true
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_call_offer_pref : local
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording : false
outbound_auth :
outbound_proxy :
outgoing_call_offer_pref : remote_merge
overlap_context :
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : true
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
security_mechanisms :
security_negotiation : no
send_aoc : false
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : false
send_rpid : false
set_var :
srtp_tag_32 : false
stir_shaken : off
stir_shaken_profile :
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_bind_udptl_to_media_address : false
t38_udptl : false
t38_udptl_ec : none
t38_udptl_ipv6 : false
t38_udptl_maxdatagram : 0
t38_udptl_nat : false
timers : yes
timers_min_se : 90
timers_sess_expires : 1800
tone_zone :
tos_audio : 0
tos_video : 0
transport : transporte_extension
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no

transporte
asterisk18*CLI> pjsip show transport transporte_extension

Transport: <TransportId…> <BindAddress…>

Transport: transporte_extension udp 0 0 0.0.0.0:5081

ParameterName : ParameterValue

allow_reload : false
allow_wildcard_certs : No
async_operations : 1
bind : 0.0.0.0:5081
ca_list_file :
ca_list_path :
cert_file :
cipher :
cos : 0
domain :
external_media_address : IP_PUBLICA_ASTERISK
external_signaling_address : IP_PUBLICA_ASTERISK
external_signaling_port : 0
local_net :
method : unspecified
password :
priv_key_file :
protocol : udp
require_client_cert : No
symmetric_transport : false
tos : 0
verify_client : No
verify_server : No
websocket_write_timeout : 100

Call example (sngrep)
IP_KAMAILIO:5060 IP_ASTERISK:5081
──────────┬───────── ──────────┬─────────
│ INV (IP_ASTERISK) │
15:21:35.125002 │ audio 53032 (opus/48000/2) │
+0.059581 │ ──────────────────────────> │
15:21:35.184583 │ 100 Trying │
+0.000856 │ <────────────────────────── │
15:21:35.185439 │ 488 Not Acceptable Here │
+0.000866 │ <────────────────────────── │
15:21:35.186305 │ ACK │
│ ──────────────────────────> │

INVITE (IP_ASTERSK)
IP_KAMAILIO:5060 → IP_ASTERISK:5081
INVITE sip:Phone_NUM@IP_KAMAILIO SIP/2.0
Via: SIP/2.0/UDP IP_KAMAILIO:5060;branch=z9hG4bK9cf2.e51d02a2a91e306bf02595e6fd2fb277.0
To: sip:648502327@IP_KAMAILIO;user=phone
From: “2032” sip:2032@IP_KAMAILIO;user=phone;tag=0tnnuqeotl
CSeq: 1 INVITE
Call-ID: fth1qbfmobpc1n1fc4dk
Max-Forwards: 69
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: Browser Phone 0.3.12 (SIPJS - 0.20.0)
Content-Type: application/sdp
Content-Length: 1811
Contact: sip:btpsh-653670b5-191a7-b@IP_KAMAILIO:5060

v=0
o=- 6176326236146416100 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS d81c8410-fb6a-49df-9340-ddb04c05b66b
m=audio 50632 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 80.33.30.219
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1621932144 1 udp 2122260223 IP_PRIVADA 50632 typ host generation 0 network-id 1
a=candidate:3954439433 1 udp 2122194687 IP_PRIVADA 50633 typ host generation 0 network-id 2
a=candidate:3148847153 1 udp 1686052607 IP_PUBLICA 50632 typ srflx raddr 10.21.1.176 rport 50632 generation 0 network-id 1
a=candidate:2651221220 1 tcp 1518280447 IP_PRIVADA 9 typ host tcptype active generation 0 network-id 1
a=candidate:353968541 1 tcp 1518214911 IP_PRIVADA 9 typ host tcptype active generation 0 network-id 2
a=ice-ufrag:rzX5
a=ice-pwd:ZYCdpaYmiNT8RF8Phu7yHNrc
a=ice-options:trickle
a=fingerprint:sha-256 E5:EE:4E:01:33:24:6F:25:03:8B:2F:54:54:D2:30:7D:FD:EC:53:0D:1C:EE:14:7F:0B:50:62:2A:C0:F2:3F:91
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 docs/native-code/rtp-hdrext/abs-send-time - src - Git at Google
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:d81c8410-fb6a-49df-9340-ddb04c05b66b 6503cd7e-c5a5-4689-8e3d-63b33be93dc2
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:2953366916 cname:UbWX4fNUPy46fKgV
a=ssrc:2953366916 msid:d81c8410-fb6a-49df-9340-ddb04c05b66b 6503cd7e-c5a5-4689-8e3d-63b33be93dc2

Asterisk 488 Response
IP_ASTERISK:5081 → IP_KAMAILIO:5060
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP IP_KAMAILIO:5060;rport=5060;received=IP_KAMAILIO;branch=z9hG4bK9cf2.e51d02a2a91e306bf02595e6fd2fb277.0
Call-ID: fth1qbfmobpc1n1fc4dk
From: “2032” sip:2032@IP_KAMAILIO;user=phone;tag=0tnnuqeotl
To: sip:648502327@IP_KAMAILIO;user=phone;tag=64d072e3-3b4e-4354-8a72-61ec2b3484ff
CSeq: 1 INVITE
Server: VIVELIBRE-SISDEV-WEBRTC
Content-Length: 0

Thank you in advance for any help. If there’s anything else that i need to explain let me know

2

The SDP appears to be WebRTC, so the “webrtc” option should be set to “yes”.

3

Hi, thanks for your response. I will try it now
But could you explain me why i need to configure it like this? The websocket conection is against kamailio, and it sends SIP traffic to asterisk. But the connection between asterisk and kamailio is not websocket.

Again, thank you for your response.

4

You need to configure it like that because the SDP is WebRTC. Websocket is just how the SIP signaling itself is conveyed, it has no bearing on the SDP.

5

Good morning,

You were completly right, after changing webrtc to yes it started working. I’ve been testing for a week and everything looks ok

Thank you for your time and knowledge

6

Good evening,

It’s me again haha.
I got another question, but i’m not sure if it belongs here (if not please let me know and i’ll open a new ticket)
In the scenario i’ve set (an extension that registers against kamailio via websocket and then it sends the SIP messages to asterisk). Do i need to set RTPengine (or similar alication) on my kamailio? In case it’s not necesary, is it a good practice to do that?

Again, thank you for your time

7

I have no input on that.

8

Okay, ill try to ask on kamailio forums then.

Again, thank you for your quick reply
Have a nice day

9

Good evening,

Apologies for opening this again but i’ve realised that asterisk accepts the INVITE from my kamailio but when responding INVITE (SDP) from asterisk to kamailio i receive no response on kamailio. But responses 100 trying, 200 ok, and bye everithing works fine

It seems to not send INVITE (SDP), but when looking it in sngrep it seems to be fine

If it’s not clear please let me know and i’ll explain it with more detail

Thank you for your time

10

There is insufficient information here as to what you mean. If you see the expected packet in sngrep, then it will have been sent. Doesn’t mean it went to where you expected, but it reached the network layer.

11

Thank you again for your reply,

The sngrep output i have is like this (I upload it as a screenshot because when paste it is hard to read, if you need it in text tell me)

Kamailio:

image
image1559×401 21.9 KB

Asterisk:

image
image1654×763 56.3 KB

Is there any parameter that i have to set on pjsip configuration to fix this? As you said it looks like it is sending the message but not to my kamailio

12

If sngrep tells you that Asterisk is sending the Invite, then I would believe
it. If kamailio is not responding to it, I would examine the kamailio end, or
ask the kamailio people what the problem is.

Antony.

13

It not seems to be related to kamailio. I have it working when it is with plain SIP messages, problems seems to appear when i use wss conections from the users to kamailio.
And 200 ok, 100 trying and bye messages from asterisk to kamailio works perfectly.

Just guessing (probably i’m wrong), it seems that the INVITE (SDP) message is is treated different by asterisk, probably because a bad config

If you told me it’s not like that i’ll keep finding a solution to this

Thank you for your reply

14

The sngrep screenshot provided shows that Asterisk received an INVITE, sent a 100 Trying, then tried to send a 200 OK and there were retransmissions. Why that is - no idea. The contents of it aren’t shown, or whether your redaction is incorrect for IP addresses.

Fundamentally you have a lot of complicated moving parts in this arrangement. You have a WebRTC based endpoint (and WebRTC itself is complicated), Kamailio, and Asterisk. I don’t know if anyone here can really support or help you with it outside of general answers because of that. We also don’t know what is “correct” for your setup.

15

thank you for yor reply

I’ll keep trying to find a solution to this. There isn’t much information about this scenario (at least i can’t find anything) and i’m not sure what to do next.

Please could you tell me if there is any difference between how asterisk treat the first invite it receives and the INVITE (SDP).

Again, thank you for all your replies

16

Fundamentally, no. If authentication has to occur then that would be different, as the first INVITE would be challenged and then the second attempt would include credentials and likely be accepted.

The problem is most likely something in your setup, which means you need to determine what that is, and further isolate things. Asterisk is sending a 200 OK in the screenshot. Is it going to the correct place? Where does it get lost? Why does it get lost? Those are the questions you have to answer.

17

I feel as though I should add that you’ve got a complex setup as I previously mentioned. It’s not a beginner level thing, and you need a solid foundation in multiple areas (WebRTC, Javascript, Kamailio, Asterisk, SIP) if you’re planning on deploying this in a production environment. When things go wrong even beyond this, without that knowledge you’re going to hit a road block.

18

Aparently it is sending the INVITE (SDP) properly, it’s send to the exact same direction as 100 trying, and bye. But i got nothing on my kamailio, i have even try to completly remove FW from kamailio cloud in order to capture all trafic and search for the INVITE (SDP) that sends asterisk but i couldn’t find anything

What really blows my mind is that if webrtc is set to no asterisk does not accept calls because of incorrect SDP but when it’s set to yes asterisk accept the call but the INVITE (SDP) is lost somewhere. Because of that i tought it was related to that parameter

I’ll keep working on it, thank you for you feedback and help

19

It’s not lost. Asterisk receives the INVITE with SDP, handles it, sends a 100 Trying, and then sends a 200 OK to answer the call. The 200 OK to answer the call retransmits multiple times until it gives up and the call is terminated. The INVITE is received by Asterisk fine.

20

Yes, that’s what i mean. Sorry i explained myself poorly.

What i was trying to say is that when webrtc is set to no kamailio sends and invite and receives the 488 response from asterisk properly. But when webrtc is set to yes kamailio sends an invite but doesn’t receive the 200ok that asterisk is sending, but he receives responses 100 trying, and bye.

Thank you again for your time and help