I have someone who is trying to send me SIP-T messages through a SER
system that acts as a PSTN gateway. The destination PSTN switch
can accept either SIP or SIP-T as can the originator of the INVITE.
The SIP-T message appears to pass through SER in both directions
with the SIP-T data apparently intact.
However, there are problems with the SDP payload. The functions
in modules/nathelper that locate the SDP payload (mainly in
check_content_type() in nhelpr_funcs.c) appear to be coded
to never work properly with multi-part MIME in the message
headers, nor deal with section boundary markers in the message
body. So when the headers contain a:
Content-Type: multipart/mixed;boundary=tekBoundary
instead of the expected*:
Content-Type: application/sdp
nathelper gets confused and says things like:
May 22 21:25:56 ser1 ser[24905]: ERROR:check_content_type: invalid type
for a message
May 22 21:25:56 ser1 ser[24905]: ERROR: extract_body: content type
mismatching
May 22 21:25:56 ser1 ser[24905]: ERROR: force_rtp_proxy: can't extract
body from the message
* (nhelpr_funcs.c also tests for Content-Types beginning with "icat",
"ion" and "appl" in addition to sdp but doesn't know how to deal
with any others, including a "multipart/mixed" and the resulting
nested message body.
Subsequently, calls to the various force_rtp_proxy() and related
functions when processing the INVITE, 183 Session Progress or
200 OK replies do not substitute in the new IP address provided by
rtpproxy (because it can't find the start of the body or a known
body type), and so the party receiving this message will get
the uncorrected IP address and audio for the call fails due to
an unreachable IP address.
This limitation is noted in ser-2.0.0-rc1.
Has anybody done any development to make check_content_type() and
the related functions in nhelpr_funcs.c capable of dealing with
multi-part MIME sections? Ideally, SER should allow the
entire message body even with more than one section to pass without
comment or complaint. Meanwhile, nathelper should be able to
find the sdp section and allow parsing and editing of it as
would have been done if the body contained only one section.
In reading RFC 3261, it appears that multi-part MIME is allowed
and so it appears that nathelper is violating the RFC by not
coping with this. Here is the passage on this subject that
caught my attention:
7.4.1 Message Body Type (RFC 3261)
The Internet media type of the message body MUST be given by the
Content-Type header field. If the body has undergone any encoding
such as compression, then this MUST be indicated by the Content-
Encoding header field; otherwise, Content-Encoding MUST be omitted.
If applicable, the character set of the message body is indicated as
part of the Content-Type header-field value.
The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
the body of the message. Implementations that send requests
containing multipart message bodies MUST send a session description
as a non-multipart message body if the remote implementation requests
this through an Accept header field that does not contain multipart.
SIP messages MAY contain binary bodies or body parts. When no
explicit charset parameter is provided by the sender, media subtypes
of the "text" type are defined to have a default charset value of
"UTF-8".
Thanks in advance to any pointers to newer nathelper code
that deals with this RFC-permitted message body format.
Here is an example of the INVITE message that caused the
problem:
INVITE sip:9712345678@230.123.45.67:5060 SIP/2.0
Via: SIP/2.0/UDP 225.67.89.1:5060;branch=z9hG4bKfi0cjdk0qb8sv24f18ki1ddao4
To: <sip:9712345678@230.123.45.67:5060>
From: <sip:8005551212@225.67.89.1>;tag=11775339
Call-ID: 1241812549-66096587@SIP
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:8005551212@225.67.89.1:5060;transport=udp>
Supported: 100rel
Expires: 330
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, PRACK, REFER, SUBSCRIBE,
NOTIFY,
UPDATE, REGISTER
P-Asserted-Identity: <sip:8005551212@8.4.99.59>
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary=tekBoundary
Content-Length: 426
--tekBoundary
Content-Type: application/sdp
v=0
o=- 321533952 1243026447 IN IP4 225.67.89.1
s=-
c=IN IP4 225.67.89.1
t=0 0
a=sendrecv
m=audio 49168 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
--tekBoundary
Content-Type: application/isup; base=ansi92; version=ansi
..x
..x...x..x.Pxx
....x@xp.xx..xx..
--tekBoundary--
This is and old issue that I still have around here ...
-Kamailio 1.5.1 (svn)
-PostgreSQL database
-Database created with "kamdbctl create", so just clean
- in kamailio.cfg:
[...]
loadmodule "uri_db.so"
modparam("uri_db", "db_url", "postgres://openser:XXXXX@localhost:5435/voip3")
modparam("uri_db", "db_table", "uri")
modparam("uri_db", "user_column", "username")
modparam("uri_db", "domain_column", "domain")
modparam("uri_db", "uriuser_column", "uri_user")
modparam("uri_db", "use_uri_table", 0)
modparam("uri_db", "use_domain", 0)
[...]
May 24 10:22:27 [23631] INFO:core:init_mod: initializing module auth_db
May 24 10:22:27 [23631] INFO:core:init_mod: initializing module uri_db
May 24 10:22:27 [23631] ERROR:uri_db:mod_init: Invalid table version of the
subscriber table
May 24 10:22:27 [23631] ERROR:core:init_mod: failed to initialize module
uri_db
May 24 10:22:27 [23631] ERROR:core:main: error while initializing modules
And I don't undestand why ... because subscriber table it's on version 6, that
is what uri_db checks ...
[uri_db_mod.c]
/* Check table version */
ver = uridb_db_ver(&db_url, &db_table);
if (ver < 0) {
LM_ERR("Error while querying table version\n");
return -1;
} else {
if (use_uri_table) {
if (ver != URI_TABLE_VERSION) {
LM_ERR("Invalid table version of the uri table\n");
return -1;
}
} else {
if (ver != SUBSCRIBER_TABLE_VERSION) {
LM_ERR("Invalid table version of the subscriber table\n");
return -1;
}
}
}
[uri_db_mod.c]
and SUBSCRIBER_TABLE_VERSION has value 6
is there something I'm doing wrong?, last time I compile myself this I was
forced to comment that block of code on the uri_db sources.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Hi all, I'm getting a lot of problems to migrate to 1.5.1, the last one is
with auth.
I'm using postgresql as DB and auth_db with the next params:
[...]
loadmodule "auth.so"
modparam("auth", "nonce_expire", 300)
modparam("auth", "realm_prefix", "sip.")
modparam("auth", "rpid_suffix", ";party=calling;id-type=subscriber;screen=yes")
modparam("auth", "rpid_avp", "$avp(s:rpid)")
loadmodule "auth_db.so"
modparam("auth_db", "db_url", "postgres://openser:XXXX@localhost:5435/voip3")
modparam("auth_db", "user_column", "username")
modparam("auth_db", "domain_column", "domain")
modparam("auth_db", "password_column", "password")
modparam("auth_db", "password_column_2", "ha1b")
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "use_domain", 1)
modparam("auth_db", "load_credentials", "$avp(s:caller_uuid)=uuid")
[...]
With openser 1.3.2 and this:
[...]
if(!www_authorize("", "subscriber"))
{
xlog("L_INFO", "Register authentication failed BI $T_branch_idx - M=$rm
RURI=$ru F=$fu T=$tu IP=$si I D=$ci\n");
www_challenge("", "0");
exit;
}
[...]
All is working ok .. but with kamailio 1.5.1 it doesn't run, It allway return
401 Authentication needed ...
I don't found anything in the docs about any change on auth modules ... what
could be happen ?
Best regards
--
Raúl Alexis Betancor Santana
Dimensión Virtual
I'm geting this error when trying to run kamailio svn trunk version
...
May 23 22:27:30 [17510] INFO:core:init_mod: initializing module usrloc
May 23 22:27:30 [17510] INFO:usrloc:ul_init_locks: locks array size 512
May 23 22:27:30 [17510] ERROR:core:db_check_api: module db_postges does not
export db_use_table function
May 23 22:27:30 [17510] ERROR:usrloc:mod_init: failed to bind database module
May 23 22:27:30 [17510] ERROR:core:init_mod: failed to initialize module
usrloc
May 23 22:27:30 [17510] ERROR:core:main: error while initializing modules
...
Any clue?
--
Raúl Alexis Betancor Santana
Dimensión Virtual
On 05/24/2009 10:50 AM, Raúl Alexis Betancor Santana wrote:
> On Sunday 24 May 2009 08:38:42 you wrote:
>
>> Hello,
>>
>> On 05/24/2009 12:30 AM, Raúl Alexis Betancor Santana wrote:
>>
>>> I'm geting this error when trying to run kamailio svn trunk version
>>>
>>> ...
>>> May 23 22:27:30 [17510] INFO:core:init_mod: initializing module usrloc
>>> May 23 22:27:30 [17510] INFO:usrloc:ul_init_locks: locks array size 512
>>> May 23 22:27:30 [17510] ERROR:core:db_check_api: module db_postges
>>>
>> looks like there is a typo in the db_postgres name (you miss r or?!?).
>>
>> If you want to play with development version, then you should take the
>> sources from GIT http://sip-router.org. It is the place where the
>> development is done now.
>>
>
> Umm, I want to use kamailio not sip-router by now, maybe I sould get .tar.gz
> version of 1.5.1 instead of the svn
>
I thought you have Kamailio development version from svn trunk. If you
have 1.5.x, use the SVN branch 1.5, it is recommended. There are some
fixes since 1.5.1.
Was the error the typo I the db_postgres module name?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Hi,
I was trying to understand how SER manages its memory. From what I searched
and read on the mailing list and SER documentation it seams to me that SER
allocates all the necessary memory at start time and never allocates anymore
memory. If the initial memory defined (PKG,SHM) is full no more will be
allocated. Is this the correct Interpretation?
Kind Regards,
José Carlos Silva
Please keep the list in your replies.
Check the dialog documentation carefully. It is all explained there:
how to add dialogs into a profile and retrieve the them.
The dialog profiles are stored into memory for fast access.
Regards,
Ovidiu Sas
On Wed, May 20, 2009 at 4:26 PM, Kareem Hamdy
<Kareem.Hamdy(a)trustvesta.com> wrote:
> Thanks!
>
> I still don't know how to do it, but you've put me on the right track. I'm fairly new to Kamailio, so I'm trying to figure out all the syntaxing. I did an SQL query on my FS boxes, and I was able to see the number of dialogs per host.
>
> Is it possible to do something similar with Kamailio - where I store the dialogs in a DB and query it in the dispatcher section of my routes?
>
> If so, would you be able to give me an example syntax of how I'd go about doing so?
>
> Thanks,
> Kareem
>
>
>
>
>
> -----Original Message-----
> From: sip.nslu(a)gmail.com [mailto:sip.nslu@gmail.com] On Behalf Of Ovidiu Sas
> Sent: Wednesday, May 20, 2009 12:10 PM
> To: Kareem Hamdy
> Cc: users(a)lists.kamailio.org
> Subject: Re: [Kamailio-Users] Load Based Load Balancing
>
> Hello Kareem,
>
> Use dialog profiling to track the number of calls per destination:
> http://www.kamailio.net/docs/modules/1.5.x/dialog#id2531102
> In your script, before sending the INVITE out, check if the selected
> destination has enough capacity to accept the call:
> http://www.kamailio.net/docs/modules/1.5.x/dialog#id2532103
>
>
> Regards,
> Ovidiu Sas
>
> On Wed, May 20, 2009 at 2:57 PM, Kareem Hamdy
> <Kareem.Hamdy(a)trustvesta.com> wrote:
>> Hello:
>>
>> I've been going through your lists and your documentation, and I'm unable to find how you set up load based load balancing.
>>
>> To further illustrate:
>>
>>
>>
>> For example, let's say we have the following live calls:1,2,3,4,5,6,7
>>
>> Round Robin Works Well
>> ----------------------
>>
>> +-----+
>> | SER |
>> +-----+
>> |
>> | +--------------+
>> |-------| FreeSWITCH 1 | [Calls 1,3,5,7]
>> | +--------------+
>> |
>> | +--------------+
>> |-------| FreeSWITCH 2 | [Calls 2,4,6]
>> +--------------+
>>
>>
>>
>> But let's say some of the calls end significantly quicker than the others, how can I send calls by their load (current calls, cpu, etc)
>>
>> For example, let's say we have the following live calls:1,2,3,4,5,6,7 - Let's say calls 4 and 5 lasted about 30 seconds, while the others lasted about 5 minutes. How would I be able to route calls to the box that's least used - in this example, "FreeSWITCH 2" at any given time had the least number of calls, so calls 4,5, and 6 were dispatched to it.
>>
>> Load Based Load Balancing
>> -------------------------
>>
>> +-----+
>> | SER |
>> +-----+
>> |
>> | +--------------+
>> |-------| FreeSWITCH 1 | [Calls 1,3,7]
>> | +--------------+
>> |
>> | +--------------+
>> |-------| FreeSWITCH 2 | [Calls 2,6]
>> +--------------+
>>
>>
>>
>> Thanks,
>> Kareem
>>
>>
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users(a)lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>
Hi,
I got the following error when using FreeRADIUS to authenticate SER
registration.
May 21 04:46:57 ser[3352]: REGISTER
May 21 04:46:57 ser[3352]: REGISTER: challenging user
May 21 04:46:57 ser[3354]: REGISTER
May 21 04:46:57 ser[3354]: pre_auth(): Credentials received are not
filled properly
What does this mean? Also, I don't see any RADIUS traffic generated by
SER. Please assist.
Thanks
Leon
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be
happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the
dialog module by putting them in a global profile. Because of a
segfault bug with profiles with "no values," a workaround is used
wherein a profile "with" values is created and the hash key is always
the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)
And profile looks like this:
modparam("dialog", "profiles_with_value",
"globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that
performs some logic like this:
route[1] {
# Check if DID is assigned to an account with database
# and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") {
sl_send_reply("404", "Not Found");
exit;
}
get_profile_size("specificinbound", "$avp(S:account_id)",
"$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) {
sl_send_reply("486", "Busy");
exit;
}
setflag(2); # Track dialog.
set_dlg_profile("globalinbound", "1");
set_dlg_profile("specificinbound", "$avp(S:account_id)");
}
What appears to be happening is that calls coming into unassigned
numbers ($avp(S:did_assigned) == "0") increase the size of the
"globalinbound" profile, which is something of a mystery to me since I
am neither setting flag 2 nor calling set_dlg_profile() until further
down in the logic! And after the 404 Not Found reply is sent, the
profile size is not decremented. Is the use of statefully tracked
replies (t_reply()) required in order to propagate dialog state through
to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not
decreased; in my interpretation, such calls should not be added to the
'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
Greetings,
I was wondering if someone fluent in the anatomy of the TM module can
tell me what this condition actually implies in a commonsensical sort of
way, from a user perspective -- it is on line 861 in modules/tm/timer.c:
/* check first if we are on the "detached" timer_routine list,
* if so do nothing, the timer is not valid anymore
* (sideffect: reset_timer ; set_timer is not safe, a reseted timer
* might be lost, depending on this race condition ) */
if (new_tl->timer_list==DETACHED_LIST){
LM_CRIT("set_timer for %d list called on a \"detached\" "
"timer -- ignoring: %p\n", list_id, new_tl);
goto end;
}
Reason I am wondering is that I got a few of these error messages in my
logs:
May 20 18:23:50 ser1 /usr/local/sbin/kamailio[25232]:
CRITICAL:tm:set_timer: set_timer for 1 list called on a "detached" timer
-- ignoring: 0x2a96cc0d50
And was not sure what to make of them.
Thank you!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671