[SR-Users] Wrong ACK to Provider

[Yuriy Gorlichenko]

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>:

>
> On 28/08/14 15:11, Olle E. Johansson wrote:
>
>
>  On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <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> 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 Mierlahttp://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
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140829/149a9b20/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mydump1.pcap
Type: application/octet-stream
Size: 59548 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140829/149a9b20/attachment.obj>