I have this in my config
$ru = "sip:"+$rU+"10.31.2.101:5090;transport=tls";
if (!t_relay_to_tls()) {
sl_reply_error();
return;
}
My ip address dest is 10.31.2.101.
Why has 130.31.2.101 been used?
13(10882) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 130.31.2.101
4(10883) ERROR: <core> [tcp_main.c:4422]: tcpconn_main_timeout(): connect 130.31.2.101:5090 failed (timeout)
Integration - works.
Problem - dialing peer to peer via Kamailio OK but with missing VARs and
extension number, on dialing/transferring.
Maybe you know other way to configure Asterisk dialplan for users,
registered on kamailio and alowing dial as SIP/UserNumber insted SIP/
UserNumber(a)kamailio.host.name
What we have.
My Kamailio config:
*http://pastebin.com/p7YxsFaw <http://pastebin.com/p7YxsFaw>*
Asterisk's user (peer) - registered on kamailio:
[3]
host=192.168.144.212
qualify=yes
dtmfmode=rfc2833
canreinvite=no
context=local-routing
host=dynamic
type=friend
directmedia=no
nat=no
qualify=yes
disallow=all
allow=ulaw
allow=alaw
allow=g729
call-limit=2
limitonpeers=yes
callcounter=yes
callerid=Usov Mob <3>
### Asterisk queue members:
;syntax: member =>
interface,[,penalty][,membername][,state_interface][,ringinuse]
member=SIP/1(a)sip.cloudpbx.com.ua,1,1001,SIP/1,no
member=SIP/3(a)sip.cloudpbx.com.ua,1,1003,SIP/1,no
### Asterisk dialing local peer:
...
exten => _X,n,Dial(SIP/${EXTEN}(a)sip.cloudpbx.com.ua,12,tT)
...
### Asterisk attended transfer from 1 to 9 exten:
*http://pastebin.com/k9H4vMgx <http://pastebin.com/k9H4vMgx>*
Problem #1:
Peer 9 receive clid as asterisk(a)sip.cloudpbx.com.ua
Need #1:
1(a)sip.cloudpbx.com.ua.
Problem #2:
TRANSFERERNAME=SIP/sip.cloudpbx.com.ua-000000b5
Need #2:
TRANSFERERNAME=SIP/1(a)sip.cloudpbx.com.ua-000000b5
### Asterisk blind transfer dump log:
*http://pastebin.com/NXqXingR <http://pastebin.com/NXqXingR>*
Problem #3:
BLINDTRANSFER=SIP/sip.cloudpbx.com.ua-000000ba
Need #3:
BLINDTRANSFER=SIP/9(a)sip.cloudpbx.com.ua-000000ba
Main problem it is missed peer number - SIP/*peer_number*@
sip.cloudpbx.com.ua. And asterisk(a)sip.cloudpbx.com.ua instead
1(a)sip.cloudpbx.com.ua on attended transfer.
Asterisk sip.conf domain settings:
realm=sip.cloudpbx.com.ua
fromdomain=sip.cloudpbx.com.ua
;domain=sip.cloudpbx.com.ua ;; temporary not uses becaouse not accepting
GOIP sim ports registration on asterisk with IP-address of sip proxy
instead domain sip.cloudpbx.com.ua; and it's not helps to change
asterisk(a)sip.cloudpbx.com.ua clid
Any help from all - wellcome!
P.S. domain sip.cloudpbx.com.ua not exist
Hi,
We frequently run into the situation where a call is simultaneously
CANCEL'd by the caller and answered (2xx) by the callee. This results in
the caller not sending an e2e ACK, since it CANCEL'd the branch. It
results in retransmission of the 200 OK, since the proxy can't CANCEL
the branch anymore.
It leaves the dialog in state 3
#define DLG_STATE_CONFIRMED_NA 3 /*!< confirmed dialog without a ACK
yet */ (dlg_hash.h)
for up to 'dialog_timeout' time.
Is there a straightforward hack for this situation? Does changing the
dialog timeout AVP have any effect after the relay of the initial INVITE
(and thus invocation of the registered dialog init TM callback)?
More generally, I was wondering if there has been any thought given to
the idea of separate timeout modparams for confirmed-nonACKed state, as
well as early state perhaps.
Thanks,
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hi,
I need to get call-id and from-tag from a call in ringing state (2).
If I use dlg_manage() and put the call into a profile using
set_dlg_profile("usr","1").
Then do a avp_db_query() I don't see the call until it is connected.
I am using db_mode 1.
Yet if I do a sercmd dlg.dlg_list I see the call in ringing state and when
it is connected.
How do I get the call-id when it is in ringing state?
Regards
John
Dear list,
I'm having a problem.
I have an SBC server with two network interfaces, one external IP
(X.X.248.194) and other internal IP (X.X.248.21). Messages are sent to the
proxy sip server through internal ip with this configuration:
route [sip-serverr] {
rewritehostport ("ip_sip_proxy: 5060");
force_send_socket (X.X.248.21: 5060);
t_relay ();
exit;
}
When a UA sends an INVITE to the SBC, the responses (back) to UA are being
sent with the correct external source IP (X.X.248.194) but if there are
retransmissions of these responses, after 6 seconds, the source IP changes
to the internal ip (X.X.248.21)
Does anyone from the list know how I can solve this?
Thanks,
Regards,
--
Diego
Daniel, Klaus,
Sorry to reply late to your comments, was busy doing some other things
until now.
Just provided some comments in
https://sip-router.org/tracker/index.php?do=details&task_id=380
Please take a look and let me know if you agree with my assessment. Thanks,
Ding
So when Im trying to use is_subscriber & load_credentials together, It
seems I have either hit a bug or just a bad config ( but I dont think its
the latter )
My symptom is that only the field on the far right of "load_credentials"
ever returns the correct value, the other fields are always null.
My config has this setting :
modparam("auth_db", "load_credentials", "field1;field2")
and I can see the following debug when running kamailio -ddddd
0(14174) DEBUG: auth_db [authdb_mod.c:291]: w_is_subscriber(): uri [sip:
1112(a)192.168.173.5] table [subscriber] flags [1]
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:807]: db_cassa_query():
query table=subscriber
0(14174) DEBUG: db_cassandra [dbcassa_table.c:461]:
dbcassa_db_get_table(): found dbname=kamailio, table=subscriber
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:351]: cassa_constr_key():
query col = username
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:351]: cassa_constr_key():
query col = domain
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:376]: cassa_constr_key():
key = 1112 192.168.173.5
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:499]:
cassa_translate_query(): Query col: field2
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:499]:
cassa_translate_query(): Query col: field1; field2
0(14174) DEBUG: db_cassandra [dbcassa_base.cpp:501]:
cassa_translate_query(): get 2 columns
0(14174) DEBUG: <core> [db_res.c:118]: db_new_result(): allocate 56 bytes
for result set at 0x7fc6ce770e78
if I had to put money on where the bug is, I would look in
parse_aaa_pvs in authdb_mod.c
however, an initial glance revealed nothing glaring, also this file was
last changed in *2013-01-20 ( and that was only a move from modules_k )*
SURELY I cant be the only person wanting to use this for more than one
field ?
This code looks like its almost the same as when first committed in August
2011 ....
Id love someone to see if they can confirm this and point me in the right
direction ( if this is my fault ) or lets get this fixed, if its a bug :)
--
Sincerely
Jay
Hoho,
i want to implement RFC3578 (transaction oriented) in Kamailio.
Therefore I have to correlate two different Invites with same Call-ID. I
see various ways of accomplishing this, but I am stuck at all of my
solutions.
Find the algorithm I want to implement attached.
Shortly explained what RFC3578 is: In a open numbering plan you never
know if the INVITE you received is already complete, or if there are
more numbers coming in. One way of accomplishing this is to set up a
timer. If the timer elapses you assume the number is complete. If not,
you are receiving a new INVITE with one digit more. Now you have to
close the old transaction with a "484 - Address Incomplete"-response and
start the timer again. (Find the algorithm I want to implement attached)
The following lines, I'm going to explain my thoughts. For reference I'm
calling "Thread A" the first INVITE coming in and "Thread B" the second.
#######################
### using Module ASYNC
* Thread A -> async_route("handle_overlap","<timer t99 value>");
* Thread B -> if new incoming transaction,
** set avp("<call-id>")= <digitlength of called number> and
** call async_route("handle_overlap","<timer t99 value>");
* in route[handle_overlap]
** if avp("call-id") greater than "<digitlength of called number>"
*** cancel transaction with "484 -Address Incomplete"
** if avp("call-id") equals "<digitlength of called number>"
*** handle call => the number is complete
PROBLEM: The old transaction is not canceled immediately, but after t99
elapsed...
#######################
### using Module TMX
using t_suspend() and t_continue(), but here i see the following problems:
* Thread A calls "t_suspend()"
** How is it possible to cancel "Thread A"'s transaction from Thread B?
** If there is no Thread B, so the numbers were complete, how can I get
Thread A to continue processing??
* General TMX-Question: Are there any examples available?
#######################
### using simple sleep() and shv()/avp()
Sounds like dirty hacking... I'd appriciate a solution with one of
aboves modules. But if there is a solution available, I'd try this.
Thx in advise
Moritz
--
Moritz Graf, B.Sc.
Betrieb NGN-Plattform
G-FIT GmbH & Co. KG
Greflingerstr. 26, 93055 Regensburg
Telefon +49 (9 41) 69 85 - 1 86
Telefax +49 (9 41) 69 85 - 2 86
mailto:moritz.graf@g-fit.de
http://www.g-fit.de
G-FIT Gesellschaft für innovative Telekommunikationsdienste mbH & Co.
KG, Kommanditgesellschaft, Sitz Regensburg, Registergericht Regensburg,
HRA 7626; Geschäftsführer: Dipl.Inf. (FH) Alfred Rauscher
Hi,
I’ve recently tried out CDR-stats, and after a bumpy ride to get it going ;) , I’m happily surprised with it.
Especially the fraud detection mechanisms (which could use some extra’s), and the eye-candy makes it attractive.
It is based on a mongodb which has to be filled with CDRs.
As there is no mongodb module in Kamailio, I was thinking of using the jsonrpc module to push cdrs from Kamailio to some Python thing which pushes it into MongoDB. Perhaps by using the async module.
Netstrings seems a rather low overhead protocol, and the jsonrpc module allows to push over a cluster of servers, which makes it scalable.
Would this be a good way to do this, or am I bluntly missing the better way?
Thx,
Davy