Nando
April 23, 2025, 5:09pm
1
Hello everyone,
Setup:
Asterisk Kubernetes Service Configuration:
spec:
ports:
- name: tcp-port
protocol: TCP
port: 5060
targetPort: 5060
nodePort: 32210
- name: udp-port
protocol: UDP
port: 5060
targetPort: 5060
nodePort: 32210
Problem:
When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190.
Everything seems fine initially, but at exactly 32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I’m still receiving and sending audio. Then, at around 1:04, I get a 408 Request Timeout.
Questions:
Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well?
Why is Asterisk sending a BYE so early if audio is still flowing?
Could it be a signaling timeout or an issue with SIP dialog tracking?
Any help or pointers would be greatly appreciated!
Thanks in advance!
I don’t understand the Kubernetes side of this, although I wonder about nodePort.
However, if you mean 32 seconds, rather the 320 milliseconds that you actually wrote, an Asterisk is initiating the close, that will be because it is never getting an ACK to its 200 OK, and the 200 OK is reaching its maximum re-transmissions. That often means that the Contact header it is sending contains the wrong address. Again I can’t really factor in the Kubernetes aspects, but a common reason for that is failing tell Asterisk its address, as seen from outside NAT. Normally that would have the same port number, as inside, although i beileve it is possible to specify a different one.
Nando
April 24, 2025, 8:37am
3
Yeah, I meant 32 seconds. I posted on another forum and got the same suggestion. I’ll look into it. Thank you very much.
Nando
April 24, 2025, 10:34am
4
I’ve checked the Contact header, and it’s indeed incorrect, it’s gettingContact: sip:10.244.9.200:5060;transport=TCP . I’ve been trying to fix it but haven’t had any success so far. I’m using the configuration from This Kamailio example Contact header.
Here’s the relevant part of my Asterisk config:
[transport-tcp-nat]
type=transport
protocol=tcp
bind=0.0.0.0
local_net=10.244.0.0/16
external_media_address=192.168.1.190
external_signaling_address=192.168.1.190
[6007]
type=endpoint
context=public
disallow=all
allow=g722
allow=ulaw
auth=6007
aors=6007
transport=transport-tcp-nat
force_rport=yes
ice_support=yes
rewrite_contact=yes
Do you happen to know where the issue might be in my configuration?
jcolp
April 24, 2025, 10:47am
5
What is the IP address of what Asterisk is talking to? If it is in this range:
Nando:
local_net=10.244.0.0/16
Then external_* will not take effect because it is on the same network according to configuration.
Nando
April 24, 2025, 11:08am
6
Kamailio and RTPengine are running on the IP address 192.168.1.75 for media handling.192.168.1.190
Asterisk talks to 192.168.1.75 to send the media to the client but also talks locally to get the media from the different services such as whisper…
jcolp
April 24, 2025, 11:10am
7
Show the actual output of an attempt using “pjsip set logger on”.
Nando
April 24, 2025, 11:20am
8
[Apr 24 11:19:59] NOTICE[109]: src/mrcp_sofiasip_client_agent.c:617 Receive SIP Event [nua_i_state] Status 0 INVITE sent [speech-unimrcp-mrcp2]
[Apr 24 11:19:59] NOTICE[109]: src/mrcp_sofiasip_client_agent.c:617 Receive SIP Event [nua_i_active] Status 200 Call active [speech-unimrcp-mrcp2]a411b056a43d4856@speechsynth 10.244.9.200:46136 ↔ 10.244.9.198:1544 [1]a411b056a43d4856@speechsynth [1]
1745489996.376007Olá Carlos, como te posso ajudar hoje?`TTS_MS
[Apr 24 11:19:59] NOTICE[106]: src/mrcp_client_session.c:498 Raise App MRCP Response TTS-74
jcolp
April 24, 2025, 11:21am
9
That’s a third party set of modules. There is no logging from PJSIP in that provided output.
Nando
April 24, 2025, 11:53am
10
<— Transmitting SIP response (1372 bytes) to TCP:10.244.9.1:48370 —>sip:192.168.1.75;transport=tcp;lr;ftag=215bd4ad79da46d3894d7b45a739f590 sip:6007@62.28.2xx.1xx ;tag=215bd4ad79da46d3894d7b45a739f590sip:100@62.28.2xx.1xx ;tag=e8cb3b33-9340-439e-9d4d-317beea2b37fsip:10.244.9.200:5060;transport=TCP
<— Transmitting SIP request (520 bytes) to TCP:192.168.1.75:5060 —>sip:100@62.28.2xx.1xx ;tag=e8cb3b33-9340-439e-9d4d-317beea2b37fsip:6007@62.28.2xx.1xx ;tag=215bd4ad79da46d3894d7b45a739f590sip:192.168.1.75;transport=tcp;lr;ftag=215bd4ad79da46d3894d7b45a739f590
<— Received SIP response (411 bytes) from TCP:192.168.1.75:5060 —>sip:100@192.168.1.75:5060 ;tag=e8cb3b33-9340-439e-9d4d-317beea2b37fsip:6007@192.168.1.75:5060 ;tag=215bd4ad79da46d3894d7b45a739f590
jcolp
April 24, 2025, 11:55am
11
According to the output the TCP connection is originating from 10.244.9.1, so external_* wouldn’t kick in.
Nando
April 24, 2025, 12:02pm
12
Any tips on how I can fix this issue—either on the Asterisk side or maybe in Kamailio/RTPengine?
jcolp
April 24, 2025, 12:03pm
13
I can’t speak towards Kubernetes networking, but from an Asterisk perspective you could purposely configure local_net incorrectly.
airsay
April 24, 2025, 9:21pm
14
And you were answered on that mailing list about reviewing the Contact header and the c: in SDP. You have to use that SIP proxy to deal with this as indicated in the responses in the mailing list
Nando
May 13, 2025, 3:49pm
15
[SOLVED]
subst("/^Contact:.*<sip:(10\.244\.[0-9\.]+):/Contact:<sip:SOME IP:/ig")