Hi,
We have an ugly message looping scenario
where a SIP request message received at Kamailio is forwarded
to the switch/router and back to Kamailio in a loop until the
Max-forwards header value becomes 0 or the transaction times
out.
After receiving an incoming INVITE request
from a local user, Kamailio forwards the INVITE request to
another proxy located in a different network. The call is
established successfully.
During the call setup the external proxy
sends an OPTIONS request to Kamailio (actually to the external
public IP address from where it received INVITE request from
Kamailio). The OPTIONS request arrives at Kamailio. But the
request uri contains the mapped public address instead of the
local ip address where Kamailio is listening. So Kamailio
forwards the request to the public IP address (i.e. the
switch) which again sends it back to Kamailio again and it
keeps looping.
Here is the message flow. 192.168.1.3 is
the local user registered to Kamailio which is running at
192.168.1.5. IP address of the external proxy server is
10.139.90.161 and 10.139.90.137 is the public IP address of
the switch/router. NAT isn’t enabled at Kamailio.
Internet Protocol Version 4, Src:
192.168.1.3 (192.168.1.3), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE
sip:1002@video-conf SIP/2.0
Message Header
Via: SIP/2.0/UDP
192.168.1.3:5060;rport;branch=z9hG4bK1941685709
From: "xxxx"
<sip:1001@192.168.1.5>;tag=256977615
To: <sip:1002@video-conf>
Call-ID: 1110783207
CSeq: 20 INVITE
Contact:
<sip:1001@192.168.1.3>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL,
OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.5.2
(eXosip2/3.6.0)
Subject: Phone call
Content-Length: 510
Message Body
Internet Protocol Version 4, Src:
192.168.1.5 (192.168.1.5), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 trying -- your
call is important to us
Message Header
Via: SIP/2.0/UDP
192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709
From: "xxxx"
<sip:1001@192.168.1.5>;tag=256977615
To: <sip:1002@video-conf>
Call-ID: 1110783207
CSeq: 20 INVITE
Server: kamailio (3.3.3
(i386/linux))
Content-Length: 0
Internet Protocol Version 4, Src:
192.168.1.5 (192.168.1.5), Dst: 10.139.90.161 (10.139.90.161)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE
sip:1002@vc-vcs-control.air2gnd.net SIP/2.0
Message Header
Record-Route:
<sip:192.168.1.5;lr=on>
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0
Via: SIP/2.0/UDP
192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709
From: "xxxx"
<sip:1001@192.168.1.5>;tag=256977615
To: <sip:1002@video-conf>
Call-ID: 1110783207
CSeq: 20 INVITE
Contact:
<sip:1001@192.168.1.3>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL,
OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 69
User-Agent: Linphone/3.5.2
(eXosip2/3.6.0)
Subject: Phone call
Content-Length: 510
Message Body
Internet Protocol Version 4, Src:
10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 100 Trying
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0;received=10.139.90.137
Via: SIP/2.0/UDP
192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709
From: "xxxx"
<sip:1001@192.168.1.5>;tag=256977615
To: <sip:1002@video-conf>
Call-ID: 1110783207
CSeq: 20 INVITE
Content-Length: 0
Internet Protocol Version 4, Src:
10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 101 Dialog
Establishement
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0;received=10.139.90.137
Via: SIP/2.0/UDP
192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709
Record-Route:
<sip:192.168.1.5;lr=on>
From: "xxxx”
<sip:1001@192.168.1.5>;tag=256977615
To: <sip:1002@
video-conf>;tag=689763673
Call-ID: 1110783207
CSeq: 20 INVITE
Contact:
<sip:1002@10.139.90.161:5060>
Content-Length: 0
Internet Protocol Version 4, Src:
192.168.1.5 (192.168.1.5), Dst: 192.168.1.3 (192.168.1.3)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 101 Dialog
Establishement
Message Header
Via: SIP/2.0/UDP
192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709
Record-Route:
<sip:192.168.1.5;lr=on>
From: "xxxx"
<sip:1001@192.168.1.5>;tag=256977615
To:
<sip:1002@video-conf>;tag=689763673
Call-ID: 1110783207
CSeq: 20 INVITE
Contact: sip:1002@10.139.90.161:5060
Content-Length: 0
P-Received: 10.139.90.137
Internet Protocol Version 4, Src:
10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS
sip:10.139.90.137:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP
10.139.90.161:5060;rport;branch=z9hG4bK231479102
From: "yyyy"
<sip:1002@10.139.90.161>;tag=537974226
To: <sip:1001@192.168.1.5>
Call-ID: 1856507851
CSeq: 20 OPTIONS
Accept: application/sdp
Max-Forwards: 70
Content-Length: 0
Internet Protocol Version 4, Src:
192.168.1.5 (192.168.1.5), Dst: 10.139.90.137 (10.139.90.137)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS
sip:10.139.90.137:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bK8ba7.fa94bab7.0
Via: SIP/2.0/UDP
10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102
From: "yyyy"
<sip:1002@10.139.90.100>;tag=537974226
To: <sip:1001@192.168.1.5>
Call-ID: 1856507851
CSeq: 20 OPTIONS
Accept: application/sdp
Max-Forwards: 69
Content-Length: 0
Internet Protocol Version 4, Src:
10.139.90.137 (10.139.90.137), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS
sip:10.139.90.137:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bK8ba7.fa94bab7.0
Via: SIP/2.0/UDP
10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102
From: "uuuu"
<sip:1002@10.139.90.100>;tag=537974226
To: <sip:1001@192.168.1.5>
Call-ID: 1856507851
CSeq: 20 OPTIONS
Accept: application/sdp
Max-Forwards: 69
Content-Length: 0
Internet Protocol Version 4, Src:
192.168.1.5 (192.168.1.5), Dst: 10.139.90.137 (10.139.90.137)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS
sip:10.139.90.137:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bK8ba7.0b94bab7.0
Via: SIP/2.0/UDP
192.168.1.5;received=10.139.90.137;branch=z9hG4bK8ba7.fa94bab7.0
Via: SIP/2.0/UDP
10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102
From: "yyyy"
<sip:1002@10.139.90.100>;tag=537974226
To: <sip:1001@192.168.1.5>
Call-ID: 1856507851
CSeq: 20 OPTIONS
Accept: application/sdp
Max-Forwards: 68
Content-Length: 0
Internet Protocol Version 4, Src:
10.139.90.137 (10.139.90.137), Dst: 192.168.1.5 (192.168.1.5)
User Datagram Protocol, Src Port: sip
(5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS
sip:10.139.90.137:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP
192.168.1.5;branch=z9hG4bK8ba7.0b94bab7.0
Via: SIP/2.0/UDP
192.168.1.5;received=10.139.90.137;branch=z9hG4bK8ba7.fa94bab7.0
Via: SIP/2.0/UDP
10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102
From: "yyyy"
<sip:1002@10.139.90.100>;tag=537974226
To: <sip:1001@192.168.1.5>
Call-ID: 1856507851
CSeq: 20 OPTIONS
Accept: application/sdp
Max-Forwards: 68
Content-Length: 0
This message forwarding goes on for a long
time in a loop, each time with an extra Via header and
Max-Forwards value decremented by one. After sometime it
eventually times out and Kamailio starts sending 408 response
for the OPTIONS request which again keeps looping.
Probably adding an alias for the public IP
address i.e., 10.139.90.137 in the Kamailio config file would
solve the problem. But this IP address is not fixed and may
change and I guess there is no way Kamailio can learn the
public IP address on its own.
Any help or reference to previous posts if
it is already discussed and solved will be much helpful.
Regards,
Ajay