12 Mar
2019
12 Mar
'19
10:06 a.m.
Dear Kamailio mailing list
I've a problem with a simple Kamailio-Asterisk setup. I tried to find a solution and
found several posts, but was not able to fix my problem!
I'm using the following setup:
- SIP device registered to Kamailio (IP 10.40.6.188)
- Kamailio (port 5070) and Asterisk (port 5060) on the same host (IP 10.40.8.104)
- I tried to forward calls from Kamailio to Asterisk with with standard PSTN call routing
and dispatcher module, but the result was the same
- Asterisk has a trunk to Kamailio
- SIP device registered to Asterisk (IP 10.40.6.214)
Calls from the Asterisk phone towards the Kamailio phone work without any issue.
Calls from the Kamailio phone towards the Asterisk phone are successfully established and
the voice works in both directions. The problem here is, that the Kamailio phone sends an
ACK upon 200 OK, but the ACK is not forwarded to Asterisk. After 6 seconds, the call is
terminated.
If I remove record_route() or add a second IP to the same interface for Asterisk
(10.40.8.106), then the call signaling works without any issue.
Does anyone have an idea what I'm doing wrong here?
I'm using more or less a standard Kamailio config file without rtpproxy. Please let me
know if I shall post the full config or just some relevant snippets.
Best regards
Mathias
Following are two snippets of the relevant ACK. The first shows the situation where the
ACK was not forwarded to Asterisk and the second with a different IP for Asterisk works.
No. Time Source Destination Protocol Length Info
752 17.269019 10.40.8.104 10.40.8.104 SIP/SDP 1135 Status:
200 OK |
Frame 752: 1135 bytes on wire (9080 bits), 1135 bytes captured (9080 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 304]
[Response Time (ms): 2093]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.48918e0ef9372ba1a38655eb93742e46.0;received=10.40.8.104
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
764 17.270668 10.40.8.104 10.40.6.188 SIP/SDP 1025 Status:
200 OK |
Frame 764: 1025 bytes on wire (8200 bits), 1025 bytes captured (8200 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 56960
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2115]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
786 17.402987 10.40.6.188 10.40.8.104 SIP 486
Request: ACK sip:004112345@10.40.8.104:5060 |
Frame 786: 486 bytes on wire (3888 bits), 486 bytes captured (3888 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 56960, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK sip:004112345@10.40.8.104:5060 SIP/2.0
Method: ACK
Request-URI: sip:004112345@10.40.8.104:5060
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2247]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;rport;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 70
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
Content-Length: 0
No. Time Source Destination Protocol Length Info
787 17.404480 10.40.8.104 10.40.8.104 SIP 561
Request: ACK sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
|
Frame 787: 561 bytes on wire (4488 bits), 561 bytes captured (4488 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5070, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61 SIP/2.0
Method: ACK
Request-URI:
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.f914ac9def098ece9a50d53389574f85.0
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 69
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Content-Length: 0
In this case I used a second IP on the same interface for Asterisk and this call works
without any issue:
No. Time Source Destination Protocol Length Info
939 8.849431 10.40.8.106 10.40.6.214 SIP 473
Request: ACK sip:004112345@10.40.6.214:49316;ob |
Frame 939: 473 bytes on wire (3784 bits), 473 bytes captured (3784 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.6.214
User Datagram Protocol, Src Port: 5060, Dst Port: 49316
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
946 8.850293 10.40.8.106 10.40.8.104 SIP/SDP 1136 Status:
200 OK |
Frame 946: 1136 bytes on wire (9088 bits), 1136 bytes captured (9088 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
956 8.851703 10.40.8.104 10.40.6.188 SIP/SDP 1026 Status:
200 OK |
Frame 956: 1026 bytes on wire (8208 bits), 1026 bytes captured (8208 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 60223
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
989 9.095859 10.40.6.188 10.40.8.104 SIP 485
Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 989: 485 bytes on wire (3880 bits), 485 bytes captured (3880 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 60223, Dst Port: 5070
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
991 9.097228 10.40.8.104 10.40.8.106 SIP 516
Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 991: 516 bytes on wire (4128 bits), 516 bytes captured (4128 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.106
User Datagram Protocol, Src Port: 5070, Dst Port: 5060
Session Initiation Protocol (ACK)
12 Mar
12 Mar
10:48 a.m.
New subject: ACK not forwarding to Asterisk
Hello,
It is hard to understand with these logs but it looks like loose_route issiue.
in WITHINDLG route (sample script) there is a loose_route function that function set
route header uri to Request uri if it is related with kamailio as shown below logs. so ,
kamailio send ACK message to itself that shown at second.
it is specified in RFC 3261
<https://tools.ietf.org/html/rfc3515>
https://tools.ietf.org/html/rfc3261#section-16.12
Best Regards
Yasin CANER.
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 56960, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK sip:004112345@10.40.8.104:5060 SIP/2.0
Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5070, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61 SIP/2.0
________________________________
From: sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of Schneuwly Mathias
RUAG <Mathias.Schneuwly(a)ruag.com>
Sent: Tuesday, March 12, 2019 10:06 AM
To: sr-users(a)lists.kamailio.org
Subject: Re: [SR-Users] ACK not forwarding to Asterisk
Dear Kamailio mailing list
I've a problem with a simple Kamailio-Asterisk setup. I tried to find a solution and
found several posts, but was not able to fix my problem!
I'm using the following setup:
- SIP device registered to Kamailio (IP 10.40.6.188)
- Kamailio (port 5070) and Asterisk (port 5060) on the same host (IP 10.40.8.104)
- I tried to forward calls from Kamailio to Asterisk with with standard PSTN call routing
and dispatcher module, but the result was the same
- Asterisk has a trunk to Kamailio
- SIP device registered to Asterisk (IP 10.40.6.214)
Calls from the Asterisk phone towards the Kamailio phone work without any issue.
Calls from the Kamailio phone towards the Asterisk phone are successfully established and
the voice works in both directions. The problem here is, that the Kamailio phone sends an
ACK upon 200 OK, but the ACK is not forwarded to Asterisk. After 6 seconds, the call is
terminated.
If I remove record_route() or add a second IP to the same interface for Asterisk
(10.40.8.106), then the call signaling works without any issue.
Does anyone have an idea what I'm doing wrong here?
I'm using more or less a standard Kamailio config file without rtpproxy. Please let me
know if I shall post the full config or just some relevant snippets.
Best regards
Mathias
Following are two snippets of the relevant ACK. The first shows the situation where the
ACK was not forwarded to Asterisk and the second with a different IP for Asterisk works.
No. Time Source Destination Protocol Length Info
752 17.269019 10.40.8.104 10.40.8.104 SIP/SDP 1135 Status:
200 OK |
Frame 752: 1135 bytes on wire (9080 bits), 1135 bytes captured (9080 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 304]
[Response Time (ms): 2093]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.48918e0ef9372ba1a38655eb93742e46.0;received=10.40.8.104
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
764 17.270668 10.40.8.104 10.40.6.188 SIP/SDP 1025 Status:
200 OK |
Frame 764: 1025 bytes on wire (8200 bits), 1025 bytes captured (8200 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 56960
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2115]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
786 17.402987 10.40.6.188 10.40.8.104 SIP 486
Request: ACK sip:004112345@10.40.8.104:5060 |
Frame 786: 486 bytes on wire (3888 bits), 486 bytes captured (3888 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 56960, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK sip:004112345@10.40.8.104:5060 SIP/2.0
Method: ACK
Request-URI: sip:004112345@10.40.8.104:5060
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2247]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;rport;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 70
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
Content-Length: 0
No. Time Source Destination Protocol Length Info
787 17.404480 10.40.8.104 10.40.8.104 SIP 561
Request: ACK sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
|
Frame 787: 561 bytes on wire (4488 bits), 561 bytes captured (4488 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5070, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61 SIP/2.0
Method: ACK
Request-URI:
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.f914ac9def098ece9a50d53389574f85.0
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 69
From: <sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Content-Length: 0
In this case I used a second IP on the same interface for Asterisk and this call works
without any issue:
No. Time Source Destination Protocol Length Info
939 8.849431 10.40.8.106 10.40.6.214 SIP 473
Request: ACK sip:004112345@10.40.6.214:49316;ob |
Frame 939: 473 bytes on wire (3784 bits), 473 bytes captured (3784 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.6.214
User Datagram Protocol, Src Port: 5060, Dst Port: 49316
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
946 8.850293 10.40.8.106 10.40.8.104 SIP/SDP 1136 Status:
200 OK |
Frame 946: 1136 bytes on wire (9088 bits), 1136 bytes captured (9088 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
956 8.851703 10.40.8.104 10.40.6.188 SIP/SDP 1026 Status:
200 OK |
Frame 956: 1026 bytes on wire (8208 bits), 1026 bytes captured (8208 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 60223
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
989 9.095859 10.40.6.188 10.40.8.104 SIP 485
Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 989: 485 bytes on wire (3880 bits), 485 bytes captured (3880 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 60223, Dst Port: 5070
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
991 9.097228 10.40.8.104 10.40.8.106 SIP 516
Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 991: 516 bytes on wire (4128 bits), 516 bytes captured (4128 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.106
User Datagram Protocol, Src Port: 5070, Dst Port: 5060
Session Initiation Protocol (ACK)
12:59 p.m.
New subject: ACK not forwarding to Asterisk
Hi Mathias,
I am new to this and have been playing about with Kamailio & Asterisk. I
also use the dispatcher to send calls to Asterisk from Kamailio. I am
not seeing exactly what you are doing, but what I have done is 2 things:
1. In the "auth" part of Kamailio, I have used IP address to detect
messages coming FROM Asterisk, as I am trusting calls from these nodes
and they are isolated from external injection etc. If they arrive from
Asterisk I use a 'flag' to mark the call (as all calls coming from my
Asterisk were generally sent there by Kamailio in the first place).
2. Also, when I send then to Asterisk I add extra info in the "Route",
such as 'media=yes;' (I call my Asterisk boxes as media handlers)
In my 'withindlg' script, I can then do things like:
if($(hdr(Route){param.value,media}) == "yes") {
route(MEDIA);
} else {
route(RELAY);
}
exit;
This is just a small part, but maybe that principle may be of some help?
Steve
On 12/03/2019 07:48, YASIN CANER wrote:
Hello,
It is hard to understand with these logs but it looks like loose_route
issiue.
in WITHINDLG route (sample script) there is a loose_route function
that function set route header uri to Request uri if it is related
with kamailio as shown below logs. so , kamailio send ACK message to
itself that shown at second.
it is specified in RFC 3261
https://tools.ietf.org/html/rfc3261#section-16.12
Best Regards
Yasin CANER.
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 56960, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK sip:004112345@10.40.8.104:5060 SIP/2.0
Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: _5070_, Dst Port: _5070_
Session Initiation Protocol (ACK)
Request-Line: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
SIP/2.0
------------------------------------------------------------------------
*From:* sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of
Schneuwly Mathias RUAG <Mathias.Schneuwly(a)ruag.com>
*Sent:* Tuesday, March 12, 2019 10:06 AM
*To:* sr-users(a)lists.kamailio.org
*Subject:* Re: [SR-Users] ACK not forwarding to Asterisk
Dear Kamailio mailing list
I've a problem with a simple Kamailio-Asterisk setup. I tried to find
a solution and found several posts, but was not able to fix my problem!
I'm using the following setup:
- SIP device registered to Kamailio (IP 10.40.6.188)
- Kamailio (port 5070) and Asterisk (port 5060) on the same host (IP
10.40.8.104)
- I tried to forward calls from Kamailio to Asterisk with with
standard PSTN call routing and dispatcher module, but the result was
the same
- Asterisk has a trunk to Kamailio
- SIP device registered to Asterisk (IP 10.40.6.214)
Calls from the Asterisk phone towards the Kamailio phone work without
any issue.
Calls from the Kamailio phone towards the Asterisk phone are
successfully established and the voice works in both directions. The
problem here is, that the Kamailio phone sends an ACK upon 200 OK, but
the ACK is not forwarded to Asterisk. After 6 seconds, the call is
terminated.
If I remove record_route() or add a second IP to the same interface
for Asterisk (10.40.8.106), then the call signaling works without any
issue.
Does anyone have an idea what I'm doing wrong here?
I'm using more or less a standard Kamailio config file without
rtpproxy. Please let me know if I shall post the full config or just
some relevant snippets.
Best regards
Mathias
Following are two snippets of the relevant ACK. The first shows the
situation where the ACK was not forwarded to Asterisk and the second
with a different IP for Asterisk works.
No. Time Source Destination Protocol Length Info
752 17.269019 10.40.8.104 10.40.8.104 SIP/SDP
1135 Status: 200 OK |
Frame 752: 1135 bytes on wire (9080 bits), 1135 bytes captured (9080 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 304]
[Response Time (ms): 2093]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.48918e0ef9372ba1a38655eb93742e46.0;received=10.40.8.104
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From:
<sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
764 17.270668 10.40.8.104 10.40.6.188 SIP/SDP
1025 Status: 200 OK |
Frame 764: 1025 bytes on wire (8200 bits), 1025 bytes captured (8200 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 56960
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2115]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjVtFCvs26liH-aJoGn8CaLg4kWqml5LH.
Record-Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
From:
<sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 INVITE
Server: Asterisk PBX 12.3.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:004112345@10.40.8.104:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 271
Message Body
No. Time Source Destination Protocol Length Info
786 17.402987 10.40.6.188 10.40.8.104 SIP
486 Request: ACK sip:004112345@10.40.8.104:5060 |
Frame 786: 486 bytes on wire (3888 bits), 486 bytes captured (3888 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 56960, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK sip:004112345@10.40.8.104:5060 SIP/2.0
Method: ACK
Request-URI: sip:004112345@10.40.8.104:5060
[Resent Packet: False]
[Request Frame: 259]
[Response Time (ms): 2247]
Message Header
Via: SIP/2.0/UDP
10.40.6.188:56960;rport;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 70
From:
<sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Route:
<sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61>
Content-Length: 0
No. Time Source Destination Protocol Length Info
787 17.404480 10.40.8.104 10.40.8.104 SIP
561 Request: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
|
Frame 787: 561 bytes on wire (4488 bits), 561 bytes captured (4488 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5070, Dst Port: 5070
Session Initiation Protocol (ACK)
Request-Line: ACK
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
SIP/2.0
Method: ACK
Request-URI:
sip:10.40.8.104:5070;lr;ftag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC;did=17a.4f61
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP
10.40.8.104:5070;branch=z9hG4bKda4f.f914ac9def098ece9a50d53389574f85.0
Via: SIP/2.0/UDP
10.40.6.188:56960;received=10.40.6.188;rport=56960;branch=z9hG4bKPjM2GQWjVep2XhpLxJD-cxNh75Qtep-sN3
Max-Forwards: 69
From:
<sip:proxydevice@10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
To: <sip:004112345@10.40.8.104>;tag=as5e5c287c
Call-ID: a6T0GAwBL69m5gsc215EgXi61Oorwxik
CSeq: 10909 ACK
Content-Length: 0
In this case I used a second IP on the same interface for Asterisk and
this call works without any issue:
No. Time Source Destination Protocol Length Info
939 8.849431 10.40.8.106 10.40.6.214 SIP
473 Request: ACK sip:004112345@10.40.6.214:49316;ob |
Frame 939: 473 bytes on wire (3784 bits), 473 bytes captured (3784 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.6.214
User Datagram Protocol, Src Port: 5060, Dst Port: 49316
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
946 8.850293 10.40.8.106 10.40.8.104 SIP/SDP
1136 Status: 200 OK |
Frame 946: 1136 bytes on wire (9088 bits), 1136 bytes captured (9088 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.106, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
956 8.851703 10.40.8.104 10.40.6.188 SIP/SDP
1026 Status: 200 OK |
Frame 956: 1026 bytes on wire (8208 bits), 1026 bytes captured (8208 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.6.188
User Datagram Protocol, Src Port: 5070, Dst Port: 60223
Session Initiation Protocol (200)
No. Time Source Destination Protocol Length Info
989 9.095859 10.40.6.188 10.40.8.104 SIP
485 Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 989: 485 bytes on wire (3880 bits), 485 bytes captured (3880 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.6.188, Dst: 10.40.8.104
User Datagram Protocol, Src Port: 60223, Dst Port: 5070
Session Initiation Protocol (ACK)
No. Time Source Destination Protocol Length Info
991 9.097228 10.40.8.104 10.40.8.106 SIP
516 Request: ACK sip:004112345@10.40.8.106:5060 |
Frame 991: 516 bytes on wire (4128 bits), 516 bytes captured (4128 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.40.8.104, Dst: 10.40.8.106
User Datagram Protocol, Src Port: 5070, Dst Port: 5060
Session Initiation Protocol (ACK)
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2082
days inactive
2082
days old
2 comments
3 participants
participants (3)
-
Schneuwly Mathias RUAG -
Steve Bucklin -
YASIN CANER