<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Apparently the file got corrupted, most probably by email
client/server encoding, and it shows only three packets.<br>
<br>
Can you resend it compress as tgz?<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 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>