[SR-Users] ACK not forwarding to Asterisk
Steve Bucklin
steve at telcoelectronics.uk
Tue Mar 12 10:59:45 CET 2019
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 at 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 at lists.kamailio.org> on behalf of
> Schneuwly Mathias RUAG <Mathias.Schneuwly at ruag.com>
> *Sent:* Tuesday, March 12, 2019 10:06 AM
> *To:* sr-users at 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 at 10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
> To: <sip:004112345 at 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 at 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 at 10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
> To: <sip:004112345 at 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 at 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 at 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 at 10.40.8.104:5060 SIP/2.0
> Method: ACK
> Request-URI: sip:004112345 at 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 at 10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
> To: <sip:004112345 at 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 at 10.40.8.104>;tag=NCP2N5E7OZuppblpkCCNZziEmpiTRsQC
> To: <sip:004112345 at 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 at 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 at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190312/07082c55/attachment.html>
More information about the sr-users
mailing list