Hi,
Sorry for the slightly off topic question, but I am trying to debug a
buggy PBX and want to check if the digest information is correct.
I have this perl script.
#!/usr/bin/perl
use strict;
use Digest::MD5 qw(md5 md5_hex md5_base64);
my $uri = 'sip:sip1.uni-tel.dk';
my $method = "SIP/2.0";
my $username = "69102208";
my $password = "password";
my $nonce = "4e78d2b0a72196d9123be7c88d093bd74c77f35e";
my $realm = "sip1.uni-tel.dk";
my $a1 = "$username:$realm:$password";
my $ha1 = md5_hex($a1);
my $a2 = "$method:$uri";
my $ha2 = md5_hex($a2);
print "A1 : $a1\n";
print "A2 : $a2\n";
my $response = md5_hex("$ha1:$nonce:$ha2");
print "\nRES : $response\n\n";
I registered with a softphone and entered the above values from the
Authentication header, but I cannot get the response to match.
Any help would be appreciated.
--
Morten Isaksen
Hi,
Another funny thing I encountered lately is this:
Client sends INVITE via kamailio (via dispatcher) to sems, gets back
100/200, sends another couple of INVITE with same CSeq (looks like
retransmissions), gets back more 200, then sends ACKs for each of the
200 it got. Looks like a quite broken client to me, but anyways.
The interesting thing is that after >5000ms (which is bigger then
tm.wt_timer), another 200 is sent from sems to kamailio to the client. I
see the 200 coming to kamailio in a network trace, but not an according
log message in the kamailio logs. What I see though is this:
Sep 14 13:51:26 sp2 /usr/sbin/kamailio[15950]: ERROR: <core>
[udp_server.c:586]: ERROR: udp_send:
sendto(sock,0x97ec10,1055,0,1.2.3.4:58620,16): Invalid argument(22)
Sep 14 13:51:26 sp2 /usr/sbin/kamailio[15950]: ERROR: <core>
[forward.h:149]: msg_send: ERROR: udp_send failed
The 1.2.3.4:58620 is obviously taken from the Vias, which looks like this:
Via: SIP/2.0/UDP 127.0.0.1:5060;rport=5060;branch=xyz
Via: SIP/2.0/UDP 10.1.1.9:58620;received=1.2.3.4;rport=58620;branch=abc
The top-most Via is itself, the second is the one which reflects the
destination address in the error message above.
So I'm wondering whether there is some issue with finding the proper
socket after wt_timer is expired (note that the leg client<->kamailio
uses a different socket (with public ip) than kamailio<->sems (which
uses 127.0.0.1)). Or any other idea where this error could come from?
It's actually an educated guess that this could be related to wt_timer,
but I don't know what else it could be.
Andreas
Hey Phillip,
you probably forgot to keep the mailing list in CC, I'll do that for you.
On 19.09.2011 08:43, Phillman25 Kyriacou wrote:
> You are right.
>
> I added the function dlg_manage(); when there is a BYE or CANCEL and now
> its working perfectly. Before i had this function defined only on
> INVITES. The strange thing is that it was working normally before when
> dlg_manage(); was defined only for INVITE messages in the route block.
So you are saying that before, you called dlg_manage() on INVITEs only
but now, you need that function on both INVITE and BYE/CANCEL messages?
That'd still qualify as a bug as the trigger to tracking the dialog
(i.e., dlg_manage()) is required only once. After that, the dialog
module makes sure that all dialog-related messages are properly
processed. The only thing that's necessary for sequential requests to be
tracked correctly is a call to loose_route() on such messages.
If you are sure that your Kamailio configuration didn't change between
3.1.2 and 3.1.5 w.r.t. dialog tracking or anything that could affect it,
I'd be willing to take a closer look at this issue (giving you can
provide me with more information on your scenario, like call flow
examples or similar).
Cheers,
--Timo
> The calls that were suppose to be terminated before where in state 3 to
> answer your question. However, i still see calls in state 3 now but they
> are valid.
>
> Regards
> Phillip
>
> On Fri, Sep 16, 2011 at 8:01 PM, Timo Reimann <timo.reimann(a)1und1.de
> <mailto:timo.reimann@1und1.de>> wrote:
>
> Hey Phillip,
>
> after looking closer at what has been reported to me initially, your
> case may be different after all.
>
> Could you possibly use "kamctl fifo dlg_list" to check what state the
> majority of dialogs that should be terminated in your opinion are in?
> Being given the reference counter should be useful in debugging this as
> well.
>
>
> Thanks,
>
> --Timo
>
>
>
> On 16.09.2011 14:22, Phillman25 Kyriacou wrote:
> > On Fri, Sep 16, 2011 at 3:09 PM, Timo Reimann
> <timo.reimann(a)1und1.de <mailto:timo.reimann@1und1.de>
> > <mailto:timo.reimann@1und1.de <mailto:timo.reimann@1und1.de>>> wrote:
> >
> > Hey Phillip,
> >
> >
> > On 16.09.2011 13:35, Phillman25 Kyriacou wrote:
> > > Hello
> > >
> > > I have been facing an issue where the dialog module is showing
> > calls as
> > > being active when in fact the call has already been
> completed long ago
> > > and this is giving wrong number of concurrent calls on our
> SNMP work
> > > station (CACTI) when polling the data from Kamailio. I
> realized this
> > > only started occurring after i upgraded from 3.1.2 to 3.1.5, has
> > anyone
> > > experienced the same issue?
> >
> > I was *just* being notified of issues concerning dialogs not being
> > deleted. Working on this right now to report back soon.
> >
> > Thanks for the note!
> >
> >
> > Cheers,
> >
> > --Timo
Hi everyone,
I'd like to check that a client certificat is revoked or not against a crl.
Actually, opensips use context SSL_CTX. How can I do with this context?
I do this change to load the crl :
load_crl(SSL_CTX * ctx, char *filename)
{
LM_DBG("entered load crl\n");
X509_STORE *pStore = SSL_CTX_get_cert_store(ctx);
X509_LOOKUP* plookup = X509_STORE_add_lookup(pStore, X509_LOOKUP_file());
if (!X509_load_crl_file(plookup, filename, X509_FILETYPE_PEM)){
LM_ERR("unable to load certificate file '%s'\n",
filename);
return -1;
}
LM_DBG("'%s' successfuly loaded\n", filename);
return 0;
}
But I dont know how to add flags, is it the right solution?
Thanks all
--
View this message in context: http://old.nabble.com/Add-client-certificate-checking-against-a-CRL-in-open…
Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.
Does Kamailio use lazy evaluation in if expressions?
Like
if ($var(a) == 2 && $var(b) ==3) { ... }
then $var(b) == 3 is only evaluated if $var(a) == 2 is true
--
Morten Isaksen
when sems receives voice call invite from ua behind nat that has
direction:active in its sdp, like this:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): foo.bar 0 0 IN IP4 192.168.1.
68
Session Name (s): -
Connection Information (c): IN IP4 192.168.1.68
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8500 RTP/AVP 18 4 112 100 101 0 8 106
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:4 G723/8000
Media Attribute (a): rtpmap:112 AMR/8000
Media Attribute (a): rtpmap:100 EG711U/8000
Media Attribute (a): rtpmap:101 EG711A/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:106 telephone-event/8000
Media Attribute (a): direction:active
sems includes direction:passive in 200 OK and starts to correctly send
rtp packets to the ip address/port of received rtp packets.
however, then sems receives a voice+video call invite like this:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): foo.bar 0 0 IN IP4 192.168.1.68
Session Name (s): -
Connection Information (c): IN IP4 192.168.1.68
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8500 RTP/AVP 18 4 112 100 101 0 8 106
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:4 G723/8000
Media Attribute (a): rtpmap:112 AMR/8000
Media Attribute (a): rtpmap:100 EG711U/8000
Media Attribute (a): rtpmap:101 EG711A/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:106 telephone-event/8000
Media Description, name and address (m): video 8600 RTP/AVP 34
Bandwidth Information (b): AS:300
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:34 H263/90000
Media Attribute (a): direction:active
it does not include direction:passive in 200 OK and keeps on sending rtp
packets to 192.168.1.68 even after receiving first voice rtp packet from
public ip of the ua.
is this a bug in sems or is it a bug in sr nathelper_k
fix_nated_sdp("1") implementation, i.e., does that function place
direction:active line to only one place, when it should place it in two
places (in both voice and video media descriptions)?
-- juha
Hi All,
I'm starting kamailio version 3.1.2 with db_text module but when it tries to
load route table, the following error is generated:
*
"ERROR: <core> [daemonize.c:273]: Main process exited before writing to
pipe"
*
Someone Can Help me to understand why this error is happening? Below is
part of kamaio's trace.
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_base.c:208]: _tbc->name: route
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_base.c:209]: _tbc->nrcols: 9
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_base.c:210]: _nc: 8
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_base.c:238]: new res with 8 cols
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_res.c:69]: new res with 8 cols
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: <core>
[db_res.c:118]: allocate 28 bytes for result set at 0x82e23f0
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: <core>
[db_res.c:155]: allocate 32 bytes for result names at 0x82e3798
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: <core>
[db_res.c:165]: allocate 32 bytes for result types at 0x82e37c0
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[0] at 0x82e2438
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[1] at 0x82e2390
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[2] at 0x82e23d0
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[3] at 0x82e23e0
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[4] at 0x82e37e8
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[5] at 0x82e37f8
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[6] at 0x82e3808
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: db_text
[dbt_api.c:80]: allocate 8 bytes for RES_NAMES[7] at 0x82e3818
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: <core>
[db_res.c:184]: allocate 8 bytes for rows at 0x82e3828
Sep 19 16:13:01 sswpst00 /usr/local/sbin/kamailio[25661]: DEBUG: <core>
[db_row.c:119]: allocate 160 bytes for row values at 0x82e3838
Sep 19 16:13:01 sswpst00 kamailio: ERROR: <core> [daemonize.c:273]: Main
process exited before writing to pipe
Best Regards
>
> ICE is not supported as I select the Media Proxy (which is TURN) manually
> in some Nat cases...Even note that I do not have peer to peer calls between
> 2 endpoints, just have VOIP to PSTN calls...All my VOIP customers supports
> STUN/TURN but without ICE
>
> One more thing: I would like to ask how rtp proxy help to bypass NAT else
> than working as relay server...Does it have any other job like find the NAT
> type or check blocked port or something?
>
> Regards
>
>
> On Fri, Sep 16, 2011 at 5:50 PM, Klaus Darilion <
> klaus.mailinglists(a)pernau.at> wrote:
>
>> STUN alone is not 100% sufficient, only ICE+TURN is reliable. Thus, only
>> if all your clients support ICE+TURN then you can drop rtpproxy.
>>
>> klaus
>>
>>
>> On 16.09.2011 16:47, Mikael Williams wrote:
>>
>>> Dear All,
>>>
>>> I would like to ask please if and in case I'm using STUN/TURN for Nat
>>> traversal to drp the rtpproxy from my solution as NAT traversal and
>>> relay server as I'm using SYUN for NAT traversal and TURN as relay in
>>> case of Symmetric NAT
>>>
>>> Regards
>>>
>>>
>>> ______________________________**_________________
>>> 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<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>>>
>>
>
Hello
I have been facing an issue where the dialog module is showing calls as
being active when in fact the call has already been completed long ago and
this is giving wrong number of concurrent calls on our SNMP work station
(CACTI) when polling the data from Kamailio. I realized this only started
occurring after i upgraded from 3.1.2 to 3.1.5, has anyone experienced the
same issue?
my config:
========
loadmodule "dialog.so"
.
.
.
.
# ----------------- DIALOG MODULE
PARAMETERS----------------------------------#
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 4096)
modparam("dialog", "rr_param", "did")
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "timeout_avp", "$avp(i:10)")
modparam("dialog", "dlg_extra_hdrs", "NULL")
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "detect_spirals", 1)
modparam("dialog", "db_url", "mysql://openser:openserrw@localhost/openser")
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 60)
modparam("dialog", "db_fetch_rows", 500)
modparam("dialog", "table_name", "dialog")
modparam("dialog", "from_uri_column", "from_uri")
modparam("dialog", "from_tag_column", "from_tag")
modparam("dialog", "to_uri_column", "to_uri")
modparam("dialog", "to_tag_column", "to_tag")
modparam("dialog", "h_id_column", "hash_id")
modparam("dialog", "h_entry_column", "hash_entry")
modparam("dialog", "state_column", "state")
modparam("dialog", "start_time_column", "start_time")
modparam("dialog", "timeout_column", "timeout")
modparam("dialog", "sflags_column", "sflags")
modparam("dialog", "bridge_controller", "sip:controller@kamailio.org")
modparam("dialog", "default_timeout", 7200)
.
.
.
.
route {
# MANAGE ALL DIALOGS
#===================================================
if (is_method("INVITE"))
{
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
}
Thanks
Phillip