On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 28/08/14 14:45, Olle E. Johansson wrote:
On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <ovoshlook(a)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.
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?
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.
/O
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users