[SR-Users] Wrong ACK to Provider

Daniel-Constantin Mierla miconda at gmail.com
Fri Aug 29 09:36:52 CEST 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140829/6c6a8824/attachment.html>


More information about the sr-users mailing list