Asterisk rewrites Record-Route header with incorrect tcp port

Asterisk Asterisk SIP
1

Hello.

I have Asterisk 16 with chan_pjsip SIP channel driver and I try to realize scenario with Asterisk and Opensips SIP proxy. The simple scheme of it is:

UA1 ---- Opensips ----Asterisk ----- Opensips -----UA2.

And I have the issue on piece “Asterisk - Opensips” of that chain. When signaling to Asterisk with tls transport, Opensips uses dynamic tcp port, but adds Record-Route header with its ip and port 5061, on which expects replies from Asterisk.
When Asterisk sends back 200 OK reply to Opensips, it rewrites Record-Route header from 5061 to dynamic port pointed above.
Then, Opensips relays 200 reply to UA1 with that dynamic port, and UA1’s ACK addressed to this port, Opensips drops because it never got connection to it from UA1. The description of this behaivior is below:

Opensips:48470 Asterisk (5062)
1 leg ------------------INVITE (RR:5061)------------>
<-----------------INVITE--------------------------------- 2 leg
2 leg --------------OK (RR:5061)-------------------->
<--------------------ACK (Route:48470)------------ 2 leg
< -------------------OK (RR: 48470) ----------------- 1 leg
1 leg. ACK From UA1 to Asterisk through Opensips (Route:48470) sent, but dropped.

I asked Opensips developers about this situation and they said that rewriting Record-Route header is illegal from SIP protocol point of view.

How could Asterisk community experts comment that situation?

2

What is the actual endpoint configuration? Do you have rewrite_contact set to yes? If so, then it would be rewriting things.

3

Hello, Jcolp.

Endpoin config is:

Endpoint: 505050/505050 Not in use 0 of inf
InAuth: 505050-auth/505050
Aor: 505050 1
Contact: 505050/sip:505050@UA1_IP:8852;transpo d3b38f8e46 NonQual nan
Transport: 0.0.0.0-tls tls 3 96 0.0.0.0:5062

ParameterName : ParameterValue

100rel : yes
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (opus|ulaw|g722|ilbc|h264|alaw)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : 505050
asymmetric_rtp_codec : false
auth : 505050-auth
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid : “505050” <505050>
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
contact_acl :
context : from-internal
cos_audio : 5
cos_video : 4
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 : auto
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 : ru
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : sdes
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 : true
outbound_auth :
outbound_proxy :
pickup_group :
preferred_codec_only : false
record_off_feature : apprecord
record_on_feature : apprecord
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : true
rtp_timeout : 30
rtp_timeout_hold : 300
sdp_owner : -
sdp_session : Asterisk
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : true
send_rpid : false
set_var :
srtp_tag_32 : false
stir_shaken : false
sub_min_expiry : 0
subscribe_context :
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 : 184
tos_video : 136
transport : 0.0.0.0-tls
trust_connected_line : yes
trust_id_inbound : true
trust_id_outbound : false
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no

When disabling “Rewrite contact”, endpoint is registered with its own IP instead of proxies one. Thus, Asterisk tries to connect directly to endpoint and unfortunately it’s not what i need.

4

That’s what Path support is for. You’d need to add it in OpenSIPS. It is for ensuring that requests to the client still go through the proxy after registration. Do note that it does not currently work in conjunction with the PJSIP_DIAL_CONTACTS dialplan function[1]. You could also possibly statically set the proxy on the endpoint for outbound dialing…

Otherwise there is nothing explicitly for this.

[1] [ASTERISK-28211] chan_pjsip: Path header is not used with PJSIP_DIAL_CONTACTS - Digium/Asterisk JIRA

5

Jcolp, thanks, I’ll try it.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.