Try using network=host instead of node port

Regards,

David Villasmil
email: david.villasmil.work@gmail.com



On Thu, Apr 24, 2025 at 7:42 PM Henning Westerholt via sr-users <sr-users@lists.kamailio.org> wrote:
Hello,

Does the BYE comes after 320ms or 32s? As said, look to the asterisk log why it sends the BYE, maybe it don't receive media.
Can the rtpengine actually expose ports to the internal and external network? Do you see RTP traffic flowing between the different services?

Cheers,

Henning

> -----Original Message-----
> From: airsay--- via sr-users <sr-users@lists.kamailio.org>
> Sent: Mittwoch, 23. April 2025 19:14
> To: sr-users@lists.kamailio.org
> Cc: Fernando Lopes <fernandolopes20003@gmail.com>; sr-
> users@lists.kamailio.org; airsay@duck.com
> Subject: [SR-Users] Re: SIP Call Drops After 0.32 Seconds – Asterisk on
> Kubernetes with Kamailio + RTPengine
>
> I will let the more experienced Kamailio folks comment on the
> technical/Kamailio/RTP modifications that you need to make. The SIP standard
> requires an ACK to a 200 OK to be sent within that 32 second window. If an
> ACK is not received, the session is torn down. You would need to do a packet
> capture to review the Contact header in the SIP and the c: in the SDP. I'm just
> getting bedded in with SIP, reading Alan B Johnston's "SIP: Understanding the
> Session Initiation Protocol". Excellent introduction to understanding SIP.
>
> Best regards
> Sent from my iPhone
>
> > On 23 Apr 2025, at 16:35, Fernando Lopes via sr-users <sr-
> users_at_lists.kamailio.org_airsay@duck.com> wrote:
> >
> > Hello everyone,
> > I'm running into an issue with SIP calls in my current setup and would really
> appreciate some help.
> >
> > Setup:
> > I have a machine named sip00 (IP: 192.168.1.75) running Kamailio +
> RTPengine.
> > Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This
> IP points to another machine running Asterisk inside a Kubernetes cluster.
> > RTPengine is configured with an RTP port range of 10000–20000, and my
> router is set to allow that same range.
> >
> > Asterisk Kubernetes Service Configuration:
> > yaml
> > Copy
> > Edit
> > 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 0.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 01: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!
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions --
> > sr-users@lists.kamailio.org To unsubscribe send an email to
> > sr-users-leave@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to the
> sender!
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions -- sr-
> users@lists.kamailio.org To unsubscribe send an email to sr-users-
> leave@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!