<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 28/08/14 14:45, Olle E. Johansson
wrote:<br>
</div>
<blockquote cite="mid:2D54E219-7F40-4915-82EC-536EF6A810D4@edvina.net" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <<a moz-do-not-send="true" href="mailto:ovoshlook@gmail.com">ovoshlook@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<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><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><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
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.<br></div></blockquote><div><br></div>/O<br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
Cheers,<br>
Daniel<br>
<br>
<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>
</div>
_______________________________________________<br>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br><a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br></blockquote></div><br></body></html>