My SIP call flows are as follows:
WebRTC User → OpenSIPS → Asterisk (Business Logic) → OpenSIPS → External Trunk External Trunk → OpenSIPS → Asterisk (Business Logic) → OpenSIPS → WebRTC User / External Trunk
OpenSIPS acts as a SIP proxy, and both OpenSIPS and Asterisk are running on the same server but listening on different ports.
The issue I’m facing is that Asterisk is not generating ACK or BYE messages correctly. This is because the Contact header in the SIP messages contains the WebRTC user’s IP, causing Asterisk to try sending ACK and BYE directly to the WebRTC user. Ideally, Asterisk should rely on the Record-Route headers for this purpose, as the routing information is already available there.
My Questions:
Why is Asterisk not using the Record-Route headers to send ACK and BYE?
Could the fact that OpenSIPS and Asterisk share the same IP (but different ports) be causing this issue?
jcolp
December 18, 2024, 9:19pm
2
You haven’t provided the configuration, or shown a SIP trace, or stated which SIP channel driver is in use. These are all important to be able to answer questions.
using asterisk 20 and pjsip channel.
and made a trunk in pjsip_wizard.conf with opensips
[mbl-callmax]
type = wizard
endpoint/context = tp-opensips ; Context for calls from OpenSIPS
endpoint/disallow = all ; Disable all codecs
endpoint/allow = ulaw,alaw,gsm ; Allow specific codecs
endpoint/direct_media = no ; Disable direct media
endpoint/rewrite_contact = yes ; Ensure Asterisk rewrites the Contact header for proper dialog handling
endpoint/force_rport = yes ; Use source port for responses
aor/contact = sip:172.51.121.225:6060 ; IP and port of the trunk
remote_hosts = 172.51.121.225
pjsip.conf
[transport-udp]
type=transport
protocol=udp ;udp,tcp,tls,ws,wss,flow
bind=172.51.121.225:5060
local_net=172.51.121.225
symmetric_transport=yes
asterisk->opensips
2024/12/19 10:56:43.070999 172.51.121.225:5060 -> 172.51.121.225:6060
INVITE sip:0322@172.51.121.225:6060 SIP/2.0
Via: SIP/2.0/UDP 172.51.121.225:5060;rport;branch=z9hG4bKPj7f43bf9b-8c34-4fe9-b5de-df30d29b519c
From: <sip:03016677711@172.51.121.225>;tag=082a9683-361f-44c4-ac91-51aeb068f8d1
To: <sip:0322@172.51.121.225>
Contact: <sip:asterisk@172.51.121.225:5060>
Call-ID: 84c06fad-9d84-43f2-a4b9-bbcdc6cfa442
CSeq: 1988 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.5.2
Content-Type: application/sdp
Content-Length: 284
v=0 o=- 68988126 68988126 IN IP4 172.51.121.225
s=Asterisk
c=IN IP4 172.51.121.225
t=0 0
m=audio 32094 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
opensips -> asterisk
2024/12/19 10:56:48.520811 172.51.121.225:6060 -> 172.51.121.225:5060
SIP/2.0 200 OK
From: <sip:03016677711@172.51.121.225>;tag=082a9683-361f-44c4-ac91-51aeb068f8d1
To: <sip:0322@172.51.121.225>;tag=nsBOtOxQZgp89enT1Z6E
Contact: <sips:0322@124.29.217.18:57436;transport=wss>
Call-ID: 84c06fad-9d84-43f2-a4b9-bbcdc6cfa442
User-Agent: MWWRTC 3.6.23056
CSeq: 1988 INVITE
Content-Type: application/sdp
Content-Length: 437
Via: SIP/2.0/UDP 172.51.121.225:5060;rport=5060;received=172.51.121.225;branch=z9hG4bKPj7f43bf9b-8c34-4fe9-b5de-df30d29b519c
Record-Route: <sip:172.51.121.225:8089;transport=wss;r2=on;lr;ftag=082a9683-361f-44c4-ac91-51aeb068f8d1;nat=wss;did=8f.b1457855>
Record-Route: <sip:172.51.121.225:6060;r2=on;lr;ftag=082a9683-361f-44c4-ac91-51aeb068f8d1;nat=wss;did=8f.b1457855>
Allow: ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
v=0
o=- 7365425525489908000 2 IN IP4 172.51.121.225
s=Mizutech - chrome t=0 0
a=msid-semantic: WMS 3eea8860-83d4-48f7-8031-1ebfffc9b667
m=audio 39246 RTP/AVP 0 8 101
c=IN IP4 172.51.121.225
a=msid:3eea8860-83d4-48f7-8031-1ebfffc9b667 4ea0b6b1-26ad-4f9d-b2ee-e79e3fd4427e
a=ssrc:238794072 cname:TiMNqC7OBXqRGRnI
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=rtcp:39247
a=ptime:20
in this scenario asterisk is not sending the ACK against 200OK
jcolp
December 19, 2024, 9:28am
5
Don’t set rewrite_contact to yes.
yes I commented this line in trunk configuration but still same behavior.
jcolp
December 20, 2024, 9:32am
7
Then I would suggest actually showing a complete log with full SIP trace[1].
[1] Collecting Debug Information - Asterisk Documentation
system
January 19, 2025, 9:33am
8
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
