Asterisk in Kubernetes: local_net conflict when using Kamailio vs direct client

Asterisk Asterisk SIP
1

Hello Everyone,

I’m running into a problem with Asterisk and Kamailio inside Kubernetes. Both are exposed to the outside.

My Network:
External IP: 192.168.1.99:32210 TCP

Kamailio Service IP: 10.101.179.164
Kamailio Pod IP: 10.244.10.35

Asterisk Service IP: 10.99.122.141
Asterisk Pod IP: 10.244.10.38

The issue is:

  • When connecting directly to Asterisk, SIP calls only work if I remove the local_net setting, so that Asterisk advertises its external IPs.
  • When connecting through Kamailio as a proxy, calls only “works” if I enable local_net.
    I believe the problem is that Asterisk sets the Contact header to its pod IP instead of the Service IP and Kamailio is not able to send ACK which leads to call timeout.

My Transport:

[transport-tcp-nat]
type=transport
protocol=tcp
bind=0.0.0.0
local_net=10.244.10.0/16
local_net=10.96.0.0/12
external_media_address=192.168.1.99
external_signaling_address=192.168.1.99
external_signaling_port=32210

SIP Logs:

<--- Transmitting SIP response (1293 bytes) to UDP:10.244.10.35:5001 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.190:5001;rport=5001;received=10.244.10.35;branch=z9hG4bK683e.ce5a170c8d281e2227ec5a8870044ad9.0;i=4
Via: SIP/2.0/TCP 10.244.10.1:54435;rport=54435;received=10.244.10.1;branch=z9hG4bKPjb54c457d4a7d48959ca03391a56e1136;alias
Call-ID: d0e65953da0f406498b95e77aae9f850
From: <sip:6001@192.168.1.99>;tag=d9761b4e52944f068f85ff71d139f660
To: <sip:100@192.168.1.99>;tag=76784095-78d9-4467-88e6-d9fba8bfbcd6
CSeq: 21022 INVITE
Server: Asterisk PBX 18.24.3
Contact: <sip:10.244.10.38:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   487

v=0
o=- 3966074837 3966074839 IN IP4 10.244.10.38
s=Asterisk
c=IN IP4 10.244.10.38
t=0 0
m=audio 10056 RTP/AVP 9 0 101
a=ice-ufrag:4e2d77c12b938bbc4c7f3c773f3a262a
a=ice-pwd:5df2f60432675fb26b988faa6a42c1c1
a=candidate:Hc0a80163 1 UDP 2130706431 192.168.1.99 10056 typ host
a=candidate:Hc0a80163 2 UDP 2130706430 192.168.1.99 10057 typ host
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:140
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Kamailio Log:

17(65) WARNING: <script>: [onsend_route] Packet going to sip:10.99.122.141:5060
17(65) WARNING: <script>: [RTPENGINE] ACK
17(65) WARNING: <script>: [REQUEST]: d0e65953da0f406498b95e77aae9f850: got ACK

ACK sip:100@192.168.1.99:31953;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.244.10.1:54435;rport;branch=z9hG4bKPj130d3b53570f45afa764dd874a115771;alias
Max-Forwards: 70
From: <sip:6001@192.168.1.99>;tag=d9761b4e52944f068f85ff71d139f660
To: <sip:100@192.168.1.99>;tag=z9hG4bK983e.12c423f5a5497fcaafae93af5228672e.0
Call-ID: d0e65953da0f406498b95e77aae9f850
CSeq: 21021 ACK
Content-Length:  0

WireShark Log:

Session Initiation Protocol (ACK)
    Request-Line: ACK sip:10.244.10.38:5060 SIP/2.0
        Method: ACK
        Request-URI: sip:10.244.10.38:5060
            Request-URI Host Part: 10.244.10.38
            Request-URI Host Port: 5060
        [Resent Packet: False]
        [Request Frame: 2849862]
        [Response Time (ms): 3968]
    Message Header
        Via: SIP/2.0/UDP 192.168.1.163:49666;rport;branch=z9hG4bKPje5005f15847d460d81553d1f5a5e0393
            Transport: UDP
            Sent-by Address: 192.168.1.163
            Sent-by port: 49666
            RPort: rport
            Branch: z9hG4bKPje5005f15847d460d81553d1f5a5e0393
        Max-Forwards: 70
        From: <sip:6001@192.168.1.99>;tag=d8b13b005dda4b008eaf52f5d7c1f902
            SIP from address: sip:6001@192.168.1.99
                SIP from address User Part: 6001
                SIP from address Host Part: 192.168.1.99
            SIP from tag: d8b13b005dda4b008eaf52f5d7c1f902
        To: <sip:100@192.168.1.99>;tag=768c6b9f-afd5-4546-b650-8616bbec7fd7
            SIP to address: sip:100@192.168.1.99
                SIP to address User Part: 100
                SIP to address Host Part: 192.168.1.99
            SIP to tag: 768c6b9f-afd5-4546-b650-8616bbec7fd7
        Call-ID: 210137ed6d6145bc8f864a6b1d9f0f31
        [Generated Call-ID: 210137ed6d6145bc8f864a6b1d9f0f31]
        CSeq: 8750 ACK
            Sequence Number: 8750
            Method: ACK
        Content-Length:  0

Thank you.

2

Asterisk has no concept of pod IP or service IP. If you bind to “0.0.0.0” it will guess based on the routing table and interfaces it sees to try to get the correct IP address. If it gets it wrong, then you could try creating two transports each binding to the specific IP address and see unless the service IP isn’t actually bindable, then the only option is the use of local_net/external_* to substitute in.

I know there are others who deploy using Kubernetes, but don’t have insight into how they do things. Maybe they’ll respond, maybe they won’t.

3

Thank you,

I will try that. For this, I need to remove the transport in my endpoint, correct, and let Asterisk decide which is better?

4

You would most likely still need to specify a transport. You could try without, maybe it’ll work, maybe it won’t.

These are fundamentally the options within Asterisk, though, and if none of them work for you then either you may be doing things in a way counter to how others do it, or it’s a unique setup.

1 Like
5

Gave Up trying to solve this Issue.

7

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