On 04 Feb 2014, at 11:46, Alex Balashov wrote:
> I would like to report a bug: the transactional layer in chan_sip does not
> exist. :-)
Too late, chan_pjsip has an external transaction layer. Bug closed.
/O
>
>
> "Olle E. Johansson" wrote:
>>
>> On 04 Feb 2014, at 10:43, Klaus Darilion
I would like to report a bug: the transactional layer in chan_sip does not
exist. :-)
"Olle E. Johansson" wrote:
>
>On 04 Feb 2014, at 10:43, Klaus Darilion
>wrote:
>
>> Asterisk's transcation layer is quite buggy - so it may also be that
>the reINVITE with Cseq 103 is a retransmission of a p
On 04 Feb 2014, at 10:43, Klaus Darilion wrote:
> Asterisk's transcation layer is quite buggy - so it may also be that the
> reINVITE with Cseq 103 is a retransmission of a previous transaction (which
> was not stopped correctly).
>
You are wrong. The transaction layer in chan_sip is NOT bugg
Asterisk's transcation layer is quite buggy - so it may also be that the
reINVITE with Cseq 103 is a retransmission of a previous transaction
(which was not stopped correctly).
regards
Klaus
On 04.02.2014 08:52, dotnetdub wrote:
Hi Olle,
Just a quick update..
I've gone through this in detai
On 04 Feb 2014, at 08:52, dotnetdub wrote:
> Hi Olle,
>
> Just a quick update..
>
> I've gone through this in detail and the issue is actually that
> asterisk sends an UPDATE with CSeq: 104 UPDATE
>
> and when FS respond OK asterisk then sends its REINVITE with CSeq: 103 INVITE
>
> As far a
Hi Olle,
Just a quick update..
I've gone through this in detail and the issue is actually that
asterisk sends an UPDATE with CSeq: 104 UPDATE
and when FS respond OK asterisk then sends its REINVITE with CSeq: 103 INVITE
As far as I can tell Freeswitch at this point is perfectly within its
righ
Hi Olle
I will grab traces later on and report on the FS JIRA.
Thanks
Brian
On 31 January 2014 08:17, Olle E. Johansson wrote:
>
> On 30 Jan 2014, at 23:23, dotnetdub wrote:
>
>> Hi David,
>>
>> Sorry to drag up a very old thread - we are seeing this also with
>> asterisk kamailio and FS and
On 30 Jan 2014, at 23:23, dotnetdub wrote:
> Hi David,
>
> Sorry to drag up a very old thread - we are seeing this also with
> asterisk kamailio and FS and I have tried lots of different
> combinations on both asterisk and FS to make it go away without
> success.. Did you ever come up with some
Maybe adding a "Retry-After" header to the 500 might help.
Regards,
Ovidiu Sas
On Mon, Jun 3, 2013 at 8:20 PM, Klaus Darilion
wrote:
> This is a known problem without simple solution. It can also happen if the
> ACK gets lost somewhere.
>
> The proper solution is to fix Freeswitch. The reINVITE
Hi David,
Sorry to drag up a very old thread - we are seeing this also with
asterisk kamailio and FS and I have tried lots of different
combinations on both asterisk and FS to make it go away without
success.. Did you ever come up with something better than the usleep ?
Many Thanks
On 3 June
This is a known problem without simple solution. It can also happen if
the ACK gets lost somewhere.
The proper solution is to fix Freeswitch. The reINVITE is an implicit
ACK (as there wouldn't be a reINVITE if there wouldn't have been an
ACK). Thus, FS should accept the reINVITE and implicitly
Hello all,
So I have three machines, we don't care about audio for this problem, so
everything I mention here is SIP related.
Freeswitch <--> Kamailio 3.3.2 <--> Asterisk
1. Asterisk sends an INVITE to Freeswitch through the Kamailio proxy.
2. Kamailio replies 100 Trying and forwards to Frees
12 matches
Mail list logo
