4 Aug
2015
4 Aug
'15
11:59 a.m.
Since switching to 4.2.5 (from 3.x) a customer has problems with a buggy user
agent (IMHO). What I am seeing now is:
provider kamailio customer
INVITE1->
INVITE1->
<-Trying
<-Trying
<-200 OK
<-200 OK
ACK1->
INVITE2->
INVITE2->
ACK1->
ACK1 arrives 0.007s before INVITE2, but INVITE2 is send 0.004s before ACK1. It
looks like this wasn't happening with Kamailio 3.x, it worked fine then
(apparently).
Can this reordering be (gracefully) prevented somehow (ignoring the fact that
during transport reordering can happen)? A Q&D hack looks to be just usleep
the reinvite a little.
The endpoint is essentially ignoring the reinvite before (and after) the ACK.
After a timeout INVITE2 is canceled and after that INVITE1 will be ended with
a BYE from provider.
kamailio-customer communication is UDP
provider-kamailio is tcp when message >= 1300b. INVITE1 is TCP, INVITE2 and
ACK1 are UDP.
4 Aug
4 Aug
3:12 p.m.
Hello,
hmmm, quite interesting that the ack takes longer, because invite is
typically larger and also in kamailio likely to be transaction
processing, while ack is just sent out stateless.
Anyhow, I can't remember any changes in ack processing that could add to
this. Are you doing accounting of ACK requests?
As of a solution, perhaps hash table comes handy again, filter on this
customer and then of the ack and 2nd invite are received in really short
time in between, then add some usleep() for invite, that should take the
cpu from the process handling it.
Cheers,
Daniel
On 04/08/15 11:59, Daniel Tryba wrote:
Since switching to 4.2.5 (from 3.x) a customer has
problems with a buggy user
agent (IMHO). What I am seeing now is:
provider kamailio customer
INVITE1->
INVITE1->
<-Trying
<-Trying
<-200 OK
<-200 OK
ACK1->
INVITE2->
INVITE2->
ACK1->
ACK1 arrives 0.007s before INVITE2, but INVITE2 is send 0.004s before ACK1. It
looks like this wasn't happening with Kamailio 3.x, it worked fine then
(apparently).
Can this reordering be (gracefully) prevented somehow (ignoring the fact that
during transport reordering can happen)? A Q&D hack looks to be just usleep
the reinvite a little.
The endpoint is essentially ignoring the reinvite before (and after) the ACK.
After a timeout INVITE2 is canceled and after that INVITE1 will be ended with
a BYE from provider.
kamailio-customer communication is UDP
provider-kamailio is tcp when message >= 1300b. INVITE1 is TCP, INVITE2 and
ACK1 are UDP.
_______________________________________________
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
4:41 p.m.
On Tuesday 04 August 2015 15:12:31 Daniel-Constantin Mierla wrote:
Anyhow, I can't remember any changes in ack
processing that could add to
this. Are you doing accounting of ACK requests?
Ehh, yes, accounting in mysql. That explains +/- 0.01 delay in routing the
ACK. I think the previously it was myisam with db_insert_mode set to 1.
I see there is now a 2 as value for db_insert_mode, to do this async. Sounds
like the solution.
As of a solution, perhaps hash table comes handy
again, filter on this
customer and then of the ack and 2nd invite are received in really short
time in between, then add some usleep() for invite, that should take the
cpu from the process handling it.
I'm just usleeping for 5ms on all INVITEs within dialog for now. I'll look
into the async inserting as the permanent solution.
Once again many thanks for your reply.
8:32 p.m.
On 04/08/15 16:41, Daniel Tryba wrote:
On Tuesday 04 August 2015 15:12:31 Daniel-Constantin
Mierla wrote:
You can set
the type of acc module to myisam -- we removed enforcing
myisam, leaving it to the default setting of mysql server, it is not
something like acc must not be myisam anymore.
Cheers,
Daniel
Anyhow, I can't remember any changes in ack
processing that could add to
this. Are you doing accounting of ACK requests?
Ehh, yes, accounting in mysql.
That explains +/- 0.01 delay in routing the
ACK. I think the previously it was myisam with db_insert_mode set to 1.
I see there is now a 2 as value for db_insert_mode, to do this async. Sounds
like the solution.
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
As of a solution, perhaps hash table comes handy
again, filter on this
customer and then of the ack and 2nd invite are received in really short
time in between, then add some usleep() for invite, that should take the
cpu from the process handling it.
I'm just usleeping for 5ms on all INVITEs
within dialog for now. I'll look
into the async inserting as the permanent solution.
Once again many thanks for your reply.
_______________________________________________
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
5 Aug
5 Aug
9:53 a.m.
On Tuesday 04 August 2015 20:32:56 Daniel-Constantin Mierla wrote:
You can set the type of acc module to myisam -- we
removed enforcing
myisam, leaving it to the default setting of mysql server, it is not
something like acc must not be myisam anymore.
The table is in a multimaster galera mysql cluster, myisam is not yet
supported.
4:19 p.m.
On 05/08/15 09:53, Daniel Tryba wrote:
On Tuesday 04 August 2015 20:32:56 Daniel-Constantin
Mierla wrote:
OK -- then yes, look at the async db operations for acc module.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
You can set the type of acc module to myisam --
we removed enforcing
myisam, leaving it to the default setting of mysql server, it is not
something like acc must not be myisam anymore.
The table is in a multimaster
galera mysql cluster, myisam is not yet
supported.
3209
days inactive
3210
days old
5 comments
2 participants
participants (2)
-
Daniel Tryba -
Daniel-Constantin Mierla