Hello list,
I'm using Kamailio 3.2 and am trying to send a SIP request from fifo to
kamailio using below format.
#kamctl fifo t_uac_dlg MESSAGE sip:103@ mydomain.org . . "From:
101(a)mydomain.org To: 103(a)mydomain.org Contact: mydomain.org Content-Type:
text/plain; charset=UTF-8" "INVITE"
But I see this reply from Kamctl
*database engine 'MYSQL' loaded*
*Control engine 'FIFO' loaded*
*entering fifo_cmd t_uac_dlg INVITE sip:103@ mydomain.org . . From: 101@
mydomain.org To: 103@ mydomain.org Contact: mydomain.org Content-Type:
text/plain; charset=UTF-8 INVITE*
*400 Bad headers*
*FIFO command was:*
*:t_uac_dlg:openser_receiver_25561*
*INVITE*
*sip:103@mydomain.org*
*.*
*.*
*From: 101@ mydomain.org To: 103@ mydomain.org Contact:
mydomain.org Content-Type:
text/plain; charset=UTF-8*
*INVITE*
And in log file I see this output:
Dec 16 00:57:46 Kamailio3 /usr/local/sbin/kamailio[24541]: ERROR: <core>
[parser/msg_parser.c:275]: ERROR: get_hdr_field: bad body for <From:
101(a)mydomain.org To: 103@ mydomain.org Contact: mydomain.org Content-Type:
text/plain; charset=UTF-8INVITE#012>(4)
Dec 16 00:57:46 Kamailio3 /usr/local/sbin/kamailio[24541]: INFO: <core>
[parser/msg_parser.c:353]: ERROR: bad header field [From: 101(a)mydomain.o]
Can anyone help..
Regards,
Sammy
Hi,
My Kamailio server listens on multiple IPs - say IP1, IP2. If a
request arrives on one IP, Kamailio uses the same IP as the source
address when forwarding, which is good. But is there any way a UA
could generate a request to IP1 that gets forwarded by Kamailio with
source address IP2 ? The reason I ask is because Asterisk is setup to
trust all calls arriving from IP2 but not IP1.
Thanks
Ben
Hi,
# sercmd dispatcher.list
error: 500 - command dispatcher.list not found
The module is loaded, dispatcher.list file exists. Am I doing something
wrong ? Thanks.
Mino.
I want to enable the rtp repacketization feature of the rtpproxy. I have set force_rtp_proxy("z150"). But the repacketization is not happening. in the log it does show that rtp will be repacketizes but when i see the wireshark capture, its the same.
With Best Regards
Ariful Hossain Tuhin
email: 1. etothepowerpi(a)gmail.com 2. etothepowerpi(a)hotmail.com 3.etothepowerpi(a)yahoo.com
skype: freeburn1986
Hi,
Siremis v3.2.0 is out - the web management interface for Kamailio and
SER v3.2.x series.
Besides updates to existing views to match the database schema in
Kamailio v3.2.x (such as lcr, dialog or siptrace), there are many new
features. Among most important:
- SQL-based CDR rating engine for billing purposes, with views to manage
the rating rules
- charts and table summaries to reflect the activity of accounting records
- new views to manage records for remote registrations, mtree and global
black list
- command line tools to add new database table views in a step-by-step
wizard fashion
- selection of usernames and domains for many views can be done by a
select box or picker form with values from subscriber or domain tables
More details can be find in the announcement of the release on the web site:
* http://asipto.com/u/4t
or in the ChangeLog inside the tarball.
Siremis can be downloaded from:
* http://asipto.com/u/sd
Alternative download site, along with the GIT repository for Siremis, is
offered at sourceforge.net project:
* http://sourceforge.net/projects/siremis/
Regards,
Ramona
Hello,
I am running into a problem where I am experiencing duplicated INVITE's
being originated from Kamailio proxy.
U 2011/12/13 23:58:17.543802 KAMAILIO:5060 -> PSTN:5060
INVITE sip:URI@PSTN SIP/2.0.
U 2011/12/13 23:58:17.543840 KAMAILIO:5060 -> PSTN:5060
INVITE sip:URI@PSTN SIP/2.0.
As you can see that the timestamp between the two invites is literally a
fraction of seconds.
There is no failure condition that is causing this with append_branch
There is no retransmission timer issue that is causing this (using default
timing):
modparam("tm", "retr_timer1", 500)
modparam("tm", "retr_timer2", 4000)
Any thoughts / ideas - as this is causing a race condition in which there
is a 200 OK that is being sent back from upstream -- and we are then
CANCELING the 2nd INVITE which is essentially causing on overall problem
with the call.
Thanks for all help / thoughts / input in advance, thanks!
Sincerely,
Brandon Armstead
