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 <mico...@gmail.com>: > > On 28/08/14 15:11, Olle E. Johansson wrote: > > > On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <mico...@gmail.com> > wrote: > > > On 28/08/14 14:45, Olle E. Johansson wrote: > > > On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <ovoshl...@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >
mydump1.pcap
Description: Binary data
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
