[SR-Users] Wrong ACK to Provider
Daniel-Constantin Mierla
miconda at gmail.com
Fri Aug 29 16:12:58 CEST 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140829/06c3c3b0/attachment.html>
More information about the sr-users
mailing list