[SR-Users] Wrong ACK to Provider

[Yuriy Gorlichenko]

All packets (INVITE,ACK,BYE) that comes from Asterisk and sends to Provider
handled by Kamailio (changed tU, fU and td and from d). so I write to PLIVO
this question, but they still answer to me  nothing... As I see my trace
there are no simple muistakes (such as wrong dst or wrong contact header).

AboutAsteirsk and Kamailio I think As Daniel that Auth is not Asterisk
problem.
Furthermore Asterisk works with kamailio without registration on kamailio:
ip-based dialog.

So Daniel - If you will have some time to see my trace I will be happy.

Thanks for answers and help.

I will thinkabout problem to and waiting answer.




2014-08-28 16:57 GMT+04:00 Daniel-Constantin Mierla <miconda at gmail.com>:

>
> 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.
>
> 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.
>
> I didn't have time to look at the sip trace properly, but Asterisk should
> have nothing to do with the problem here, unless I missed something from
> the description.
>
> 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/20140828/18468084/attachment.html>