PJSIP & Asterisk issue with TLS
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 --->
INVITE sips:zz2867@xxx.xxx.xxx.xxx:5060 SIP/2.0
Via: SIP/2.0/TLS 217.169.223.250:50986;rport;branch=z9hG4bKPjfc4612c5-1684-
465d-bc4e-3efe626e3f31;alias
Max-Forwards: 70
From: sips:yy0206@xxx.xxx.xxx.xxx;tag=382ff707-70d7-43e5-ad8c-ca3319e3d124
To: sips:zz2867@xxx.xxx.xxx.xxx
Contact: sips:yy0206@217.169.223.250:50986;transport=TLS;ob
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 --->
INVITE sips:zz2867@217.169.223.250:43122;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS xxx.xxx.xxx.xxx:5060;rport;branch=z9hG4bKPj76d12694-8316-
42c6-9c16-737dc1ce9c5d;alias
From: <sip:yy0206@172.31.1.100
sip%3Ayy0206@172.31.1.100>;tag=a2953819-10ab-4673-ad5f-ba31bf3d9d60
To: sips:zz2867@217.169.223.250;ob
Contact: sips:asterisk@xxx.xxx.xxx.xxx:5060;transport=TLS
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
bind=0.0.0.0:5060
protocol=udp
and
[transport-tls]
type=transport
bind=0.0.0.0:5060
protocol=tls
cert_file=***
priv_key_file=***
password=***
cipher=***
method=tlsv1
local_net=172.31.1.0/255.255.255.0
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
Contact: yy0206/sips:yy0206@217.169.223.250 3d00261b2b Unknown
nan
Identify: yy0206/yy0206
Match: 127.0.0.1/32
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.
Two things you may want to look at.
One, confirm what is being sent in the CONTACT header. If it is indeed the internal IP of your server (172.31.1.0/24) then set your external media and signalling addresses to an IP and not a hostname. I ran into this issue recently with the hostname being used on my AWS instance of Asterisk as AWS will resolve the private IP even if the hostname is the public one. Simple solution is not to use the hostname and instead just the IP.
Second, I noticed that nothing is set in the transport field of your endpoint. I’m not sure if this is relevant as according to the documentation (https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships) it states…
Defaults: For many config options, it's very helpful to understand their default behavior. For example, for the endpoint section "transport=" option, if no value is assigned then Asterisk will DEFAULT to the first configured transport in pjsip.conf which is valid for the URI we are trying to contact.
Regardless, for me I do set this field and it does show up when I do a pjsip show endpoint myendpoint. I set it using ARI but you should be able to do it in the pjsip.conf. When I look at my endpoints they are set to 0.0.0.0-tls which is the name of my transport config.. ie.
[0.0.0.0-tls]
type=transport
protocol=tls
…
Hopefully that helps some. My guess is it’s a couple of missing configs like I just mentioned and highly likely a NAT issue with the the addresses not being set correctly. Definitely look for that CONTACT header to see what it’s being set to.
Regards,
Peter
On Oct 19, 2017, at 7:11 AM, Mladen Mijatovic mladen.mijatovic@tp.rs wrote:
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 http://217.169.223.250:50986/ --->
INVITE sips:zz2867@xxx.xxx.xxx.xxx:5060 SIP/2.0
Via: SIP/2.0/TLS 217.169.223.250:50986;rport;branch=z9hG4bKPjfc4612c5-1684-465d-bc4e-3efe626e3f31;alias
Max-Forwards: 70
From: sips:yy0206@xxx.xxx.xxx.xxx;tag=382ff707-70d7-43e5-ad8c-ca3319e3d124
To: sips:zz2867@xxx.xxx.xxx.xxx
Contact: <sips:yy0206@217.169.223.250 mailto:sips%3Ayy0206@217.169.223.250:50986;transport=TLS;ob>
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 http://217.169.223.250:43122/ --->
INVITE sips:zz2867@217.169.223.250 mailto:sips%3Azz2867@217.169.223.250:43122;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS xxx.xxx.xxx.xxx:5060;rport;branch=z9hG4bKPj76d12694-8316-42c6-9c16-737dc1ce9c5d;alias
From: <sip:yy0206@172.31.1.100 mailto:sip%3Ayy0206@172.31.1.100>;tag=a2953819-10ab-4673-ad5f-ba31bf3d9d60
To: <sips:zz2867@217.169.223.250 mailto:sips%3Azz2867@217.169.223.250;ob>
Contact: sips:asterisk@xxx.xxx.xxx.xxx:5060;transport=TLS
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
bind=0.0.0.0:5060 http://0.0.0.0:5060/
protocol=udp
and
[transport-tls]
type=transport
bind=0.0.0.0:5060 http://0.0.0.0:5060/
protocol=tls
cert_file=***
priv_key_file=***
password=***
cipher=***
method=tlsv1
local_net=172.31.1.0/255.255.255.0 http://172.31.1.0/255.255.255.0
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
Contact: yy0206/sips:yy0206@217.169.223.250 mailto:sips%3Ayy0206@217.169.223.250 3d00261b2b Unknown nan
Identify: yy0206/yy0206
Match: 127.0.0.1/32 http://127.0.0.1/32
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.
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi,
Thanks for the feedback. I will investigate this and try to implement from
Monday and will reach you with the outcome. You can check full log in the
attachments.
Thanks again.
Pozdrav/Best regards,
Mladen Mijatovic,
Technology Partnership.
2017-10-20 17:42 GMT+02:00 Peter Warrick peter@cabanawire.com:
Two things you may want to look at.
One, confirm what is being sent in the CONTACT header. If it is indeed the
internal IP of your server (172.31.1.0/24) then set your external media
and signalling addresses to an IP and not a hostname. I ran into this issue
recently with the hostname being used on my AWS instance of Asterisk as AWS
will resolve the private IP even if the hostname is the public one. Simple
solution is not to use the hostname and instead just the IP.
Second, I noticed that nothing is set in the transport field of your
endpoint. I’m not sure if this is relevant as according to the
documentation (https://wiki.asterisk.org/wiki/display/AST/PJSIP+
Configuration+Sections+and+Relationships) it states…
Defaults: For many config options, it's very helpful to understand their
default behavior. For example, for the endpoint section "transport="
option, if no value is assigned then Asterisk will DEFAULT to the first
configured transport in pjsip.conf which is valid for the URI we are trying
to contact.
Regardless, for me I do set this field and it does show up when I do a
pjsip show endpoint myendpoint. I set it using ARI but you should be able
to do it in the pjsip.conf. When I look at my endpoints they are set to
0.0.0.0-tls which is the name of my transport config.. ie.
[0.0.0.0-tls]
type=transport
protocol=tls
…
Hopefully that helps some. My guess is it’s a couple of missing configs
like I just mentioned and highly likely a NAT issue with the the addresses
not being set correctly. Definitely look for that CONTACT header to see
what it’s being set to.
Regards,
Peter
On Oct 19, 2017, at 7:11 AM, Mladen Mijatovic mladen.mijatovic@tp.rs
wrote:
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 --->
INVITE sips:zz2867@xxx.xxx.xxx.xxx:5060 SIP/2.0
Via: SIP/2.0/TLS 217.169.223.250:50986;rport;br
anch=z9hG4bKPjfc4612c5-1684-465d-bc4e-3efe626e3f31;alias
Max-Forwards: 70
From: sips:yy0206@xxx.xxx.xxx.xxx;tag=382ff707-70d7-43e5-ad8c-ca3319e3d124
To: sips:zz2867@xxx.xxx.xxx.xxx
Contact: sips:yy0206@217.169.223.250:50986;transport=TLS;ob
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 --->
INVITE sips:zz2867@217.169.223.250:43122;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS xxx.xxx.xxx.xxx:5060;rport;bra
nch=z9hG4bKPj76d12694-8316-42c6-9c16-737dc1ce9c5d;alias
From: <sip:yy0206@172.31.1.100
sip%3Ayy0206@172.31.1.100>;tag=a2953819-10ab-4673-ad5f-ba31bf3d9d60
To: sips:zz2867@217.169.223.250;ob
Contact: sips:asterisk@xxx.xxx.xxx.xxx:5060;transport=TLS
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
bind=0.0.0.0:5060
protocol=udp
and
[transport-tls]
type=transport
bind=0.0.0.0:5060
protocol=tls
cert_file=***
priv_key_file=***
password=***
cipher=***
method=tlsv1
local_net=172.31.1.0/255.255.255.0
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
Contact: yy0206/sips:yy0206@217.169.223.250 3d00261b2b Unknown
nan
Identify: yy0206/yy0206
Match: 127.0.0.1/32
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.
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org