<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The last .zip file is also showing only 3 packets (different ones)
-- can you check the trace has all the packet before you compress?
Maybe you can put it somewhere on a server for download and send me
the link, so I get it over http.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 29/08/14 09:36, Daniel-Constantin
Mierla wrote:<br>
</div>
<blockquote cite="mid:54002D94.7010803@gmail.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I had no time to look yet at the trace.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 29/08/14 07:08, Yuriy Gorlichenko
wrote:<br>
</div>
<blockquote
cite="mid:CABSP_VfUKhCS9H8SaT6ogF4cTDcuwDfp2ZoqKRA6jzJS_gji8A@mail.gmail.com"
type="cite">
<div dir="ltr">My pcap file. Daniel sorry for first time sended
message to your private mail. Was a mistake. </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-08-28 17:27 GMT+04:00
Daniel-Constantin Mierla <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:miconda@gmail.com"
target="_blank">miconda@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class=""> <br>
<div>On 28/08/14 15:11, Olle E. Johansson wrote:<br>
</div>
<blockquote type="cite"> <br>
<div>
<div>On 28 Aug 2014, at 14:57, Daniel-Constantin
Mierla <<a moz-do-not-send="true"
href="mailto:miconda@gmail.com"
target="_blank">miconda@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<div>On 28/08/14 14:45, Olle E. Johansson
wrote:<br>
</div>
<blockquote type="cite"> <br>
<div>
<div>On 28 Aug 2014, at 14:14, Yuriy
Gorlichenko <<a
moz-do-not-send="true"
href="mailto:ovoshlook@gmail.com"
target="_blank">ovoshlook@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Hello. I try to provide
call scheme:<br>
<br>
internal client -> asterisk ->
Kamailio -> provider -> external
endpoint call<br>
<br>
when I make call I see this:<br>
<br>
asterisk kamailio provider<br>
invite --> invite --> <br>
<--
407<br>
ACK -->
<br>
invite w/Auth
--><br>
<-- 100 <--
100<br>
<-- 180 <--
180
<div> <-- 183
<-- 183</div>
<div> <-- 200
<-- 200</div>
<div> ACK --> ACK --></div>
<div><br>
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.<br>
</div>
</div>
</blockquote>
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.</div>
<div>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.</div>
</blockquote>
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.<br>
</div>
</blockquote>
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. <br>
</div>
</blockquote>
</div>
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.<br>
<br>
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.
<div class=""><br>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The provider (having a plivo platform, based
on the responses) is running kamailio 4.1.2 in
front (looking at 100 trying).<br>
<br>
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.<br>
</div>
</blockquote>
Won't the second ACK on the same transaction just
be ignored, while it waits for an ACK on the new
transaction?<br>
</div>
</blockquote>
</div>
It is the same transaction in this case, just two
branches from kamailio downstream, which is serial
forking case, as mentioned above.
<div class=""><br>
<br>
Cheers,<br>
Daniel<br>
<br>
<pre cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</div>
</div>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list<br>
<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</body>
</html>