[SR-Users] Kamailio ignores some ACK

Jason Penton jason.penton at smilecoms.com
Thu May 10 09:15:08 CEST 2012


Actually, sorry I misread your capture - it is using the same address so
doubt it the problem of interfaces......

Are you are not getting any logging in debug when the ACK comes in?

On Thu, May 10, 2012 at 9:08 AM, Jason Penton <jason.penton at smilecoms.com>wrote:

> Hey Mino,
>
> From your packet captures above it looks like your ACK is coming in
> another IP address. I also see that you are doing the packet capture across
> all your physical interfaces (-i any). Perhaps your Kamailio is only
> configured to listen on the one interface (the one *not* getting the ACK).
>
> To test limit your packet capture to only the interface/s that you know
> Kamailio is listening on.
>
> Cheers
> Jason
>
>
> On Thu, May 10, 2012 at 8:59 AM, Mino Haluz <mino.haluz at gmail.com> wrote:
>
>> We are troubleshooting this issue almost for 2 days and we did not find
>> the solution yet. The thing is, that it does not enter even the config file
>> (we have some debug messages at the start, that do not show). Otherwise we
>> do not have any problem with ACK, but only this particular ACK is not
>> forwarded... Was there some bug related to parsing in 3.1.0 which would not
>> print any error to syslog?
>>
>> On Wed, May 9, 2012 at 4:41 PM, Jason Penton <jason.penton at smilecoms.com>wrote:
>>
>>> Seems like a loose routing issue. Are you loose routing in your config
>>> file?
>>>
>>>
>>> On Wed, May 9, 2012 at 4:34 PM, Stoyan Mihaylov <
>>> stoyan.v.mihaylov at gmail.com> wrote:
>>>
>>>> You can use something like wireshark on Kamailio server to see if ACK
>>>> packets go in right direction.
>>>> I had problem with ACK and BYE, and I saw that in some cases ACK and
>>>> BYE packets looped back in kamailio.
>>>> May be I used wrong client.
>>>>
>>>>
>>>> On Wed, May 9, 2012 at 5:15 PM, Efelin Novak <efelin.novak at gmail.com>wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> I have a strange problem when Kamailio ignores ACKs in a specific
>>>>> scenario. The call flow is as follows:
>>>>>
>>>>> A -> INVITE -> kamailio -> INVITE -> B
>>>>> [omitting 100 and 180]
>>>>> A <- 200 OK <- kamailio <- 200 OK <- B
>>>>> A -> ACK -> kamailio
>>>>>
>>>>> There are INVITE Xlogs, Reply ROUTE xlogs and media-proxy logs in the
>>>>> syslog. However there is no information about these ACKs. No XLOGs are
>>>>> printed even if there is one on the top of the main route.
>>>>>
>>>>> "tcpdump -A -s0 -i any -n port 5060" receives this message correctly:
>>>>>
>>>>> 14:47:01.246153 IP 111.111.11.11.5060 > 80.80.80.80.60442: SIP,
>>>>> length: 915
>>>>> SIP/2.0 200 OK
>>>>> Via: SIP/2.0/UDP
>>>>> 111.111.11.11:5060
>>>>> ;rport=60442;x-route-tag="tgrp:A";branch=z9hG4bK1634E6A88
>>>>> Record-Route:
>>>>> <sip:111.111.11.11;lr;ftag=599248D4-260;vsf=AAAAAAAAAAAAAAAAAAAAW0FVT0ZWHF1aNy4xGzA-;nat=yes;did=3bb.327c47e6>
>>>>> Contact: <sip:80.80.80.80:65002;transport=udp>
>>>>> To: "test_account"<sip:bob at server.com>;tag=cb7dd641
>>>>> From: <sip:alice at 111.111.11.50>;tag=599248D4-260
>>>>> Call-ID: 9AFCFC51.11.50
>>>>> CSeq: 101 INVITE
>>>>> Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO,
>>>>> SUBSCRIBE, UPDATE
>>>>> Content-Type: application/sdp
>>>>> Content-Length:263
>>>>>
>>>>> v=0
>>>>> o=- 492575093 492575093 IN IP4 111.111.11.60
>>>>> s=test_device
>>>>> i=(o=IN IP4 192.168.1.10)
>>>>> c=IN IP4 111.111.11.71
>>>>> t=0 0
>>>>> m=audio 16416 RTP/AVP 18 101
>>>>> a=rtpmap:18 G729/8000
>>>>> a=fmtp:18 annexb=no
>>>>> a=rtpmap:101 telephone-event/8000
>>>>> a=fmtp:101 0-15
>>>>> a=ptime:20
>>>>>
>>>>> 14:47:01.254511 IP 111.111.11.50.60442 > 111.111.11.11.5060: SIP,
>>>>> length: 521
>>>>> ACK sip:80.80.80.80:65002;transport=udp SIP/2.0
>>>>> Via: SIP/2.0/UDP
>>>>> 111.111.11.50:5060;x-route-tag="tgrp:A";branch=z9hG4bK1634E7DE8
>>>>> From: <sip:alice at 111.111.11.50>;tag=599248D4-260
>>>>> To: "test_account"<sip:bob at server.com>;tag=cb7dd641
>>>>> Call-ID: 9AFCFC51.11.50
>>>>> Route:
>>>>> <sip:111.111.11.11;lr;ftag=599248D4-260;vsf=AAAAAAAAAAAAAAAAAAAAW0FVT0ZWHF1aNy4xGzA-;nat=yes;did=3bb.327c47e6>
>>>>> Max-Forwards: 70
>>>>> CSeq: 101 ACK
>>>>> Content-Length: 0
>>>>>
>>>>> My Kamailio version is kamailio 3.1.0 (i386/linux) 1e204f.
>>>>> Does anybody knows where can be a problem?
>>>>> How can I check whether Kamailio receives something?
>>>>>
>>>>> ...
>>>>>
>>>>> Jan
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>> This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>

This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120510/d4363ed5/attachment-0001.htm>


More information about the sr-users mailing list