Does tm.t_uac_wait RPC call block a worker process while waiting for a
reply, or use some sort of asynchronous callback?
Thanks,
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
in some of my tests i get the following udp send related errors, when
request is t_relayed:
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: INFO: Routing initial
INVITE <sip:+35892223333@test.fi> to <sip:+35892223333@193.166.3.2;transport=udp>
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: <core> [udp_server.c:566]: ERROR: udp_send: sendto(sock,0xb2d1f1e8,1190,0,193.166.3.2:5060,16): Invalid argument(22)
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: : <core> [udp_server.c:571]: CRITICAL: invalid sendtoparameters one possible reason is the server is bound to localhost and attempts to send to the net
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [../../forward.h:148]: msg_send: ERROR: udp_send failed
Oct 24 11:20:20 test /usr/sbin/sip-proxy[10032]: ERROR: tm [t_fwd.c:1244]: ERROR: t_send_branch: sending request on branch 0 failed
$du is set to sip:+35892223333@193.166.3.2;transport=udp and the proxy
is listening on many sockets, both 127.0.0.1 and external ip address.
any idea what might cause the errors?
-- juha
hi all,
i am a new bie in kamailio. i use SMS module to send message to GSM net work.
my kamailio.cfg is :
modparam("sms", "modems", "wavecom[d=/dev/ttyS;c=+84900000022;b=57600; m=new;l=20]")
modparam("sms", "networks", "D1[m=10]; d2[m=10]")
modparam("sms", "links", "wavecom[D1;d2]")
modparam("sms", "default_net", "localhost")
modparam("sms", "domain_str", "D1.d2")
modparam("sms", "max_sms_parts", 10)
modparam("sms", "use_contact", 1)
modparam("sms", "sms_report_type", 1)
if(method == "MESSAGE"){
if(has_body("text/plain")){
sms_send_msg_to_net("D1");
}
}
but when i start kamailio
the log show :
Oct 25 06:28:26 localhost kamailio: ERROR: <core> [modparam.c:143]: set_mod_param_regex: parameter <domain_str> not found in module <sms>
Oct 25 06:28:26 localhost kamailio: : <core> [cfg.y:3333]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 173, column 42: Can't set module parameter
please help to configure it correct.
i use wavecom modem and some infomation:
baudrate=57600
c=+84900000022
ip server:192.168.1.100
modem connect with server via com1 (/dev/ttyS0)
and kamailio version 3.0.2
thanks for help me.
Peter Green
Hello,
I am testing TLS communication with Kamailio 3.0.2, and I encounter a strange problem. My setup is like this:
Client <-UDP-> Proxy server <- TLS with client certificate authentication -> Authentication server
192.168.24.1 192.168.24.128 192.168.24.129
The two servers are instance of Kamailio 3.0.2
When the client sends a REGISTER, the proxy retransmits the message to the authentication server, which sends back a 401 Unauthorized. But it seems the proxy closes the TLS connexion right after forwarding the REGISTER, and doesn't receive the 401 message. The TLS handshake is OK, and the client certificate is required (I didn't add the verification part yet). The REGISTER message goes through TLS, and is received by the authentication server. Then, the proxy sends a TLS alert (Close-notify), and after that message, the authentication server sends back the 401, and the proxy ignores that message.
Could it be caused by a timeout? Is there a way to keep the TLS connection opened?
Here are the relevant files (I don't like to send mails of more than 100 lines):
authentication server configuration: http://pastebin.com/QBmnNc4e
authentication server log: http://pastebin.com/uYdHDG5G
proxy server configuration: http://pastebin.com/8WPPJBtM
proxy server log: http://pastebin.com/JTwJSKtk
I am just testing TLS, so I have tried to remove most of the irrelevant parts.
Best regards,
Geoffroy
________________________________
Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
based on core cookbokk, it is not clear to me what happens when drop is
executed in branch route:
drop
Stop the execution of the configuration script and alter the implicit
action which is done afterwards.
If the function is called in a 'branch_route' then the branch is
discarded (implicit action for 'branch_route' is to forward the
request).
i understand that request is not forwarded to that branch, but if that
branch is the only branch, does t_relay() then return -1 or is script
execution terminated?
-- juha
On 10/29/10 5:40 PM, Sergey Okhapkin wrote:
> I can't test now - high volume traffic is running. But I looked at the diff, it
> seems to me OK, I see no reason why it could not work:-)
Because of the law, the Murphy law ;-)
Probably I will test sometime next week if you don't do it before and
then backport.
Cheers,
Daniel
> On Friday 29 October 2010, you wrote:
>> On 10/29/10 4:33 PM, Daniel-Constantin Mierla wrote:
>>> On 10/29/10 4:09 PM, Sergey Okhapkin wrote:
>>>> I just realized that 3.1 executes main routing block when broken SIP
>>>> message
>>>> is received! But sanity_check() function returns 0 on failed checks
>>>> and script
>>>> execution stops, my favorite xlog() is not executed.
>>> OK, that can be fixed very easy. Iirc, in some cases you don't get the
>>> sip message in the config if it is really broken, but I am not sure if
>>> error_route was executed for that case anyhow.
>> I committed on git master, id:
>>
>> 39a8108c62a2beafba18417613b9660a8abef86a
>>
>>
>> Can you take the patch and test it on 3.1? If all is fine, then I can
>> backport - even the default cfg expects non-drop behavior since it
>> attempts to print a log message there.
>>
>> Cheers,
>> Daniel
>>
>>> Cheers,
>>> Daniel
>>>
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core>
>>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core>
>>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip:
>>>> ]
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core>
>>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core>
>>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip:
>>>> ]
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core>
>>>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core>
>>>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip:
>>>> ]
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core>
>>>> [msg_translator.c:1946]: ERROR: build_res_buf_from_sip_req: alas, parse
>>>> _headers failed
>>>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: WARNING: sanity
>>>> [sanity.c:253]: sanity_check(): check_required_headers(): failed to s
>>>> end 400 via sl reply
>>>>
>>>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote:
>>>>> On 10/29/10 11:53 AM, Sergey Okhapkin wrote:
>>>>>> Daniel, I think this could be implemented without re-introduction of
>>>>>> error_route,
>>>>> it will not be re-introduced for sure, we have now a different core
>>>>> framework which care reuse event_route mechanism.
>>>>>
>>>>> In the past the error route was executed when the error was discovered,
>>>>> so it several places of the code, and I am not sure that the core can
>>>>> continue up to config execution of something is really broken.
>>>>>
>>>>> I will have it in mind when I get some spare time.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>> what about core parameter route_on_error=yes/no (default no)? If
>>>>>> route on error is enabled, then sanity module will do the trick:
>>>>>>
>>>>>> route{
>>>>>> if(!sanity_check("1159")) {
>>>>>> xlog("L_INFO","Bad message from
>>>>>> $proto:$si:$sp\n$mb\n");
>>>>>> break;
>>>>>> }
>>>>>> ....
>>>>>>
>>>>>> It will be up to script writer what to do in main routing block if
>>>>>> message parsing fails.
>>>>>>
>>>>>> On Friday 29 October 2010, Sergey Okhapkin wrote:
>>>>>>> It would be nice to get error_route back. The route was trivial in my
>>>>>>> cfg file:
>>>>>>>
>>>>>>> error_route {
>>>>>>> xlog("L_INFO","Bad message from $proto:$si:$sp\n$mb\n");
>>>>>>> drop();
>>>>>>> }
>>>>>>>
>>>>>>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote:
>>>>>>>> On 10/28/10 1:41 PM, Sergey Okhapkin wrote:
>>>>>>>>> I've found one more feature missed in 3.1 - error_route is
>>>>>>>>> eliminated
>>>>>>>>> and sanity module added. But if received SIP message is
>>>>>>>>> malformed and
>>>>>>>>> can't be parsed, routing script is not executed and I have no
>>>>>>>>> way to
>>>>>>>>> log the message to kamailio log. I did it in error_route before.
>>>>>>>>>
>>>>>>>>> This logging is important to me to support customers. SIP ALG in
>>>>>>>>> routers often breaks Via line :-(
>>>>>>>> Since I developed error_route, I remember that it handled just
>>>>>>>> sporadic
>>>>>>>> cases, but I can add an event_route to pass the buffer and some
>>>>>>>> hints
>>>>>>>> to configuration file in case the initial parsing fails and the
>>>>>>>> message
>>>>>>>> is dropped before getting to config file.
>>>>>>>>
>>>>>>>> It is good to know that someone use such case, introduction of
>>>>>>>> sanity
>>>>>>>> was clearly mentioned and so far there was no complain.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>>> On Thursday 28 October 2010, Daniel-Constantin Mierla wrote:
>>>>>>>>>> On 10/26/10 2:22 PM, Sergey Okhapkin wrote:
>>>>>>>>>>> setdebug() function is no longer provided by core. How to change
>>>>>>>>>>> debug level dynamically in the script to trace execution of a few
>>>>>>>>>>> statements only?
>>>>>>>>>> seems was lost in transition to 3.0, I will check to see what
>>>>>>>>>> can be
>>>>>>>>>> done with the new architecture.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Daniel
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> 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
--
Daniel-Constantin Mierla
http://www.asipto.com
