Hi!
Daniel has set a code freeze date for the next major release and the Kamailio community needs to work together to prepare the release.
That means you as well!
There will be a lot of work in the coming weeks to merge code from SIP router into the Kamailio core to complete the merger process. We also have a large set of new modules and functions to test. The creation of a new release is much more than code - it's testing, documentation proof-reading and feedback. With a large and complex piece of software like Kamailio we can't test all functions with all possible combinations of configurations and connections to third party products - this is where YOU can help out!
Read more on http://www.kamailio.org/w/2012/12/preparations-for-new-release/ and join us in creating the new release!
/O
Hi everyone,
I am a beginner in using Kamailio. I am currently building a load balancer
for multiple SIP Servers, all of them are Kamailio. The Load balancer can
help end-users REGISTER and INVITE normally, but has problems with ACK and
BYE.
Messages 180 Ringing and 200 OK sent successfully to the Caller, but the ACK
failed, is transmitted to the SIP Server then stop here, doesn't go back to
Load balancing. (Caller's BYE -> LB -> Proxy then stop here). Because
doesn't receive ACK, the Called continuously sent 200 call OK to Caller
(sent successfully) and wait for confirmation ACK (after arrival to the SIP
Server, ACK doesn't come back to Load Balancing). Because the Called party
doesn't receive ACK, the call will be automatically disconnected after 30
seconds.
With BYE have rather, if the Caller hangs up first, BYE is transferred over
SIP Server and returned to Load balancer, but Load Balancing can't sent it
to the Called (Caller's BYE -> LB -> Proxy -> LB then do not go to the side
of called). Caller had picked off the phone, but the Caller is not received
BYE and after 30 seconds the call will automatically disconnect (by ACK
errors). If the called party hangs up first, HUNG UP button of the called
even useless, and I don't see any packet of the Called party's BYE message
in Wireshark.
I use X-Lite and EyeBeam for two end users, the configuration of the SIP
Server is the default configuration of Kamailio.
DISPATHCHER.LIST:
I have 3 Kamailio SIP Proxies, all of them OK, share one DB located in Proxy
2. But for capturing packets more convenient, I turn off the Proxy 2 and 3.
# group sip addresses of your * units
# Kamailio SIP Proxies/Registrars
1 sip:192.168.3.11:5060
#1 sip:192.168.3.12:5060
#1 sip:192.168.3.13:5060
Previously I used the Stateless Load Balancing configuration by default, but
could not INVITE:
# -- dispatcher params --
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "force_dst", 1)
route{
if ( !mf_process_maxfwd_header("10") )
{
sl_send_reply("483","To Many Hops");
drop();
};
ds_select_dst("1", "0");
record_route();
forward();
# t_relay();
}
Then I changed the following, sent INVITE and setup call successfully, but
met ACK and BYE error above.
if ( is_method("INVITE")) {
# Not Dispatch INVITE from SIP Proxies
if ( ds_is_from_list("1") ) {
t_relay();
} else if ( !ds_is_from_list("1") ) {
route(DISPATCH);
}
} else {
# If not INVITE
route(DISPATCH);
}
}
route[DISPATCH] {
# dispatch destinations
ds_select_dst("1", "0");
record_route();
t_relay();
#forward();
}
Please tell me How to modify in the configuration of Proxy and Load
Balancing?
Thank so much for helping!
Best Regard
Nguyen Anh Tuan,
--------------------------------------------------------------------
The latest 200 OK from Called after Ringing : LB->Caller
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-a7349502ae55
cf46-1--d87543-;rport=9040
Record-Route: <sip:192.168.3.11;lr;nat=yes>
Record-Route: <sip:192.168.3.10;lr=on>
Contact: <sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 435
Caller's ACK (1001(a)192.168.3.88) to Load Balancer (192.168.3.10):
Via: SIP/2.0/UDP
172.24.104.159:9040;branch=z9hG4bK-d87543-6f1c8659392a0773-1--d87543-;rport
Max-Forwards: 70
Route: <sip:192.168.3.10;lr>
Route: <sip:192.168.3.11;lr;nat=yes>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 ACK
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9
b292",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 0
ACK 192.168.3.10:5060 (Load Balance) to 192.168.3.11:5060 (Proxy) then
STOP HERE (Not transfer further)
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-6f1c8659392a
0773-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 ACK
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9
b292",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 0
Caller's BYE (1001(a)192.168.3.88) to Load Balance (192.168.3.10)
Via: SIP/2.0/UDP
172.24.104.159:9040;branch=z9hG4bK-d87543-616e232f86191a37-1--d87543-;rport
Max-Forwards: 70
Route: <sip:192.168.3.10;lr>
Route: <sip:192.168.3.11;lr;nat=yes>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
BYE was transferred from Load Balance(192.168.3.10) to Proxy (192.168.3.11),
repeated THREE TIMES, possibly due to an error loop (Route(DISPATCH)?)
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 69
Route: <sip:192.168.3.10;lr>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.1
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Send back BYE from SIP Proxy (192.168.3.11) to Load Balance (192.168.3.10)
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0
Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.10:5060>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
BYE LOOPs Back from Load Balance(192.168.3.10) to Proxy (192.168.3.11),
possibly due to an error loop (Route(DISPATCH)?)
Record-Route: <sip:192.168.3.10;lr=on>
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.33f49894.0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.23f49894.0
Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0
Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 66
Contact: <sip:1001@192.168.3.10:5060>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Hi everyone,
I am a beginner in using Kamailio. I am currently building a load balancer
for multiple SIP Servers, all of them are Kamailio. The Load balancer can
help end-users REGISTER and INVITE normally, but has problems with ACK and
BYE.
Messages 180 Ringing and 200 OK sent successfully to the Caller, but the ACK
failed, is transmitted to the SIP Server then stop here, doesn't go back to
Load balancing. (Caller's BYE -> LB -> Proxy then stop here). Because
doesn't receive ACK, the Called continuously sent 200 call OK to Caller
(sent successfully) and wait for confirmation ACK (after arrival to the SIP
Server, ACK doesn't come back to Load Balancing). Because the Called party
doesn't receive ACK, the call will be automatically disconnected after 30
seconds.
With BYE have rather, if the Caller hangs up first, BYE is transferred over
SIP Server and returned to Load balancer, but Load Balancing can't sent it
to the Called (Caller's BYE -> LB -> Proxy -> LB then do not go to the side
of called). Caller had picked off the phone, but the Caller is not received
BYE and after 30 seconds the call will automatically disconnect (by ACK
errors). If the called party hangs up first, HUNG UP button of the called
even useless, and I don't see any packet of the Called party's BYE message
in Wireshark.
I use X-Lite and EyeBeam for two end users, the configuration of the SIP
Server is the default configuration of Kamailio.
DISPATHCHER.LIST:
I have 3 Kamailio SIP Proxies, all of them OK, share one DB located in Proxy
2. But for capturing packets more convenient, I turn off the Proxy 2 and 3.
# group sip addresses of your * units
# Kamailio SIP Proxies/Registrars
1 sip:192.168.3.11:5060
#1 sip:192.168.3.12:5060
#1 sip:192.168.3.13:5060
Previously I used the Stateless Load Balancing configuration by default, but
could not INVITE:
# -- dispatcher params --
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "force_dst", 1)
route{
if ( !mf_process_maxfwd_header("10") )
{
sl_send_reply("483","To Many Hops");
drop();
};
ds_select_dst("1", "0");
record_route();
forward();
# t_relay();
}
Then I changed the following, sent INVITE and setup call successfully, but
met ACK and BYE error above.
if ( is_method("INVITE")) {
# Not Dispatch INVITE from SIP Proxies
if ( ds_is_from_list("1") ) {
t_relay();
} else if ( !ds_is_from_list("1") ) {
route(DISPATCH);
}
} else {
# If not INVITE
route(DISPATCH);
}
}
route[DISPATCH] {
# dispatch destinations
ds_select_dst("1", "0");
record_route();
t_relay();
#forward();
}
Please tell me How to modify in the configuration of Proxy and Load
Balancing?
Thank so much for helping!
Best Regard
Nguyen Anh Tuan,
--------------------------------------------------------------------
The latest 200 OK from Called after Ringing : LB->Caller
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-a7349502ae55
cf46-1--d87543-;rport=9040
Record-Route: <sip:192.168.3.11;lr;nat=yes>
Record-Route: <sip:192.168.3.10;lr=on>
Contact: <sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 435
Caller's ACK (1001(a)192.168.3.88) to Load Balancer (192.168.3.10):
Via: SIP/2.0/UDP
172.24.104.159:9040;branch=z9hG4bK-d87543-6f1c8659392a0773-1--d87543-;rport
Max-Forwards: 70
Route: <sip:192.168.3.10;lr>
Route: <sip:192.168.3.11;lr;nat=yes>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 ACK
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9
b292",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 0
ACK 192.168.3.10:5060 (Load Balance) to 192.168.3.11:5060 (Proxy) then
STOP HERE (Not transfer further)
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-6f1c8659392a
0773-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 2 ACK
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@registrar.sip.vn",response="ec2a4c8832bc7bf7665811c26ec9
b292",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 0
Caller's BYE (1001(a)192.168.3.88) to Load Balance (192.168.3.10)
Via: SIP/2.0/UDP
172.24.104.159:9040;branch=z9hG4bK-d87543-616e232f86191a37-1--d87543-;rport
Max-Forwards: 70
Route: <sip:192.168.3.10;lr>
Route: <sip:192.168.3.11;lr;nat=yes>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
BYE was transferred from Load Balance(192.168.3.10) to Proxy (192.168.3.11),
repeated THREE TIMES, possibly due to an error loop (Route(DISPATCH)?)
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 69
Route: <sip:192.168.3.10;lr>
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.13f49894.1
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.03f49894.0
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.88:9040>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Send back BYE from SIP Proxy (192.168.3.11) to Load Balance (192.168.3.10)
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0
Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 68
Contact: <sip:1001@192.168.3.10:5060>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
BYE LOOPs Back from Load Balance(192.168.3.10) to Proxy (192.168.3.11),
possibly due to an error loop (Route(DISPATCH)?)
Record-Route: <sip:192.168.3.10;lr=on>
Record-Route: <sip:192.168.3.10;lr=on>
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.33f49894.0
Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKc5be.23f49894.0
Via: SIP/2.0/UDP 192.168.3.11;branch=z9hG4bKc5be.0070e643.0
Via: SIP/2.0/UDP 192.168.3.10;rport=5060;branch=z9hG4bKc5be.03f49894.1
Via: SIP/2.0/UDP
172.24.104.159:9040;received=192.168.3.88;branch=z9hG4bK-d87543-616e232f8619
1a37-1--d87543-;rport=9040
Max-Forwards: 66
Contact: <sip:1001@192.168.3.10:5060>
To: "1004"<sip:1004@registrar.sip.vn>;tag=8e782d60
From: "1001 registrar.sip.vn"<sip:1001@registrar.sip.vn>;tag=7c72f24e
Call-ID: 1926bb7b58289f2fODg1OTZlZGE5MTAxN2JhOWJjNTZmOGQ1OTljOTJiNjc.
CSeq: 3 BYE
Proxy-Authorization: Digest
username="1001",realm="registrar.sip.vn",nonce="T4uyKE+LsPwWJBt3JseE7OVdd58P
32lS",uri="sip:1004@192.168.3.10:5060;rinstance=040c24111dc72132",response="
c738898739dc49c02676e04a28761971",algorithm=MD5
User-Agent: eyeBeam release 1003s stamp 31159
Reason: SIP;description="User Hung Up"
Content-Length: 0
Hi,
I am running Kamailio 3.3 as a Homer capture agent, the sip-capture module
receives HEP packets from a sip-trace module in a remote kamailio instance.
Periodically the capture agent dies. The log and core dump suggest the
initial problem is an invalid HEP msg received, but kamailio crashes when
trying to send an error reply. Can anyone shed any light on this?
Thanks,
Owen Lynch
Back trace:
Program terminated with signal 11, Segmentation fault.
#0 0x0813c916 in send2child (tcpconn=0xb55c1c60) at tcp_main.c:3967
3967 tcp_main.c: No such file or directory.
in tcp_main.c
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.80.el6.i686 keyutils-libs-1.4-4.el6.i686
krb5-libs-1.9-33.el6.i686 libcom_err-1.41.12-12.el6.i686
libselinux-2.0.94-5.3.el6.i686 mysql-libs-5.1.61-4.el6.i686
nss-softokn-freebl-3.12.9-11.el6.i686 openssl-1.0.0-20.el6_2.5.i686
zlib-1.2.3-27.el6.i686
(gdb) bt
#0 0x0813c916 in send2child (tcpconn=0xb55c1c60) at tcp_main.c:3967
#1 0x08136e78 in handle_tcpconn_ev (fm=<value optimized out>, ev=<value
optimized out>,
idx=<value optimized out>) at tcp_main.c:4310
#2 handle_io (fm=<value optimized out>, ev=<value optimized out>,
idx=<value optimized out>)
at tcp_main.c:4362
#3 0x0813ea3c in io_wait_loop_epoll () at io_wait.h:1092
#4 tcp_main_loop () at tcp_main.c:4656
#5 0x080a502b in main_loop () at main.c:1727
#6 0x080a6c00 in main (argc=11, argv=0xbfeafd14) at main.c:2546
Log:
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: : <core>
[pass_fd.c:288]: ERROR: receive_fd: recvmsg on 10 failed: Connection reset
by peer
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: <core>
[tcp_main.c:2347]: BUG: tcp_send: failed to get fd(receive_fd): Connection
reset by peer (104)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: sl
[../../forward.h:193]: msg_send: ERROR: tcp_send failed
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR: ***
cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=704 a=3 n=exit
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[xavp.c:365]: destroying xavp list (nil)
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[receive.c:293]: receive_msg: cleaning up
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: ERROR:
sipcapture [sipcapture.c:682]: ERROR: sipcapture:hep_msg_received: not
supported version or bad length: v:[10] l:[10] vs [40]
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:634]: SIP Reply (status):
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:636]: version: <SIP/2.0>
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:638]: status: <500>
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:640]: reason: <Invalid CSeq>
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/parse_via.c:1286]: Found param type 234, <received> =
<yadayadayada>; state=6
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/parse_via.c:1286]: Found param type 232, <branch> =
<z9hG4bK2348.d1620f62.0>; state=16
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/parse_via.c:2561]: end of header reached, state=5
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:511]: parse_headers: Via found, flags=2
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19568]: DEBUG: <core>
[parser/msg_parser.c:513]: parse_headers: this is the first via
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: ALERT: <core>
[main.c:785]: child process 19576 exited by a signal 11
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: ALERT: <core>
[main.c:788]: core was generated
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: INFO: <core>
[main.c:800]: INFO: terminating due to SIGCHLD
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19575]: INFO: <core>
[main.c:851]: INFO: signal 15 received
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19574]: INFO: <core>
[main.c:851]: INFO: signal 15 received
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19573]: INFO: <core>
[main.c:851]: INFO: signal 15 received
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19572]: INFO: <core>
[main.c:851]: INFO: signal 15 received
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm
[t_funcs.c:122]: DEBUG: tm_shutdown : start
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm
[t_funcs.c:125]: DEBUG: tm_shutdown : emptying hash table
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm
[t_funcs.c:127]: DEBUG: tm_shutdown : removing semaphores
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm
[t_funcs.c:129]: DEBUG: tm_shutdown : destroying tmcb lists
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tm
[t_funcs.c:132]: DEBUG: tm_shutdown : done
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: tls
[tls_init.c:674]: tls module final tls destroy
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core>
[mem/shm_mem.c:242]: shm_mem_destroy
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core>
[mem/shm_mem.c:245]: destroying the shared memory lock
Nov 28 12:24:24 flowadmin /usr/local/sbin/kamailio[19567]: DEBUG: <core>
[main.c:804]: terminating due to SIGCHLD
Hello,
is anyone using the modules_s/eval module?
In the context of merging modules_s/* to modules/*, this one lacks the
docbook xml files for readme. It has a text readme file, from where I
understand it does script operations using a stack and polish notation
expressions.
Probably it was developed before the expressions support in config file
language, at this moment all its operations can be done directly by the
interpreter.
I am considering moving the module to obsolete/ folder. If anyone is
using it and wants to keep it in modules/*, then he/she has to convert
the readme text into docbook format (which is not complex at all, just
takes a bit of time, probably like 60 min or even less).
If there is no answer in one week about usage, will be sent to
obsolete/, from where it can be rescued in case of need (just to be
clear for everybody that code is not lost).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi All,
I am experiencing an issue when i try to contact xy(a)cisco.com.
I found that kamailio/sip-router can't resolve by default resolving way
a TCP + SRV records from domain cisco.com.
e.g. cisco.com
misi@alma:~$ host -t NAPTR cisco.comcisco.com has no NAPTR record
misi@alma:~$ host -t SRV _sip._udp.cisco.com
Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
misi@alma:~$ host -t SRV _sip._tcp.cisco.com_sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
misi@alma:~$ host -t SRV _sips._tcp.cisco.com_sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
I can't call xy(a)cisco.com because it does not exists an NAPTR record in
domain cisco.com,
and furthermore no SRV with udp.
But it exists sip+tcp record
and also exists an secure sip SRV, so sips+tcp record!
I read rfc3263
I find kamailio dns resolver is not working as it should according RFC3263.
http://tools.ietf.org/html/rfc3263
_If no NAPTR records are found, the client constructs SRV queries
for those transport protocols it supports, and does a query for each._
So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
Can anyone help/guide me to create a fix to this issue?
My plan is to create a patch to kamailio resolver, to correct and behave
according RFC3263.
Any help or guidance appreciated!
Thanks,
Misi
when i t_relay in-dialog bye:
Request-Line: BYE sip:0x8eb94d0@[2002:c062:660a::1]:5050;transport=tcp SIP/2.0
Message Header
Via: SIP/2.0/TCP [2002:C062:660A:0:0:0:0:1];branch=z9hG4bKde53.6aaed77ea908953bbb133e5021d74036.0
Via: SIP/2.0/UDP [::1]:5090;received=0:0:0:0:0:0:0:1;branch=z9hG4bKq~ouJaGs;rport=5090
From: <sip:jh@as.test.fi>;tag=5A29C828-50BEFE55000C7118-B4FF9B70
To: "" <sip:test@test.fi>;tag=92e26ffbfbc16e53
CSeq: 10 BYE
Call-ID: 28d1e4872cc5f83e
User-Agent: Sip Express Media Server (1.6.0 (x86/linux))
Max-Forwards: 69
Content-Length: 0
with $du set to sip:[2002:C062:660A:0:0:0:0:1]:59933;transport=tcp,
i get to syslog:
Dec 5 09:53:48 sip /usr/sbin/sip-proxy[1947]: INFO: <core> [resolve.c:729]: invalid domain name '[2002:C062:660A:0:0:0:0:1]'
since everything is and works as expected, why is the info message
produced and how can i get rid of it?
-- juha
any idea what could be the cause for lots of these kind syslog messages:
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: : <core>
[pass_fd.c:293]: ERROR: receive_fd: EOF on 56
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core>
[io_wait.h:628]: ERROR: io_watch_del: trying to delete already erased
entry 56 in the hash(-1, 0, 0xb2f28adc) flags 0)
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core>
[io_wait.h:628]: ERROR: io_watch_del: trying to delete already erased
entry 59 in the hash(-1, 0, 0xb725a9d8) flags 0)
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: : <core>
[pass_fd.c:209]: ERROR: send_fd: sendmsg failed sending 58 on 59:
Broken pipe (32)
Dec 3 23:11:36 sip2 /usr/sbin/sip-proxy[5490]: ERROR: <core>
[tcp_main.c:4003]: ERROR: send2child: send_fd failed for 0xb3024a48
(flags 0x4018), fd 58
-- juha
Hello,
My setup includes a cellphone that uses Wi-Fi to hookup to the internet
with IP 192.168.1.101. Cellphone app, tries to register with VOIPSwitch
through an outbound proxy server(Kamailio + rtpproxy), which rewrites SDP
to force rtp through an rtpproxy.
I can make a call from the cellphone to a PSTN number. When the PSTN
endpoint hangs up, VOIPSwitch relays a BYE message to the proxy that looks
like :
No. Time Source Destination Protocol Info
27 18.383929 IPaddr_VoipSwitch IPaddr_proxy SIP
Request: BYE sip:1234@IPaddr_VoipSwitch
Frame 27 (420 bytes on wire, 420 bytes captured)
Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst:
Supermic_bd:b9:bc (00:30:48:bd:b9:bc)
Internet Protocol, Src: IPaddr_VoipSwitch , Dst: IPaddr_proxy
User Datagram Protocol, Src Port: sip (5060), Dst Port: 7160 (7160)
Session Initiation Protocol
Request-Line: BYE sip:1234@IPaddr_VoipSwitch SIP/2.0
Method: BYE
[Resent Packet: False]
Message Header
Route: <sip:IPaddr_proxy:7160;lr=on;nat=yes>
CSeq: 1 BYE
Via: SIP/2.0/UDP IPaddr_VoipSwitch:5060;
branch=z9hG4bk180242100434182912333954
From: sip:5678@IPaddr_VoipSwitch;tag=18024210041929123187506289
Call-ID: LUOyIDm-ecy36NcUfj5G3v1lM6g5snkM
To: "1234"
<sip:1234@IPaddr_VoipSwitch>;tag=9XHJmiuf58vTrF7.vwflEK-G63JVPQSi
Content-Length: 0
The request URI in the above message is the IP address of VOIPSwitch
itself, which causes the proxy to forward the BYE message back to
VOIPSwitch. The cellphone never receives the BYE message and consequently
never hangs up.
Any suggestions on how i can get around this problem ?
Thanks and Regards,
Vikram.
