THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Iñaki Baz Castillo (ibc)
Attached to Project - sip-router
Summary - If no NAPTR then SRV must be queried for more than UDP
Task Type - Bug Report
Category - dns / dns cache
Status - New
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - As discussed in the maillist, Kamailio does the following lookups:
1. NAPTR cisco.com (no result)
2. SRV _sip._udp.cisco.com (NXDOMAIN)
3. A cisco.com -> Bingo -> use SIP over UDP to Cisco's web server :-(
Step 2 is wrong. After NAPTR query (with no result) it should look for SRV records for TLS, TCP and then UDP (maybe also SCTP) in an order configured by local policy (Kamailio DNS settings).
This is really clear in RFC 3263 section 4.1:
If no NAPTR records are found, the client constructs SRV queries for
those transport protocols it supports, and does a query for each.
Queries are done using the service identifier "_sip" for SIP URIs and
"_sips" for SIPS URIs. A particular transport is supported if the
query is successful. The client MAY use any transport protocol it
desires which is supported by the server.
If no SRV records are found, the client SHOULD use TCP for a SIPS
URI, and UDP for a SIP URI. However, another transport protocol,
such as TCP, MAY be used if the guidelines of SIP mandate it for this
particular request.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=253
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi,
I am facing following issues with kamailio 3.3.2 server.
1. Authentication issue for backend subscription of rls resource list
I am using kamailio server as a integrated RLS server.
Server generating backend subscriptions for all resourse list entries, for
client RLS subscribe. But the issue is server again challenging
authentication for thease internal subscribes which are not handled.
As a work around i was removed authentications for SUBSCRIBE requests,
please suggest me proper solution to fix this issue
2. RLS subscribe looping for backend subscriptions
After the work around, i found another issue with RLS backend subscriptions.
Server also generating subscriptions request with the eventlist in the
supported header. this is again handled by rls_handle_subscribe with the
valid return value. So again the server is checking rls resource list to
generate backend subscribes.
please provide me the solution to resolve this issue.
Regards,
Raman
Hi All,
Is there any reason why update_stat(name, value) shouldn't take a $var/avp
as the value? If not, I will go ahead and add the ability.
This would be useful to be able to dynamically add/subtract values to/from
a specific stat.
Cheers
Jason
Module: sip-router
Branch: master
Commit: 2750e03d4977d4a8f59ca0d2d0f59e1caec96b2d
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2750e03…
Author: Carsten Bock <carsten(a)ng-voice.com>
Committer: Carsten Bock <carsten(a)ng-voice.com>
Date: Mon Sep 17 17:25:38 2012 +0200
New Option: "x" for automatic bridging between IPv4 and IPv6.
Based on the following assumption: "i" is the IPv4 interface
and "e" is the IPv6 interface on the RTPProxy (tested with both
RTPProxy and Sipwise's ngcp-mediaproxy-ng).
Mechanism is as follows:
- IP in SDP is IPv4: Do bridging "ie"
- IP in SDP is IPv6: Do bridging "ei"
Not a big deal, but makes the configuration much more easier.
---
modules/rtpproxy/doc/rtpproxy.xml | 8 ++++++++
modules/rtpproxy/doc/rtpproxy_admin.xml | 7 +++++++
modules/rtpproxy/rtpproxy.c | 22 +++++++++++++++++++++-
3 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/modules/rtpproxy/doc/rtpproxy.xml b/modules/rtpproxy/doc/rtpproxy.xml
index d5a15ee..741a4d9 100644
--- a/modules/rtpproxy/doc/rtpproxy.xml
+++ b/modules/rtpproxy/doc/rtpproxy.xml
@@ -57,6 +57,14 @@
<email>osas(a)voipembedded.com</email>
</address>
</editor>
+ <editor>
+ <firstname>Carsten</firstname>
+ <surname>Bock</surname>
+ <affiliation><orgname>ng-voice GmbH</orgname></affiliation>
+ <address>
+ <email>carsten(a)ng-voice.com</email>
+ </address>
+ </editor>
</authorgroup>
<copyright>
<year>2003-2008</year>
diff --git a/modules/rtpproxy/doc/rtpproxy_admin.xml b/modules/rtpproxy/doc/rtpproxy_admin.xml
index a245d73..d6a9dc5 100644
--- a/modules/rtpproxy/doc/rtpproxy_admin.xml
+++ b/modules/rtpproxy/doc/rtpproxy_admin.xml
@@ -344,6 +344,13 @@ rtpproxy_offer();
the 'w' flag for clients behind NAT! See also above notes!
</para></listitem>
<listitem><para>
+ <emphasis>x</emphasis> - this flag will do automatic bridging between IPv4 on the
+ "internal network" and IPv6 on the "external network". The distinction is done by
+ the given IP in the SDP, e.g. a IPv4 Address will always call "ie" to the RTPProxy
+ (IPv4(i) to IPv6(e)) and an IPv6Address will always call "ei" to the RTPProxy (IPv6(e)
+ to IPv4(i)).
+ </para></listitem>
+ <listitem><para>
<emphasis>f</emphasis> - instructs rtpproxy to ignore marks
inserted by another rtpproxy in transit to indicate that the
session is already goes through another proxy. Allows creating
diff --git a/modules/rtpproxy/rtpproxy.c b/modules/rtpproxy/rtpproxy.c
index 9a0fd14..59e7092 100644
--- a/modules/rtpproxy/rtpproxy.c
+++ b/modules/rtpproxy/rtpproxy.c
@@ -1993,6 +1993,7 @@ force_rtp_proxy(struct sip_msg* msg, char* str1, char* str2, int offer, int forc
{NULL, 0}, /* Timeout-Socket */
};
int iovec_param_count;
+ int autobridge_ipv4v6;
char *c1p, *c2p, *bodylimit, *o1p;
char itoabuf_buf[20];
@@ -2012,7 +2013,7 @@ force_rtp_proxy(struct sip_msg* msg, char* str1, char* str2, int offer, int forc
LM_ERR("out of pkg memory\n");
FORCE_RTP_PROXY_RET (-1);
}
- flookup = force = real = orgip = commip = via = 0;
+ flookup = force = real = orgip = commip = via = autobridge_ipv4v6 = 0;
for (cp = str1; cp != NULL && *cp != '\0'; cp++) {
switch (*cp) {
case '1':
@@ -2076,6 +2077,11 @@ force_rtp_proxy(struct sip_msg* msg, char* str1, char* str2, int offer, int forc
orgip = 1;
break;
+ case 'x':
+ case 'X':
+ autobridge_ipv4v6 = 1;
+ break;
+
case 'w':
case 'W':
if (append_opts(&opts, 'S') == -1) {
@@ -2253,6 +2259,12 @@ force_rtp_proxy(struct sip_msg* msg, char* str1, char* str2, int offer, int forc
}
/* XXX must compare address families in all addresses */
if (pf == AF_INET6) {
+ if (autobridge_ipv4v6 != 0) {
+ if ((append_opts(&opts, 'E') == -1) && (append_opts(&opts, 'I') == -1)) {
+ LM_ERR("out of pkg memory\n");
+ FORCE_RTP_PROXY_RET (-1);
+ }
+ }
if (append_opts(&opts, '6') == -1) {
LM_ERR("out of pkg memory\n");
FORCE_RTP_PROXY_RET (-1);
@@ -2260,7 +2272,15 @@ force_rtp_proxy(struct sip_msg* msg, char* str1, char* str2, int offer, int forc
/* We need to update the pointers and the length here, it has changed. */
v[1].iov_base = opts.s.s;
v[1].iov_len = opts.oidx;
+ } else {
+ if (autobridge_ipv4v6 != 0) {
+ if ((append_opts(&opts, 'I') == -1) && (append_opts(&opts, 'E') == -1)) {
+ LM_ERR("out of pkg memory\n");
+ FORCE_RTP_PROXY_RET (-1);
+ }
+ }
}
+
STR2IOVEC(newip, v[9]);
STR2IOVEC(oldport, v[11]);
#ifdef EXTRA_DEBUG
Hi,
today, i've noticed the following:
In the Config of a Border-Proxy (running Kamailio TRUNK), i have the
following settings:
listen=1.2.3.4
listen=1234:1234:3::ea
#!define CAPTURE_NODE "sip:[1234:1234:2:3300::3]:5060"
#!ifdef CAPTURE_NODE
# Destination, where to send the traffic
modparam("siptrace", "duplicate_uri", CAPTURE_NODE)
# Trace all traffic
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag", FLT_CAPTURE)
modparam("siptrace", "hep_mode_on", 1)
#!endif
route {
[...]
sip_capture(); <== This takes 3-4 seconds, if an IPv4 packet is received!!!!
[...]
}
I do IPv4 to IPv6 on that node, so a message is received on the IPv4
interface and sent using the IPv6 interface to the core-network and
the tracing-server.
I've noticed, that forwarding the SIP-Message takes awful long time
(3-4 seconds), when the tracing-server is IPv6 and the message is
actually received on the IPv4-interface. All works fine, if i have an
IPv6 message forwarded via IPv6 or if i have an IPv4 message forwarded
via IPv4; but not if i mix those two protocols (i haven't tried
forwarding IPv6 messages to an IPv4 tracing server).
Before i dig deeper into the code of the siptrace module, does anyone
have a clue, why this could be the case????
Thanks in advance,
Carsten
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Schomburgstr. 80
D-22767 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 34927219
Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/