[SR-Users] Wrong ACK to Provider
Daniel-Constantin Mierla
miconda at gmail.com
Mon Sep 1 12:05:35 CEST 2014
How did you grab the pcap? All the variants (including the zip via http
download) are not recognized by ngrep or wireshark.
Anyhow, I looked with a text editor inside the and I could see that the
ACK is changing the r-uri -- it comes to kamailio with the contact from
200ok, but goes out with a different hostname. You have some rules in
kamailio.cfg that do that -- you should let the r-uri unchanged for ack
-- routing is done via record-routing.
Cheers,
Daniel
On 29/08/14 16:12, Daniel-Constantin Mierla wrote:
> The last .zip file is also showing only 3 packets (different ones) --
> can you check the trace has all the packet before you compress? Maybe
> you can put it somewhere on a server for download and send me the
> link, so I get it over http.
>
> Cheers,
> Daniel
>
> On 29/08/14 09:36, Daniel-Constantin Mierla wrote:
>> I don't mind to receive directly attachments that can contain
>> sensitive data. But you have to write an email via mailing list
>> saying you do/did so.
>>
>> With gmail I am checking mostly the emails that are filtered with
>> various rules, otherwise, the rest land together with a lot of
>> spam/advertising and check them very rarely, if ever.
>>
>> So, as a reminder to anyone that did it -- if a conversation from
>> mailing list was turned into a direct email to me only, it very
>> unlikely to get answered soon, given the load I have -- better resend
>> to mailing list.
>>
>> I had no time to look yet at the trace.
>>
>> Cheers,
>> Daniel
>>
>> On 29/08/14 07:08, Yuriy Gorlichenko wrote:
>>> My pcap file. Daniel sorry for first time sended message to your
>>> private mail. Was a mistake.
>>>
>>>
>>> 2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla
>>> <miconda at gmail.com <mailto:miconda at gmail.com>>:
>>>
>>>
>>> On 28/08/14 15:11, Olle E. Johansson wrote:
>>>>
>>>> On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla
>>>> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>>>
>>>>>
>>>>> On 28/08/14 14:45, Olle E. Johansson wrote:
>>>>>>
>>>>>> On 28 Aug 2014, at 14:14, Yuriy Gorlichenko
>>>>>> <ovoshlook at gmail.com <mailto:ovoshlook at gmail.com>> wrote:
>>>>>>
>>>>>>> Hello. I try to provide call scheme:
>>>>>>>
>>>>>>> internal client -> asterisk -> Kamailio -> provider ->
>>>>>>> external endpoint call
>>>>>>>
>>>>>>> when I make call I see this:
>>>>>>>
>>>>>>> asterisk kamailio provider
>>>>>>> invite --> invite -->
>>>>>>> <-- 407
>>>>>>> ACK -->
>>>>>>> invite w/Auth -->
>>>>>>> <-- 100 <-- 100
>>>>>>> <-- 180 <-- 180
>>>>>>> <-- 183 <-- 183
>>>>>>> <-- 200 <-- 200
>>>>>>> ACK --> ACK -->
>>>>>>>
>>>>>>> My problem with last ACK, that I send to provider. Provider
>>>>>>> ignores it, and sends me some OK packets. As resultI can
>>>>>>> notend session ( answer to BYE 481 - transaction does not
>>>>>>> exists). I think it is wrong ACK but can not undrtand where
>>>>>>> I do mistake.
>>>>>> Well, by letting the proxy handle authentication the INVITE
>>>>>> tranction i closed without Asterisk knowing about it. So the
>>>>>> ACK sent from the proxy and from Asterisk is for the same
>>>>>> transaction, which messes things up. Asterisk does not know
>>>>>> anything about the second invite. Letting the proxy handle
>>>>>> authentiction breaks the SIP protocol in bad ways and is
>>>>>> generally not a good solution.
>>>>>> You may want to send another response to asterisk when you
>>>>>> get the 407 so Asterisk retries and use the retry as a
>>>>>> trigger for the second INVITE and add auth to that.
>>>>> While breaking the cseq incrementation for authentication
>>>>> (mentioned in the readme of uac), the Asterisk seems to do ok
>>>>> here, because the ACK is coming from asterisk, but it is not
>>>>> accepted by the provider.
>>>> You are missing the fact that the ACK sent by Asterisk is
>>>> already sent by the proxy. The INVITE w/AUth have a different
>>>> cseq than the ACK.
>>> Kamailio is doing serial forking in this case, so the first ack
>>> is for the first branch that gets 407. This should be as usual
>>> for serial/parallel forking.
>>>
>>> Then, Kamailio is not increasing the cseq here -- that's the
>>> limitation with uac auth module, because the authenticator
>>> should normally reject it. But if it is authentication against
>>> another kamailio, should just work.
>>>
>>>
>>>>>
>>>>> The provider (having a plivo platform, based on the responses)
>>>>> is running kamailio 4.1.2 in front (looking at 100 trying).
>>>>>
>>>>> Authentication from kamailio to another kamailio using uac
>>>>> module should work fine, as kamailio doesn't act as end user
>>>>> UAC and doesn't care much of cseq.
>>>> Won't the second ACK on the same transaction just be ignored,
>>>> while it waits for an ACK on the new transaction?
>>> It is the same transaction in this case, just two branches from
>>> kamailio downstream, which is serial forking case, as mentioned
>>> above.
>>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
>>> Next Kamailio Advanced Trainings 2014 -http://www.asipto.com
>>> Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>> mailing list
>>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>> Next Kamailio Advanced Trainings 2014 -http://www.asipto.com
>> Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
> Next Kamailio Advanced Trainings 2014 -http://www.asipto.com
> Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140901/44557947/attachment.html>
More information about the sr-users
mailing list