[SR-Users] SIP-I trunking
Hello, I'm planning to interconnect kamailio with a SIP-I provider (an i have no more information at this time from my telco). I read the documentation about the SIP-I module, who need to be completed to match our needs. basically, we need to read the location parameter for incoming call, and be able to set redirecting number for outgoing call Does anybody use this module for SIP-I ? Have you experiences of SIP-I trunking with telco ? And another question: when you make an ISUP (SS7) interconnection with a telco, you need to pass specific test to validate the correct implementation of the SS7 protocol (and it's national variant, eg. SPIROU in france). Is it the same thing on an SIP-I interconnection ? Any information about it will be appreciate, Cheers, Jérôme. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] CANCEL request and subsequent 487 response to INVTE configuration problem
Hello,
the functions from tm and tmx module work at transaction level -- if the
transaction was not created before (or the function doesn't create the
transaction), then they don't do much. The log messages you gave
indicated that the transaction was not found.
In understood that you terminate the invite locally, not forward it via
sip anymore, so you need to create the transaction with the dedicated
function. Otherwise, t_relay() creates the transaction if not created
(for convenience).
Cheers,
Daniel
On 15/06/15 20:23, Joao Alves wrote:
>
> Hi Daniel,
>
>
>
> As suggested, I’ve add the t_newtran() after the SIP INVITE and did
> work. Now the responses are being send correctly (which is great!),
> and in fact no need did notice that the 487 response is sent
> automatically, and thus no need to explicitly generate one.
>
>
>
> Curious to understand why is that. I gathered that t_newtran() –
> assuming this is the proper function – was used to create a new
> transaction, let’s say if needed to generate a new SIP INVITE req from
> the server (UAS) side. Why in that sense would I need to create a
> “new” transaction?
>
>
>
> Many Thanks,
>
> Joao
>
>
>
>
>
> *From:*sr-users [mailto:sr-users-boun...@lists.sip-router.org] *On
> Behalf Of *Daniel-Constantin Mierla
> *Sent:* segunda-feira, 15 de Junho de 2015 18:45
> *To:* Kamailio (SER) - Users Mailing List
> *Subject:* Re: [SR-Users] CANCEL request and subsequent 487 response
> to INVTE configuration problem
>
>
>
> Hello,
>
> have you created the transaction for INVITE request?
>
> There is also a function t_cancel_callid() that could help better than
> t_reply_callid().
>
> Cheers,
> Daniel
>
> On 15/06/15 19:29, Joao Alves wrote:
>
> Hi,
>
>
>
> I’m creating a configuration is for a SIP <> HTTP gateway
> (performing protocol conversion) and thus all SIP messages and
> responses needs to be generated from the kamailio config file.
>
>
>
> I’m failing to create the case where the calling user abandons the
> session, and thus, following the reception of a CANCEL a 200 “OK”
> needs to be sent to this transaction and later the 487 “Request
> Terminated” to the SIP INVITE original session.
>
>
>
> On the traces I see:
>
> SIP INVITE (Cseq 1 INVITE) -->
>
> 100 Trying (Cseq 1 INVITE) <--
>
> 180 Ringing (Cseq 1 INVITE) <--
>
> SIP CANCEL (Cseq 1 CANCEL) -->
>
> 200 Ok (CSeq 1 CANCEL) <--
>
> 487 Request Terminated (CSeq 1 CANCEL)
>
>
>
> Have then tried several options, trying to force the CSeq 1 INVITE
> but without success.
>
> t_reply_callid("$ci", "$cs", "487", " Request Terminated ");
>
> t_reply_callid("$ci", "$rm", "487", "Request Terminated");
>
> t_reply_callid("$ci", "1", "487", "Request Terminated");
>
>
>
> For instance, for the last I get the following log.
>
> 6(60226) exec: *** cfgtrace:request_route=[REQINIT]
> c=[/etc/kamailio/kamailio.cfg] l=705 a=28 n=t_reply_callid
>
> 6(60226) DEBUG: tm [t_lookup.c:1715]: t_lookup_callid(): created
> comparable call_id header field: >Call-ID:
> 76589ZTJmNTAwZDhlOTZiM2I3MjhhYzllNjgyOWVjZGZmMzk
>
> <
>
> 6(60226) DEBUG: tm [t_lookup.c:1719]: t_lookup_callid(): created
> comparable cseq header field: >CSeq: 1 INVITE<
>
> 6(60226) DEBUG: tm [t_lookup.c:1722]: t_lookup_callid(): just
> locked hash index 18668, looking for transactions there:
>
> 6(60226) DEBUG: tm [t_lookup.c:1749]: t_lookup_callid(): DEBUG:
> t_lookup_callid: transaction not found.
>
> 6(60226) DEBUG: tmx [tmx_mod.c:500]: t_reply_callid(): Lookup
> failed - no transaction
>
>
>
> Could you assist here?
>
>
>
> Thanks,
>
> Joao
>
>
>
>
>
>
>
> *Joao Alves*
>
> Solution Architect, Unified Communications
>
>
>
> +351 214094660 (desk)
>
> +351 912783702 (mobile)
>
>
>
> *AMDOCS |**EMBRACE CHALLENGE**EXPERIENCE SUCCESS*
>
>
>
> This message and the information contained herein is proprietary
> and confidential and subject to the Amdocs policy statement, you
> may review at http://www.amdocs.com/email_disclaimer.asp
>
>
> ___
>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>
> 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
> Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@l
Re: [SR-Users] Keep-Alive in dialog "freeing a free fragment"
Hello,
Following up on this issue, though KA seems to work fine now. We're
running into another problem. We use a fork of CNXCC that terminates all
calls when the user doesn't have enough credit. But with these patches
that doesn't work anymore and the current thread even locks up completely.
We've tracked it down to these changes:
diff --git a/modules/dialog/dlg_req_within.c
b/modules/dialog/dlg_req_within.c
index 206d13e..5668c3c 100644
--- a/modules/dialog/dlg_req_within.c
+++ b/modules/dialog/dlg_req_within.c
@@ -214,7 +214,7 @@ void bye_reply_cb(struct cell* t, int type, struct
tmcb_params* ps){
unref++;
}
/* dialog terminated (BYE) */
- run_dlg_callbacks( DLGCB_TERMINATED, dlg, ps->req,
ps->rpl, DLG_DIR_NONE, 0);
+ run_dlg_callbacks( DLGCB_TERMINATED_CONFIRMED, dlg,
ps->req, ps->rpl, DLG_DIR_NONE, 0);
LM_DBG("first final reply\n");
/* derefering the dialog */
@@ -521,6 +525,9 @@ int dlg_bye_all(struct dlg_cell *dlg, str *hdrs)
str all_hdrs = { 0, 0 };
int ret;
+ /* run dialog terminated callbacks */
+ run_dlg_callbacks( DLGCB_TERMINATED, dlg, NULL, NULL,
DLG_DIR_NONE, 0);
+
if ((build_extra_hdr(dlg, hdrs, &all_hdrs)) != 0)
{
LM_ERR("failed to build dlg headers\n");
This is a diff between 4.2.3 and 4.2.5, once reverted, everthing works fine.
Can you tell me the reason for these additions? What is the expected
difference in behaviour?
Cheers,
Dirk
On 12-05-15 10:49, Daniel-Constantin Mierla wrote:
Hello,
master is still the code to be 4.3, we will make a dedicated branch
sometime soon.
The patch will be backported to 4.2 as well. Thanks for helping to
troubleshoot and testing.
Cheers,
Daniel
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Keep-Alive in dialog "freeing a free fragment"
Hello,
the respective patch was done to fix generating CDRs on local BYE. Maybe
cnxcc is locking slots as well, I am not familiar with the module at all.
Perhaps the best is to change the mutexes to be re-entrant, to avoid
such conflicts between dialog and upper layer modules relying on it. I
will push a patch for it.
Cheers,
Daniel
On 16/06/15 13:59, Dirk Teurlings - SIGNET B.V. wrote:
> Hello,
>
> Following up on this issue, though KA seems to work fine now. We're
> running into another problem. We use a fork of CNXCC that terminates
> all calls when the user doesn't have enough credit. But with these
> patches that doesn't work anymore and the current thread even locks up
> completely.
>
>
> We've tracked it down to these changes:
>
> diff --git a/modules/dialog/dlg_req_within.c
> b/modules/dialog/dlg_req_within.c
> index 206d13e..5668c3c 100644
> --- a/modules/dialog/dlg_req_within.c
> +++ b/modules/dialog/dlg_req_within.c
> @@ -214,7 +214,7 @@ void bye_reply_cb(struct cell* t, int type, struct
> tmcb_params* ps){
> unref++;
> }
> /* dialog terminated (BYE) */
> - run_dlg_callbacks( DLGCB_TERMINATED, dlg, ps->req,
> ps->rpl, DLG_DIR_NONE, 0);
> + run_dlg_callbacks( DLGCB_TERMINATED_CONFIRMED, dlg,
> ps->req, ps->rpl, DLG_DIR_NONE, 0);
>
> LM_DBG("first final reply\n");
> /* derefering the dialog */
> @@ -521,6 +525,9 @@ int dlg_bye_all(struct dlg_cell *dlg, str *hdrs)
> str all_hdrs = { 0, 0 };
> int ret;
>
> + /* run dialog terminated callbacks */
> + run_dlg_callbacks( DLGCB_TERMINATED, dlg, NULL, NULL,
> DLG_DIR_NONE, 0);
> +
> if ((build_extra_hdr(dlg, hdrs, &all_hdrs)) != 0)
> {
> LM_ERR("failed to build dlg headers\n");
>
>
>
>
>
> This is a diff between 4.2.3 and 4.2.5, once reverted, everthing works
> fine.
>
> Can you tell me the reason for these additions? What is the expected
> difference in behaviour?
>
>
> Cheers,
> Dirk
>
>
> On 12-05-15 10:49, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> master is still the code to be 4.3, we will make a dedicated branch
>> sometime soon.
>>
>> The patch will be backported to 4.2 as well. Thanks for helping to
>> troubleshoot and testing.
>>
>> Cheers,
>> Daniel
>>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> 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
Book: SIP Routing With Kamailio - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] CANCEL request and subsequent 487 response to INVTE configuration problem
Got it. Thanks for the explanation!.
Regards,
Joao
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: terça-feira, 16 de Junho de 2015 12:08
To: Joao Alves; Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] CANCEL request and subsequent 487 response to INVTE
configuration problem
Hello,
the functions from tm and tmx module work at transaction level -- if the
transaction was not created before (or the function doesn't create the
transaction), then they don't do much. The log messages you gave indicated that
the transaction was not found.
In understood that you terminate the invite locally, not forward it via sip
anymore, so you need to create the transaction with the dedicated function.
Otherwise, t_relay() creates the transaction if not created (for convenience).
Cheers,
Daniel
On 15/06/15 20:23, Joao Alves wrote:
Hi Daniel,
As suggested, I've add the t_newtran() after the SIP INVITE and did work. Now
the responses are being send correctly (which is great!), and in fact no need
did notice that the 487 response is sent automatically, and thus no need to
explicitly generate one.
Curious to understand why is that. I gathered that t_newtran() - assuming this
is the proper function - was used to create a new transaction, let's say if
needed to generate a new SIP INVITE req from the server (UAS) side. Why in that
sense would I need to create a "new" transaction?
Many Thanks,
Joao
From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Daniel-Constantin Mierla
Sent: segunda-feira, 15 de Junho de 2015 18:45
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] CANCEL request and subsequent 487 response to INVTE
configuration problem
Hello,
have you created the transaction for INVITE request?
There is also a function t_cancel_callid() that could help better than
t_reply_callid().
Cheers,
Daniel
On 15/06/15 19:29, Joao Alves wrote:
Hi,
I'm creating a configuration is for a SIP <> HTTP gateway (performing protocol
conversion) and thus all SIP messages and responses needs to be generated from
the kamailio config file.
I'm failing to create the case where the calling user abandons the session, and
thus, following the reception of a CANCEL a 200 "OK" needs to be sent to this
transaction and later the 487 "Request Terminated" to the SIP INVITE original
session.
On the traces I see:
SIP INVITE (Cseq 1 INVITE) -->
100 Trying (Cseq 1 INVITE) <--
180 Ringing (Cseq 1 INVITE) <--
SIP CANCEL (Cseq 1 CANCEL) -->
200 Ok (CSeq 1 CANCEL) <--
487 Request Terminated (CSeq 1 CANCEL)
Have then tried several options, trying to force the CSeq 1 INVITE but without
success.
t_reply_callid("$ci", "$cs", "487", " Request Terminated ");
t_reply_callid("$ci", "$rm", "487", "Request Terminated");
t_reply_callid("$ci", "1", "487", "Request Terminated");
For instance, for the last I get the following log.
6(60226) exec: *** cfgtrace:request_route=[REQINIT]
c=[/etc/kamailio/kamailio.cfg] l=705 a=28 n=t_reply_callid
6(60226) DEBUG: tm [t_lookup.c:1715]: t_lookup_callid(): created comparable
call_id header field: >Call-ID: 76589ZTJmNTAwZDhlOTZiM2I3MjhhYzllNjgyOWVjZGZmMzk
<
6(60226) DEBUG: tm [t_lookup.c:1719]: t_lookup_callid(): created comparable
cseq header field: >CSeq: 1 INVITE<
6(60226) DEBUG: tm [t_lookup.c:1722]: t_lookup_callid(): just locked hash
index 18668, looking for transactions there:
6(60226) DEBUG: tm [t_lookup.c:1749]: t_lookup_callid(): DEBUG:
t_lookup_callid: transaction not found.
6(60226) DEBUG: tmx [tmx_mod.c:500]: t_reply_callid(): Lookup failed - no
transaction
Could you assist here?
Thanks,
Joao
Joao Alves
Solution Architect, Unified Communications
+351 214094660 (desk)
+351 912783702 (mobile)
AMDOCS |EMBRACE CHALLENGEEXPERIENCE SUCCESS
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may review at
http://www.amdocs.com/email_disclaimer.asp
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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
Book: SIP Routing With Kamailio - http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Keep-Alive in dialog "freeing a free fragment"
I just pushed the patch -- commit link is:
-
https://github.com/kamailio/kamailio/commit/9c3ea838b31039ac067e17d519df67b64b0dada1
Testing and reporting the results will be really appreciated.
Cheers,
Daniel
On 16/06/15 14:32, Daniel-Constantin Mierla wrote:
> Hello,
>
> the respective patch was done to fix generating CDRs on local BYE. Maybe
> cnxcc is locking slots as well, I am not familiar with the module at all.
>
> Perhaps the best is to change the mutexes to be re-entrant, to avoid
> such conflicts between dialog and upper layer modules relying on it. I
> will push a patch for it.
>
> Cheers,
> Daniel
>
> On 16/06/15 13:59, Dirk Teurlings - SIGNET B.V. wrote:
>> Hello,
>>
>> Following up on this issue, though KA seems to work fine now. We're
>> running into another problem. We use a fork of CNXCC that terminates
>> all calls when the user doesn't have enough credit. But with these
>> patches that doesn't work anymore and the current thread even locks up
>> completely.
>>
>>
>> We've tracked it down to these changes:
>>
>> diff --git a/modules/dialog/dlg_req_within.c
>> b/modules/dialog/dlg_req_within.c
>> index 206d13e..5668c3c 100644
>> --- a/modules/dialog/dlg_req_within.c
>> +++ b/modules/dialog/dlg_req_within.c
>> @@ -214,7 +214,7 @@ void bye_reply_cb(struct cell* t, int type, struct
>> tmcb_params* ps){
>> unref++;
>> }
>> /* dialog terminated (BYE) */
>> - run_dlg_callbacks( DLGCB_TERMINATED, dlg, ps->req,
>> ps->rpl, DLG_DIR_NONE, 0);
>> + run_dlg_callbacks( DLGCB_TERMINATED_CONFIRMED, dlg,
>> ps->req, ps->rpl, DLG_DIR_NONE, 0);
>>
>> LM_DBG("first final reply\n");
>> /* derefering the dialog */
>> @@ -521,6 +525,9 @@ int dlg_bye_all(struct dlg_cell *dlg, str *hdrs)
>> str all_hdrs = { 0, 0 };
>> int ret;
>>
>> + /* run dialog terminated callbacks */
>> + run_dlg_callbacks( DLGCB_TERMINATED, dlg, NULL, NULL,
>> DLG_DIR_NONE, 0);
>> +
>> if ((build_extra_hdr(dlg, hdrs, &all_hdrs)) != 0)
>> {
>> LM_ERR("failed to build dlg headers\n");
>>
>>
>>
>>
>>
>> This is a diff between 4.2.3 and 4.2.5, once reverted, everthing works
>> fine.
>>
>> Can you tell me the reason for these additions? What is the expected
>> difference in behaviour?
>>
>>
>> Cheers,
>> Dirk
>>
>>
>> On 12-05-15 10:49, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> master is still the code to be 4.3, we will make a dedicated branch
>>> sometime soon.
>>>
>>> The patch will be backported to 4.2 as well. Thanks for helping to
>>> troubleshoot and testing.
>>>
>>> Cheers,
>>> Daniel
>>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> 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
Book: SIP Routing With Kamailio - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Keep-Alive in dialog "freeing a free fragment"
Hi Daniel,
Just applied this patch on 4.2.5, debian wheezy stable from
kamailio.org. Unfortunately it doesn't fix the problem.
Looking into CNXCC master code I noticed that there are quite a few
changes now. I will try and backport CNXCC from master to 4.2.5 first
before coming back to this issue.
Thanks,
Dirk
On 16-06-15 15:34, Daniel-Constantin Mierla wrote:
I just pushed the patch -- commit link is:
-
https://github.com/kamailio/kamailio/commit/9c3ea838b31039ac067e17d519df67b64b0dada1
Testing and reporting the results will be really appreciated.
Cheers,
Daniel
On 16/06/15 14:32, Daniel-Constantin Mierla wrote:
Hello,
the respective patch was done to fix generating CDRs on local BYE. Maybe
cnxcc is locking slots as well, I am not familiar with the module at all.
Perhaps the best is to change the mutexes to be re-entrant, to avoid
such conflicts between dialog and upper layer modules relying on it. I
will push a patch for it.
Cheers,
Daniel
On 16/06/15 13:59, Dirk Teurlings - SIGNET B.V. wrote:
Hello,
Following up on this issue, though KA seems to work fine now. We're
running into another problem. We use a fork of CNXCC that terminates
all calls when the user doesn't have enough credit. But with these
patches that doesn't work anymore and the current thread even locks up
completely.
We've tracked it down to these changes:
diff --git a/modules/dialog/dlg_req_within.c
b/modules/dialog/dlg_req_within.c
index 206d13e..5668c3c 100644
--- a/modules/dialog/dlg_req_within.c
+++ b/modules/dialog/dlg_req_within.c
@@ -214,7 +214,7 @@ void bye_reply_cb(struct cell* t, int type, struct
tmcb_params* ps){
unref++;
}
/* dialog terminated (BYE) */
- run_dlg_callbacks( DLGCB_TERMINATED, dlg, ps->req,
ps->rpl, DLG_DIR_NONE, 0);
+ run_dlg_callbacks( DLGCB_TERMINATED_CONFIRMED, dlg,
ps->req, ps->rpl, DLG_DIR_NONE, 0);
LM_DBG("first final reply\n");
/* derefering the dialog */
@@ -521,6 +525,9 @@ int dlg_bye_all(struct dlg_cell *dlg, str *hdrs)
str all_hdrs = { 0, 0 };
int ret;
+ /* run dialog terminated callbacks */
+ run_dlg_callbacks( DLGCB_TERMINATED, dlg, NULL, NULL,
DLG_DIR_NONE, 0);
+
if ((build_extra_hdr(dlg, hdrs, &all_hdrs)) != 0)
{
LM_ERR("failed to build dlg headers\n");
This is a diff between 4.2.3 and 4.2.5, once reverted, everthing works
fine.
Can you tell me the reason for these additions? What is the expected
difference in behaviour?
Cheers,
Dirk
On 12-05-15 10:49, Daniel-Constantin Mierla wrote:
Hello,
master is still the code to be 4.3, we will make a dedicated branch
sometime soon.
The patch will be backported to 4.2 as well. Thanks for helping to
troubleshoot and testing.
Cheers,
Daniel
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] siptrace: how to log sent ACK within dialog
Hi, TM forward ACK statelessly (see log below), so there is no call of installed callback on TMCB_REQUEST_(IN)SENT in siptrace module, so I can't see way how to log ACK sent packet. Any work around to get sent ACK logged? DEBUG: sl [sl_funcs.c:388]: sl_filter_ACK(): DEBUG : sl_filter_ACK: to late to be a local ACK! DEBUG:
Re: [SR-Users] Kamailio Crash
On 06/16/2015 12:04 PM, Marc Soda wrote: Is it normal for Kamailio to segfault No. :-) Can you provide a GDB backtrace? -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio Crash
Is it normal for Kamailio to segfault on a duplicate key in the usrloc DB? Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate entry 'uloc-557a96c1-3577-4e5f1' for key 'ruid_idx' Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: [db_query.c:337]: db_do_update(): error while submitting query Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: usrloc [ucontact.c:800]: db_update_ucontact_addr(): updating database failed Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: usrloc [urecord.c:368]: wb_timer(): updating contact in db failed (aor: sip305_isibmp) I believe that there should never be a duplicate key. I'm not sure how that's happening either. I have 3 Kamailio boxes in a cluster replicating registrations to each other and using a MySQL Galara cluster for the usrloc DB. This is Kamailio 4.0.6. Thanks, Marc ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] loose_route to find transport=tcp
We are using Kamailio 4.2.5 as a registrar and proxy between many dispersed
end-users of a soft phone app and our calling platform / switch.
Until now we have used udp exclusively but are trying to introduce tcp
between end-users and Kamailio, leaving udp between Kam and our
switch...while maintaining the ability for some end-users to use udp to Kam.
With some simple address checks I am able to always send to our switch over
udp. If all end-users used tcp I could send everything else tcp, but I need
to maintain udp support.
The specific problem I am having is on a reINVITE such as this one from our
platform to the a-leg:
INVITE sip:xx@x:42679;user=phone SIP/2.0
Via: SIP/2.0/UDP
x:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad
Max-Forwards: 35
Route:
Route:
Contact:
To: "xx";tag=daba971c
From: ;tag=6a678853-co76461-INS002
Call-ID: MDI4ZmFjNmZhN2Y1NWE2ZTViNTkyZGUwNWE2YzUzYmU
CSeq: 7646101 INVITE
Allow:
INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO,UPDATE
Content-Type: application/sdp
Date: Mon, 15 Jun 2015 20:10:18 GMT
User-Agent:
Content-Length: 262
As you might notice, we have rr:enable_double_rr set:
*There are some situations when the server needs to insert two Record-Route
header fields instead of one. For example when using two disconnected
networks or doing cross-protocol forwarding from UDP->TCP. This parameter
enables inserting of 2 Record-Routes. The server will later remove both of
them. *
and I believe it is necessary to keep this way. Without it Kamailio doesn't
even see the reINVITE...the switch probably tries tcp and that's not setup
between the two.
The invite above is sent to the a-leg over udp but I would expect and need
it to be tcp in this case. The reINVITE is part of an existing dialog. We
call loose_route() followed by some simple bflag setting and flag checking,
t_on_reply(), ... then t_relay().
I do have a functional workaround but would prefer to avoid such manual
handling by utilizing built-in functionality properly.
#
# relay the message
#
if(route(TEST_TOGW)) {
if (!t_relay_to_udp()) {
sl_reply_error();
}
}
else {
if ($(hdr(Route)[-1]) =~ "tcp") {
if(!t_relay_to_tcp()) {
sl_reply_error();
}
}
else if (!t_relay()) {
sl_reply_error();
}
}
I'm not 100% sure how reliable or fast this will be, but it does work so
far in my simple tests.
Is loose_route supposed to see and use the transport=tcp but isn't for some
reason? It seems like the right thing to do to me. If not, is there
anything else I can/should be doing in the tm and/or rr modules to make
Kamailio realize it needs to send this message over TCP? If not in those
two modules is there some recommended way perhaps via registrar or usrloc
etc. to make Kamailio remember/store when a user is connected via TCP and
be able to do a quick lookup before sending to them? Anything else I'm
missing or not thinking of?
Please let me know if I can further explain and rest assured any assistance
will be much appreciated!!!
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio Crash
Unfortunately, the best I can do is this: Core was generated by `/usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.'. Program terminated with signal 11, Segmentation fault. #0 0x7fa3e65a5f3b in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so (gdb) #0 0x7fa3e65a5f3b in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so #1 0x7fa3e659a2b8 in mem_timer_udomain () from /usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so #2 0x7fa3e658bec6 in synchronize_all_udomains () from /usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so #3 0x7fa3e65a465a in ?? () from /usr/lib/x86_64-linux-gnu/kamailio/modules/usrloc.so #4 0x0054d517 in ?? () #5 0x00552aa2 in slow_timer_main () #6 0x0047df69 in main_loop () #7 0x0041bcd1 in main () I can't find the proper kamailio-dbg DEB to install for 4.0.6. Only 4.0.7 is in the repo. Anyway, I still believe the trouble is with writing to the DB. Marc On Tue, Jun 16, 2015 at 12:05 PM, Alex Balashov wrote: > On 06/16/2015 12:04 PM, Marc Soda wrote: > > Is it normal for Kamailio to segfault >> > > No. :-) Can you provide a GDB backtrace? > > -- > Alex Balashov | Principal | Evariste Systems LLC > 303 Perimeter Center North, Suite 300 > Atlanta, GA 30346 > United States > > Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > ntended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio Crash
Marc Soda writes: > Is it normal for Kamailio to segfault on a duplicate key in the usrloc > DB? > > Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: db_mysql > [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate > entry 'uloc-557a96c1-3577-4e5f1' for key 'ruid_idx' I don't know if it is normal, but I have seen the same error messages. My sip proxy has not crashed though. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] loose_route to find transport=tcp
After enabling and deciphering debugging it appears there may be a bug. I
also reviewed https://tools.ietf.org/html/rfc5658#section-6
I cross-referenced my pcap to ensure I was looking at the reINVITE and see:
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG: rr
[loose.c:785]: after_loose(): *Topmost route URI:
'sip:xx.xxx.x.xx;lr;r2=on;ftag=a30a720a;did=b75.65a1;nat=yes' is me*
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if
host==us: 11==11 && [xx.xxx.x.xx] == [xx.xxx.x.xx]
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port
5060 (advertise 0) matches port 5061
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if
host==us: 11==11 && [xx.xxx.x.xx] == [xx.xxx.x.xx]
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port
5070 (advertise 0) matches port 5061
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if
host==us: 11==11 && [xx.xxx.x.xx] == [xx.xxx.x.xx]
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port
5090 (advertise 0) matches port 5061
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if
host==us: 11==11 && [xx.xxx.x.xx] == [xx.xxx.x.xx]
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port
5061 (advertise 0) matches port 5061
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG:
[parser/msg_parser.c:106]: get_hdr_field(): found end of header
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG: rr
[loose.c:181]: find_next_route(): *No next Route HF found*
Jun 16 15:01:29 x /usr/sbin/kamailio[643]: DEBUG: rr
[loose.c:847]: after_loose(): no next URI found
There is definitely another Route header immediately below the one found
above, but find_next_route() doesn't find it
. I added my own debugging to loose.c and
if ((_m->last_header->type!=HDR_ROUTE_T) || (_m->last_header==*_hdr)) {
LM_DBG("No next Route HF found\n");
LM_DBG("_m->last_header->type: %d\n", _m->last_header->type);
return 1;
}
logs find_next_route(): _m->last_header->type: 12 which is
HDR_CONTENTLENGTH_T which is indeed the LAST header in the message. We have
done very little work in the Kamailio source...just some database escaping
in odbc for things to work properly with our database engine...but unless
I'm missing something isn't it very wrong to be looking at the last header
right here? I may attempt to figure out the message and/or hdr_field data
structures and change it. It may also be that the issue doesn't occur when
find_next_route is called with a valid _hdr which does seem to search for
the "next" one vs going straight to the final header in the entire message.
If this is getting overly complicated for this mailing list please let me
know...
Ryan
On Tue, Jun 16, 2015 at 11:40 AM, Ryan Kendrick
wrote:
>
> We are using Kamailio 4.2.5 as a registrar and proxy between many
> dispersed end-users of a soft phone app and our calling platform / switch.
>
> Until now we have used udp exclusively but are trying to introduce tcp
> between end-users and Kamailio, leaving udp between Kam and our
> switch...while maintaining the ability for some end-users to use udp to Kam.
>
> With some simple address checks I am able to always send to our switch
> over udp. If all end-users used tcp I could send everything else tcp, but I
> need to maintain udp support.
>
> The specific problem I am having is on a reINVITE such as this one from
> our platform to the a-leg:
>
> INVITE sip:xx@x:42679;user=phone SIP/2.0
> Via: SIP/2.0/UDP
> x:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad
> Max-Forwards: 35
> Route:
> Route:
>
> Contact:
> To: "xx";tag=daba971c
> From: :5070>;tag=6a678853-co76461-INS002
> Call-ID: MDI4ZmFjNmZhN2Y1NWE2ZTViNTkyZGUwNWE2YzUzYmU
> CSeq: 7646101 INVITE
> Allow:
> INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO,UPDATE
> Content-Type: application/sdp
> Date: Mon, 15 Jun 2015 20:10:18 GMT
> User-Agent:
> Content-Length: 262
>
> As you might notice, we have rr:enable_double_rr set:
>
> *There are some situations when the server needs to insert two
> Record-Route header fields instead of one. For example when using two
> disconnected networks or doing cross-protocol forwarding from UDP->TCP.
> This parameter enables inserting of 2 Record-Routes. The server will later
> remove both of them. *
>
> and I believe it is
