4 Feb
2014
4 Feb
'14
12:49 p.m.
On 04 Feb 2014, at 11:46, Alex Balashov <abalashov(a)evaristesys.com> 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" <oej(a)edvina.net> wrote:
On 04 Feb 2014, at 10:43, Klaus Darilion <klaus.mailinglists(a)pernau.at>
wrote:
You are wrong. The transaction layer in
chan_sip is NOT buggy. It
simply does not exist.
/O
> regards
> Klaus
> On 04.02.2014 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 as I can tell
Freeswitch at this point is perfectly within
its
>> rights to send a 500 as the CSEQ is out of order.
> >> Should I file a bug report on
the asterisk tracker to get this
fixed?
> >> Regards
>> Brian
> > > >> On 31
January 2014 08:17, Olle E. Johansson <oej(a)edvina.net> wrote:
>> >>> On 30 Jan 2014, at
23:23, dotnetdub <dotnetdub(a)gmail.com> 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 something better than the
usleep ?
>>> >>> If freeswitch
believes it already has an open INVITE transaction it
should
>>> Please check with the
FreeSwitch people and file a bug report so
that they
>>> /O
>>>> Many Thanks
>>> >>> >>> >>>
>>>> On 3 June 2013 20:23, David K
<kamailio.org(a)spam.lublink.net>
wrote:
>>>>> 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.
>>>>> So,
my problem is that Kamailio seems to process my re-INVITE
more quickly
>>>>> So my
"solution" is to add a usleep(20); for re-INVITEs on
Kamailio, but I
>>>>> think this is a lousy solution.
>>>> >>>>> Has
anyone here had to deal with problems where Kamailio routes a
re-INVITE
>>>>>
Thanks,
>>>> >>>>>
David
>>>> >>>> >>>> >>>>>
_______________________________________________
>>>>> 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
>>> >>>>
_______________________________________________
>>>> 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
>> >> >>> _______________________________________________
>>> 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
> >>
_______________________________________________
>> 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
> > _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully
fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
_______________________________________________
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 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).
>> not respond with 500, it should respond
with 491 request pending.
In that
>>> case Asterisk will back off and retry.
>> >> can fix this issue. That's the long
term solution, all the rest is
just quick and
>> dirty fixes. Seems like if this problem
is still around, no one
filed a bug report.
>> >>>> 2. Kamailio replies 100 Trying
and forwards to Freeswitch
>>>> 3. Freeswitch replies 100 Trying
>>>> 4. Freeswitch replies 180 Ringing to Kamailio
>>>> 5. Kamailio routes the answer to Asterisk
>>>> 6. Freeswitch replies 200 OK to Kamailio
>>>> 7. Kamailio replies 200 OK to Asterisk
>>>> 8. Asterisk replies ACK to Kamailio
>>>> 9. Asterisk sends a re-INVITE to Freeswitch through Kamailio
>>>> 10. Kamailio routes the re-INVITE to freeswitch
>>>> 11. Kamailio routes the ACK to freeswitch.
>>>> 12. Freeswitch replies 500 Server error because it got a
re-INVITE
before
>>>>> the ACK.
>>>> >>>> than the ACK. So Freeswitch
replies an error because it got the
re-INVITE
>>>>> before the ACK.
>>>> >>>> faster than an ACK causing
endpoints to return error messages?
Has anyone
>>>>> had to deal with a similar issue?
>>>> sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
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