28 Aug
2014
28 Aug
'14
3:11 p.m.
All packets (INVITE,ACK,BYE) that comes from Asterisk and sends to Provider
handled by Kamailio (changed tU, fU and td and from d). so I write to PLIVO
this question, but they still answer to me nothing... As I see my trace
there are no simple muistakes (such as wrong dst or wrong contact header).
AboutAsteirsk and Kamailio I think As Daniel that Auth is not Asterisk
problem.
Furthermore Asterisk works with kamailio without registration on kamailio:
ip-based dialog.
So Daniel - If you will have some time to see my trace I will be happy.
Thanks for answers and help.
I will thinkabout problem to and waiting answer.
2014-08-28 16:57 GMT+04:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
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.
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.
Cheers,
Daniel
--
Daniel-Constantin Mierlahttp://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