[asterisk-dev] [PJSIP] Controlling RTP Media Source IP?
Mark Murawski
markm-lists at intellasoft.net
Tue Jan 5 08:10:36 CST 2021
Hi!
I have the following situation here:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; WAN1 and traffic to PBX-A / PBX-B
[transport-udp]
type = transport
symmetric_transport = yes
protocol = udp
bind = 10.13.13.38:5060
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
[transport-tcp]
type = transport
symmetric_transport = yes
protocol = tcp
bind = 10.13.13.38:5060
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
[transport-tcp-tls]
type = transport
symmetric_transport = yes
protocol = tls
allow_reload = yes
bind = 10.13.13.38:5061
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port = 5061
tos = cs3
cos = 3
cert_file = /etc/asterisk/keys/asterisk.crt
priv_key_file = /etc/asterisk/keys/asterisk.key
method = tlsv1_2
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; WAN2
;
[transport-udp-wan2]
type = transport
symmetric_transport = yes
protocol = udp
bind = 10.13.13.39:5060
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
[transport-tcp-wan2]
type = transport
symmetric_transport = yes
protocol = tcp
bind = 10.13.13.39:5060
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port = 5060
allow_reload = yes
tos = cs3
cos = 3
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
[transport-tcp-wan2-tls]
type = transport
symmetric_transport = yes
protocol = tls
allow_reload = yes
bind = 10.13.13.39:5061
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port = 5061
tos = cs3
cos = 3
cert_file = /etc/asterisk/keys/asterisk.crt
priv_key_file = /etc/asterisk/keys/asterisk.key
method = tlsv1_2
local_net = 192.168.181.0/24
local_net = 10.13.13.0/24
I then have the following call
INVITE
(Call is attached)
Packet from: ZZ.75.184.42
Packet To: -> YY.9.5.40 (Ie: WAN2), Then firewall DNATs to
10.13.13.39:5061, and asterisk gets the call
Use Case:
Now... in order for this dual-wan to operate correctly... say WAN1 is
down. Asterisk needs to be able to send RTP traffic (not just SIP
Signalling) using the correct rtp bind, associated to the correct return
transport and external_media_address
My expectation here is that since Asterisk knows it's using
transport-tcp-wan2-tls, and it has set the correct media source in the
SDP to YY.9.5.40, that the RDP engine would then send media from
10.13.13.39. But it does not....
During the above call, the outgoing RTP looks like this from tcpdump:
08:52:13.234702 IP 10.13.13.38.16384 > ZZ.75.184.42.7078: UDP, length 182
The closest thing I've found so far in digging deeper to resolve this
is: res_pjsip_sdp_rtp.c
static int create_rtp(struct ast_sip_session *session, struct
ast_sip_session_media *session_media,
const pjmedia_sdp_session *sdp)
{
....snip....
transport =
ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "transport",
session->endpoint->transport);
if (transport) {
struct ast_sip_transport_state *trans_state;
trans_state =
ast_sip_get_transport_state(ast_sorcery_object_get_id(transport));
if (trans_state) {
char hoststr[PJ_INET6_ADDRSTRLEN];
pj_sockaddr_print(&trans_state->host,
hoststr, sizeof(hoststr), 0);
if
(ast_sockaddr_parse(&temp_media_address, hoststr, 0)) {
ast_debug_rtp(1, "Transport %s
bound to %s: Using it for RTP media.\n",
session->endpoint->transport, hoststr);
media_address =
&temp_media_address;
} else {
ast_debug_rtp(1, "Transport %s
bound to %s: Invalid for RTP media.\n",
session->endpoint->transport, hoststr);
}
ao2_ref(trans_state, -1);
}
ao2_ref(transport, -1);
}
Here we check if the transport is explicitly bound, and if so, we use
it.... now if I do explicitly set the transport to
transport-tcp-wan2-tls instead of leaving it unset, then RTP is sourced
from the correct address.
But this is a dynamic contact which could be talking to asterisk either
on the 'WAN1' transports or the 'WAN2' transports.
Given that SIP OPTIONS and such will go back to the correct transport,
given the transport configuration above, it seems logical we should also
be able to send RTP using the associated transport settings as well.
So the issue here is that in res_pjsip_sdp_rtp.c, create_rtp(). I don't
see a way to find the associated endpoint/contact... it's all pointing
to null at this time.
Am I in the right place? Is there a further down the line place to
handle rtp source, or is there a way to pull up the dynamically stored
AST_SIP_X_AST_TXP here?
Also... speaking of AST_SIP_X_AST_TXP, it doesn't appear to be set in
all situations either. Looking at core debug, logging and hits to
'res_pjsip/pjsip_message_filter.c: Set transport', result in absolutely
no usage of any of the -tls transports when OPTIONS come in from this
peer, or any peer using tls.
Examples:
[2021-01-04 23:57:41.328] DEBUG[16309] res_pjsip/pjsip_message_filter.c:
Set transport 'transport-udp' on OPTIONS from 192.168.181.5:5060
[2021-01-04 23:57:41.927] DEBUG[16309] res_pjsip/pjsip_message_filter.c:
Set transport 'transport-udp' on OPTIONS from 192.168.181.5:5060
But, that's it... when getting OPTIONS over TLS, this is not tracked.
-------------- next part --------------
PJSIP Logging Enabled for host: ZZ.75.184.42
<--- Received SIP request (1388 bytes) from TLS:ZZ.75.184.42:33932 --->
INVITE sip:*1234 at YY.9.5.40 SIP/2.0
Via: SIP/2.0/TLS 192.168.5.80:33932;branch=z9hG4bK.RG95dqhHy;rport
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: sip:*1234 at YY.9.5.40
CSeq: 20 INVITE
Call-ID: dVXeZszcMw
Max-Forwards: 70
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 720
Contact: <sip:21005 at ZZ.75.184.42:33932;transport=tls>;expires=3599;+sip.instance="<urn:uuid:85feff52-16e7-4327-b3a6-62015753fb47>"
User-Agent: Linphone Desktop/4.2.4 (Debian GNU/Linux bullseye/sid, Qt 5.12.5) LinphoneCore/4.4.9-1-g18c59c7db
v=0
o=21005 2414 224 IN IP4 192.168.5.80
s=Talk
c=IN IP4 192.168.5.80
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 7078 RTP/SAVP 96 97 18 0
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 opus/48000
a=fmtp:18 annexb=yes
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:mU7Y/ourRjuElLqlGorsPT4TycWTjmJWLjnlCvJM
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:DHkC64WHH2HbNZcRFX6q+cE+BGPZd3i0M+RvxnbK
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:NS9mtVNG7dzuiimnz8URRE8PBoV1zuTqszn3f/4qXfRwcsj3tSNBisMzDlzDIA==
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:3E1E2XshnoyCVss22DcQZz7KYPIgZCEoywON7nNMoHwA/uDzPO/7MxdUouEAuA==
a=rtcp-fb:* trr-int 1000
a=rtcp-fb:* ccm tmmbr
<--- Transmitting SIP response (514 bytes) to TLS:ZZ.75.184.42:33932 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.5.80:33932;rport=33932;received=ZZ.75.184.42;branch=z9hG4bK.RG95dqhHy
Call-ID: dVXeZszcMw
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=z9hG4bK.RG95dqhHy
CSeq: 20 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1609782385/341a6f7affaa64057522cc3f5daa6d23",opaque="69f724d82e47421b",algorithm=md5,qop="auth"
Server: Asterisk PBX 16.15.0
Content-Length: 0
<--- Received SIP request (407 bytes) from TLS:ZZ.75.184.42:33932 --->
ACK sip:*1234 at YY.9.5.40 SIP/2.0
Via: SIP/2.0/TLS 192.168.5.80:33932;branch=z9hG4bK.RG95dqhHy;rport
Call-ID: dVXeZszcMw
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=z9hG4bK.RG95dqhHy
Contact: <sip:21005 at ZZ.75.184.42:33932;transport=tls>;expires=3599;+sip.instance="<urn:uuid:85feff52-16e7-4327-b3a6-62015753fb47>"
Max-Forwards: 70
CSeq: 20 ACK
Content-Length: 0
<--- Received SIP request (1665 bytes) from TLS:ZZ.75.184.42:33932 --->
INVITE sip:*1234 at YY.9.5.40 SIP/2.0
Via: SIP/2.0/TLS 192.168.5.80:33932;branch=z9hG4bK.8eaGFaPQf;rport
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: sip:*1234 at YY.9.5.40
CSeq: 21 INVITE
Call-ID: dVXeZszcMw
Max-Forwards: 70
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 720
Contact: <sip:21005 at ZZ.75.184.42:33932;transport=tls>;expires=3599;+sip.instance="<urn:uuid:85feff52-16e7-4327-b3a6-62015753fb47>"
User-Agent: Linphone Desktop/4.2.4 (Debian GNU/Linux bullseye/sid, Qt 5.12.5) LinphoneCore/4.4.9-1-g18c59c7db
Authorization: Digest realm="asterisk", nonce="1609782385/341a6f7affaa64057522cc3f5daa6d23", algorithm=md5, opaque="69f724d82e47421b", username="21005", uri="sip:*1234 at YY.9.5.40", response="31de6be238172269eac7bbdcf86abd34", cnonce="WZ2fAYNsylQEpgtJ", nc=00000001, qop=auth
v=0
o=21005 2414 224 IN IP4 192.168.5.80
s=Talk
c=IN IP4 192.168.5.80
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 7078 RTP/SAVP 96 97 18 0
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 opus/48000
a=fmtp:18 annexb=yes
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:mU7Y/ourRjuElLqlGorsPT4TycWTjmJWLjnlCvJM
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:DHkC64WHH2HbNZcRFX6q+cE+BGPZd3i0M+RvxnbK
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:NS9mtVNG7dzuiimnz8URRE8PBoV1zuTqszn3f/4qXfRwcsj3tSNBisMzDlzDIA==
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:3E1E2XshnoyCVss22DcQZz7KYPIgZCEoywON7nNMoHwA/uDzPO/7MxdUouEAuA==
a=rtcp-fb:* trr-int 1000
a=rtcp-fb:* ccm tmmbr
== Setting global variable 'SIPDOMAIN' to 'YY.9.5.40'
<--- Transmitting SIP response (340 bytes) to TLS:ZZ.75.184.42:33932 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.5.80:33932;rport=33932;received=ZZ.75.184.42;branch=z9hG4bK.8eaGFaPQf
Call-ID: dVXeZszcMw
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>
CSeq: 21 INVITE
Server: Asterisk PBX 16.15.0
Content-Length: 0
-- <PJSIP/21005-00001960> Executing [*1234 at cos_internal+local+ld:1] Set("__DialedNumber=*1234")
-- <PJSIP/21005-00001960> Executing [*1234 at cos_internal+local+ld:2] Set("__Tenant=default")
-- <PJSIP/21005-00001960> Executing [*1234 at cos_internal+local+ld:3] Goto("_cos_internal+local+ld,*1234,1")
-- <PJSIP/21005-00001960> Goto (_cos_internal+local+ld,*1234,1)
-- <PJSIP/21005-00001960> Executing [*1234 at _cos_internal+local+ld:1] Answer("")
<--- Transmitting SIP response (862 bytes) to TLS:ZZ.75.184.42:33932 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.5.80:33932;rport=33932;received=ZZ.75.184.42;branch=z9hG4bK.8eaGFaPQf
Call-ID: dVXeZszcMw
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=7bb6bcac-1dfe-43af-93e9-a6f673a3b67c
CSeq: 21 INVITE
Server: Asterisk PBX 16.15.0
Contact: <sip:YY.9.5.40:5061;transport=TLS>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 247
v=0
o=- 2414 226 IN IP4 YY.9.5.40
s=Asterisk
c=IN IP4 YY.9.5.40
t=0 0
m=audio 16758 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:71MihF06084dUcjrwLKQqToVZRQlfK0faPisCrks
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP request (695 bytes) from TLS:ZZ.75.184.42:33932 --->
ACK sip:YY.9.5.40:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.5.80:33932;rport;branch=z9hG4bK.c2KvuEM9n
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=7bb6bcac-1dfe-43af-93e9-a6f673a3b67c
CSeq: 21 ACK
Call-ID: dVXeZszcMw
Max-Forwards: 70
Authorization: Digest realm="asterisk", nonce="1609782385/341a6f7affaa64057522cc3f5daa6d23", algorithm=md5, opaque="69f724d82e47421b", username="21005", uri="sip:*1234 at YY.9.5.40", response="31de6be238172269eac7bbdcf86abd34", cnonce="WZ2fAYNsylQEpgtJ", nc=00000001, qop=auth
User-Agent: Linphone Desktop/4.2.4 (Debian GNU/Linux bullseye/sid, Qt 5.12.5) LinphoneCore/4.4.9-1-g18c59c7db
Content-Length: 0
-- <PJSIP/21005-00001960> Executing [*1234 at _cos_internal+local+ld:2] Gosub("echoTest,s,1")
-- <PJSIP/21005-00001960> Executing [s at echoTest:1] Answer("")
-- <PJSIP/21005-00001960> Executing [s at echoTest:2] Set("attempts=3")
-- <PJSIP/21005-00001960> Executing [s at echoTest:3] BackGround("demo-echotest")
-- <PJSIP/21005-00001960> Playing 'demo-echotest.ulaw' (language 'en')
<--- Transmitting SIP request (509 bytes) to TLS:ZZ.75.184.42:33932 --->
OPTIONS sip:21005 at ZZ.75.184.42:33932;transport=TLS SIP/2.0
Via: SIP/2.0/TLS YY.9.5.40:5061;rport;branch=z9hG4bKPj56e65fb6-5553-4b89-bd3e-aab371f68043;alias
From: <sip:21005 at 10.13.13.38>;tag=ed94cd14-211c-4f47-a562-caa0f870370c
To: <sip:21005 at ZZ.75.184.42>
Contact: <sip:21005 at YY.9.5.40:5061;transport=TLS>
Call-ID: 2b480ab1-a302-4cb5-a7e7-7dce98e4f9db
CSeq: 29491 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk PBX 16.15.0
Content-Length: 0
<--- Received SIP response (315 bytes) from TLS:ZZ.75.184.42:33932 --->
SIP/2.0 200 Ok
Via: SIP/2.0/TLS YY.9.5.40:5061;rport;branch=z9hG4bKPj56e65fb6-5553-4b89-bd3e-aab371f68043;alias
From: <sip:21005 at 10.13.13.38>;tag=ed94cd14-211c-4f47-a562-caa0f870370c
To: <sip:21005 at ZZ.75.184.42>;tag=eNqyi
Call-ID: 2b480ab1-a302-4cb5-a7e7-7dce98e4f9db
CSeq: 29491 OPTIONS
Content-Length: 0
<--- Received SIP request (708 bytes) from TLS:ZZ.75.184.42:33932 --->
BYE sip:YY.9.5.40:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.5.80:33932;branch=z9hG4bK.4~cpdsGWO;rport
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=7bb6bcac-1dfe-43af-93e9-a6f673a3b67c
CSeq: 22 BYE
Call-ID: dVXeZszcMw
Max-Forwards: 70
User-Agent: Linphone Desktop/4.2.4 (Debian GNU/Linux bullseye/sid, Qt 5.12.5) LinphoneCore/4.4.9-1-g18c59c7db
Authorization: Digest realm="asterisk", nonce="1609782385/341a6f7affaa64057522cc3f5daa6d23", algorithm=md5, opaque="69f724d82e47421b", username="21005", uri="sip:YY.9.5.40:5061;transport=TLS", response="67f0714e2a88467ab243500374d67667", cnonce="VKIajt-JBCi6gUyZ", nc=00000002, qop=auth
Content-Length: 0
<--- Transmitting SIP response (374 bytes) to TLS:ZZ.75.184.42:33932 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.5.80:33932;rport=33932;received=ZZ.75.184.42;branch=z9hG4bK.4~cpdsGWO
Call-ID: dVXeZszcMw
From: "21005" <sip:21005 at YY.9.5.40>;tag=f9VCnWRZm
To: <sip:*1234 at YY.9.5.40>;tag=7bb6bcac-1dfe-43af-93e9-a6f673a3b67c
CSeq: 22 BYE
Server: Asterisk PBX 16.15.0
Content-Length: 0
== <PJSIP/21005-00001960> Spawn extension (echoTest, s, 3) exited non-zero
-- <PJSIP/21005-00001960> Got SoftHangup Request (0x7f4eb9a61d40) (cause: 16)
pbs-sbc*CLI>
-------------- next part --------------
Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.>
I/OAuth: <AuthId/UserName...........................................................>
Aor: <Aor............................................> <MaxContact>
Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................>
Identify: <Identify/Endpoint.........................................................>
Match: <criteria.........................>
Channel: <ChannelId......................................> <State.....> <Time.....>
Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......>
==========================================================================================
Endpoint: 21005/21005 Not in use 0 of inf
InAuth: 21005-iauth/21005
Aor: 21005 4
Contact: 21005/sip:21005 at ZZ.75.184.42:53326;transpo 1280ac8226 Avail 49.540
Contact: 21005/sip:21005 at QQ.227.184.188:27134;tran 5af679ec25 Avail 4.566
ParameterName : ParameterValue
==========================================================
100rel : yes
@pjsip_wizard : 21005
__DeviceTenantName : default
__DeviceType : Exten
__ExtenDevice : SIP/21005
__ExtenDeviceName : 21005
__ExtenMailBox : 21005 at internal
__ExtenPhoneGroup : internal
__ExtenPhoneNum : 21005
__Tenant : default
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (ulaw|alaw|adpcm|gsm)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
aors : 21005
asymmetric_rtp_codec : false
auth : 21005-iauth
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid : 21005
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
contact_acl :
context : cos_internal+local+ld
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_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
ice_support : false
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_mwi_mailbox :
language :
log_subscription_error : false
mailboxes : 21005 at internal
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : sdes
media_encryption_optimistic : true
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 :
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : true
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 60
rtp_timeout_hold : 60
sdp_owner : -
sdp_session : Asterisk
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : true
send_rpid : true
srtp_tag_32 : false
stir_shaken : false
sub_min_expiry : 0
subscribe_context : blf
suppress_q850_reason_headers : 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 :
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : true
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no
pbs-sbc*CLI>
More information about the asterisk-dev
mailing list