Loading stated without config generates a list of error messages, not properly terminated with new line.
0(70227) ERROR: statsd [statsd.c:65]: mod_init(): mod_init_values ip (null) 0(70227) ERROR: statsd [statsd.c:66]: mod_init(): mod_init_values port (null) 0(70227) ERROR: statsd [lib_statsd.c:126]: statsd_init(): Statsd_init ip 127.0.0.1 0(70227) ERROR: statsd [lib_statsd.c:127]: statsd_init(): Statsd_init port 8125 0(70227) ERROR: statsd [statsd.c:68]: mod_init(): Error code in mod_init is 1 0(70227) WARNING: tls [tls_mod.c
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/34
Hi,
This may be a bit out of focus topic for this forum but i am posting it
here anyway with hope that some guru would shed some light on it and point
me to right direction.
The problem is that i want to establish video call between a webrtc and a
sip client using kamailio (for signalling) and RTPEngine (for media relay).
Both signalling and the audio stream seems to work perfectly fine The
remote video on webrtc client side (i.e. video stream from sip client)
takes about 20-30 seconds to establish but once it starts it works fine.
However, the remote video on sip client side (i.e. video stream from webrtc
client) starts almost immediately (within 3-5 seconds) but it gets stuck
after 1 or 2 seconds, then it goes blank after about 30 seconds.
After a long discussion with sip client developer, we now understand the
fact that sip client sends a request for so called key-frame, which is
ignored by webrtc client. This request is sent through both RTCP stream and
SIP INFO message.
The SIP INFO message seems to be pointless as media is internally managed
by chrome/firefox and these browsers don't give us such sophisticated
access and control over media streams. Please let me know if this
assumption is wrong.
For the RTCP stream based request (RTCP-FIR), i only see "Invalid RTCP
packet type" error message in RTPEngine logs (not sure if it drops this
packet or relay it anyway).
Does anyone has any idea on how can we either,
1. Force WebRTC client (running on Chrome / Firefox) to honor SIP INFO
message and issue a key-frame in RTP video stream in response to this SIP
request?
OR
2. Force RTPEngine to accept RTCP-FIR and issue key-frame in RTP video
stream on webrtc client's behalf?
If there is any other solution to this, please feel free to share.
Thank you.
Module: kamailio
Branch: master
Commit: 102504294f9edaaee9d4baea873d4ed9151b8fed
URL: https://github.com/kamailio/kamailio/commit/102504294f9edaaee9d4baea873d4ed…
Author: Charles Chance <charles.chance(a)sipcentric.com>
Committer: Charles Chance <charles.chance(a)sipcentric.com>
Date: 2015-01-30T14:08:01Z
dmq: do not parse From header again, since it was done already prior to cloning msg.
- introduces a memory leak if not manually freed
- but there is no need to parse it again anyway
- discovered by Andrey Rybkin
---
Modified: modules/dmq/worker.c
---
Diff: https://github.com/kamailio/kamailio/commit/102504294f9edaaee9d4baea873d4ed…
Patch: https://github.com/kamailio/kamailio/commit/102504294f9edaaee9d4baea873d4ed…
---
diff --git a/modules/dmq/worker.c b/modules/dmq/worker.c
index 8426730..ca1b3dc 100644
--- a/modules/dmq/worker.c
+++ b/modules/dmq/worker.c
@@ -91,11 +91,11 @@ void worker_loop(int id)
current_job = job_queue_pop(worker->queue);
/* job_queue_pop might return NULL if queue is empty */
if(current_job) {
- /* extract the from uri */
- if (parse_from_header(current_job->msg) < 0) {
- LM_ERR("bad sip message or missing From hdr\n");
- } else {
+ /* attempt to identify node based on from uri */
+ if (current_job->msg->from->parsed) {
dmq_node = find_dmq_node_uri(node_list, &((struct to_body*)current_job->msg->from->parsed)->uri);
+ } else {
+ LM_ERR("bad sip message or missing From hdr\n");
}
ret_value = current_job->f(current_job->msg, &peer_response, dmq_node);
Module: kamailio
Branch: master
Commit: 9e48df9226b63aa8ba5232f6e02e8ba6038f1fe0
URL: https://github.com/kamailio/kamailio/commit/9e48df9226b63aa8ba5232f6e02e8ba…
Author: Jason Penton <jason.penton(a)gmail.com>
Committer: Jason Penton <jason.penton(a)gmail.com>
Date: 2015-01-30T16:41:25+02:00
modules/tm: no reason to reset KR on continuation of async requests
- maybe before continuing, a reply has been sent, request forwarded, etc...
---
Modified: modules/tm/t_suspend.c
---
Diff: https://github.com/kamailio/kamailio/commit/9e48df9226b63aa8ba5232f6e02e8ba…
Patch: https://github.com/kamailio/kamailio/commit/9e48df9226b63aa8ba5232f6e02e8ba…
---
diff --git a/modules/tm/t_suspend.c b/modules/tm/t_suspend.c
index f07307d..4b12dcf 100644
--- a/modules/tm/t_suspend.c
+++ b/modules/tm/t_suspend.c
@@ -221,7 +221,12 @@ int t_continue(unsigned int hash_index, unsigned int label,
Not a huge problem, fr timer will fire, but CANCEL
will not be sent. last_received will be set to 408. */
- reset_kr();
+ /* We should not reset kr here to 0 as it's quite possible before continuing the dev. has correctly set the
+ * kr by, for example, sending a transactional reply in code - resetting here will cause a dirty log message
+ * "WARNING: script writer didn't release transaction" to appear in log files. TODO: maybe we need to add
+ * a special kr for async?
+ * reset_kr();
+ */
/* fake the request and the environment, like in failure_route */
if (!fake_req(&faked_req, t->uas.request, 0 /* extra flags */, uac)) {
Module: kamailio
Branch: master
Commit: 4ba9ee6bff2fc74188c058f71240f1e128717588
URL: https://github.com/kamailio/kamailio/commit/4ba9ee6bff2fc74188c058f71240f1e…
Author: Jason Penton <jason.penton(a)gmail.com>
Committer: Jason Penton <jason.penton(a)gmail.com>
Date: 2015-01-30T14:53:18+02:00
modules/tm: no reason to reset KR on continuation of async requests
- maybe before continuing, a reply has been sent, request forwarded, etc...
---
Modified: modules/tm/t_suspend.c
---
Diff: https://github.com/kamailio/kamailio/commit/4ba9ee6bff2fc74188c058f71240f1e…
Patch: https://github.com/kamailio/kamailio/commit/4ba9ee6bff2fc74188c058f71240f1e…
---
diff --git a/modules/tm/t_suspend.c b/modules/tm/t_suspend.c
index f07307d..8838a97 100644
--- a/modules/tm/t_suspend.c
+++ b/modules/tm/t_suspend.c
@@ -221,7 +221,7 @@ int t_continue(unsigned int hash_index, unsigned int label,
Not a huge problem, fr timer will fire, but CANCEL
will not be sent. last_received will be set to 408. */
- reset_kr();
+// reset_kr();
/* fake the request and the environment, like in failure_route */
if (!fake_req(&faked_req, t->uas.request, 0 /* extra flags */, uac)) {