28 Aug
2014
28 Aug
'14
9:27 a.m.
On 28/08/14 15:11, Olle E. Johansson wrote:
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://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
On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>> wrote:
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.
On 28/08/14 14:45, Olle E. Johansson wrote:
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.
On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <ovoshlook(a)gmail.com
<mailto:ovoshlook@gmail.com>> wrote:
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. 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.
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?