Hi
We think we need some help with our Asterisk server.
We are using Asterisk 13.9.1 with Pjproject 2.5.5 on Ubuntu 16.04.
Server is located in the cloud, and test clients are on the local WiFi, behind the same router. We are, mostly successfully, making TLS calls between two clients.
However, we have been experiencing some problems, and we think we have traced their root to the specific invite message. It might be a configuration issue, and we would appreciate any help with resolving it.
We believe that source of the problems is "From" line in INVITE message forwarded to the callee, that contains "sip" , instead of "sips", address. In further course of the call, it likely propagates to "To" headers, and eventually ends up in "Contact" header, which causes call to end due "SIPS Required" error.
This is the INVITE message that is received by asterisk from the caller:
[Oct 18 15:47:13] VERBOSE[21198] res_pjsip_logger.c: <--- Received SIP request (1630 bytes) from TLS:
217.169.223.250:50986 --->
Via: SIP/2.0/TLS 217.169.223.250:50986;rport;branch=z9hG4bKPjfc4612c5-1684-465d-bc4e-3efe626e3f31;alias
Max-Forwards: 70
Call-ID: a62d94a3-17ba-4fd5-acb7-c3e6e9514f5a
CSeq: 12748 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Authorization: *******************************************************
Content-Type: application/sdp
Content-Length: 650
v=0
o=- 3717323230 3717323230 IN IP4 192.168.15.207
s=pjmedia
b=AS:30
t=0 0
m=audio 4000 RTP/SAVP 3 96
c=IN IP4 192.168.15.207
b=TIAS:13200
a=rtcp:4001 IN IP4 192.168.15.207
a=sendrecv
a=rtpmap:3 GSM/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=crypto:1 *******************************************************
a=crypto:2 *******************************************************
a=crypto:3 *******************************************************
a=crypto:4 *******************************************************
This is the INVITE message forwarded to the callee (note From line):
[Oct 18 15:47:14] VERBOSE[21718] res_pjsip_logger.c: <--- Transmitting SIP request (1048 bytes) to TLS:
217.169.223.250:43122 --->
Via: SIP/2.0/TLS xxx.xxx.xxx.xxx:5060;rport;branch=z9hG4bKPj76d12694-8316-42c6-9c16-737dc1ce9c5d;alias
Call-ID: 6c9e38cb-3515-421a-ae00-40636f1912ac
CSeq: 31285 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REGISTER, REFER
Supported: timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: VoIPServerBeta
Content-Type: application/sdp
Content-Length: 339
v=0
o=- 54900247 54900247 IN IP4 172.31.1.100
s=Asterisk
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 6016 RTP/SAVP 3 0 101
a=crypto:1 *******************************************************
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
There are two defined transports:
[transport-udp]
type=transport
protocol=udp
and
[transport-tls]
type=transport
protocol=tls
cert_file=***
priv_key_file=***
password=***
cipher=***
method=tlsv1
external_media_address=xxx.xxx.xxx.xxx
external_signaling_address=xxx.xxx.xxx.xxx
external_signaling_port=5060
(We are aware that default port for TLS is 5061. 5060 also work, and binding to 5061 didn't help. Nether did removing UDP transport.)
All users have the same configuration. This is the example:
Endpoint: yy0206 Not in use 0 of inf
InAuth: yy0206/yy0206
Aor: yy0206 1
Identify: yy0206/yy0206
ParameterName : ParameterValue
=========================================================
100rel : no
accountcode :
aggregate_mwi : true
allow : (gsm|ulaw)
allow_subscribe : true
allow_transfer : true
aors : yy0206
auth : yy0206
bind_rtp_to_media_address : false
call_group :
callerid : <unknown>
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
context : voip_test
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : XXX
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
force_avp : false
force_rport : true
from_domain :
from_user :
g726_non_standard : false
ice_support : false
identify_by : username
inband_progress : false
language :
mailboxes :
media_address :
media_encryption : sdes
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : false
named_call_group :
named_pickup_group :
one_touch_recording : false
outbound_auth :
outbound_proxy :
pickup_group :
record_off_feature : automixmon
record_on_feature : automixmon
rewrite_contact : false
rpid_immediate : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
send_diversion : true
send_pai : false
send_rpid : false
set_var :
srtp_tag_32 : false
sub_min_expiry : 0
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 :
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : true
user_eq_phone : false
voicemail_extension :
We would very much appreciate any help with this issue.
Thank you.
Pozdrav/Best regards,
Mladen Mijatovic,
Technology Partnership.
