29 Aug
2014
29 Aug
'14
10:12 a.m.
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.
Cheers,
Daniel
On 29/08/14 09:36, Daniel-Constantin Mierla wrote:
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.
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.
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.
I had no time to look yet at the trace.
Cheers,
Daniel
On 29/08/14 07:08, Yuriy Gorlichenko wrote:
--
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
My pcap file. Daniel sorry for first time sended
message to your
private mail. Was a mistake.
2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
On 28/08/14 15:11, Olle E. Johansson wrote:
It is the same
transaction in this case, just two branches from
kamailio downstream, which is serial forking case, as mentioned
above.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/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 <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
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
On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
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.
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.
On 28/08/14 14:45, Olle E. Johansson wrote:
>
> On 28 Aug 2014, at 14:14, Yuriy Gorlichenko
> <ovoshlook(a)gmail.com <mailto:ovoshlook@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?