[SR-Users] SIP between IPv4 and IPv6 agents

[Komáromi Péter]

Hello!

I went through your letters and start as following:

-------------------------------------------------------
root at ubuntu:/home/yeti/rtpproxy# /etc/init.d/kamailio restart
Restarting kamailio: kamailioloading modules under /usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/
Listening on 
             udp: 192.168.124.158:5060
             udp: FEC0:0:0:0:0:0:0:2:5060
             tcp: 192.168.124.158:5060
             tcp: FEC0:0:0:0:0:0:0:2:5060
Aliases: 
             tcp: ubuntu:5060
             udp: ubuntu:5060

root at ubuntu:/home/yeti/rtpproxy# kamctl restart

INFO: Stopping Kamailio : 
INFO: stopped

INFO: Starting Kamailio : 
INFO: started (pid: 7597)
root at ubuntu:/home/yeti/rtpproxy# rtpproxy restart
-------------------------------------------------------

So I guess everything is starting fine. 
The users can register and call each other. Their data are in the mysql database`s location table.
I put this into the kamailio.cfg file:

--------------------------------------------------------
# RTPProxy control
route[RTPPROXY] {
#!ifdef WITH_NAT
	if (is_method("BYE")) {
		unforce_rtp_proxy();
	} else if (is_method("INVITE"))
	{
		if (af == inet) {
			if ( $(rU{s.substr,0,1}) == "6") {
			force_rtp_proxy("ie");
			} else {
				force_rtp_proxy("ee");
			} 
		} else { 
			if ( $(rU{s.substr,0,1}) == "4") {
				force_rtp_proxy("ei");
			} else {
				force_rtp_proxy("ii");
			}
		}	
	} else if (is_method("200OK"))
	{
		if (af == inet) {
			if ( $(rU{s.substr,0,1}) == "6") {
			force_rtp_proxy("ei");
			} else {
				force_rtp_proxy("ee");
			} 
		} else { 
			if ( $(rU{s.substr,0,1}) == "4") {
				force_rtp_proxy("ie");
			} else {
				force_rtp_proxy("ii");
			}
		}	
	}
	if (!has_totag()) add_rr_param(";nat=yes");
#!endif
	return;
}

----------------------------------------------------------

But, unfortunately there is no RTP traffic yet. :(
What do you thing guys, what can be the problem?

Regards,
Peter



Am 02.12.2010 13:06, schrieb Komáromi Péter:
> Hi!
>
> So if you say it is possible to solve the problem with the only
> location table, the location_inet4 and location_inet6 is not
> certainly necessary... do I _have to_ use the 4to6.cfg file from the
> source of kamailio, or not?

When you call force_rtp_proxy() then you have to provide the i/e flags
to tell rtpproxy how it should bridge the call. Therefore you need to
know for every call:
- is the caller IPv4 or IPv6?
- is the callee IPv4 or IPv6?

Finding out the protocol version of the caller is rather easy:

if (af == inet) {
# caller ipv4
...
} else {
# caller ipv6
...
}

But finding out if the callee is v4 or v6 is difficult. Actually it may
even be that the callee is registered with 2 clients at the same time -
one using v4 and v6. As far as I know this multi-registration scenario
can not be handled currently - only single-registrations or
multi-registrations which use the same protocol version are supported.

Anyway - there are several approaches how to detect the IP version of
the callee.

- fixed mapping: for example if you know that all usernames starting
with 1 are IPv4 clients, and all usernames starting with 2 are IPv6
clients, then you can detect the callee's protocol version manually, e.g:

if ( $(rU{s.substr,0,1}) == "1") {
# callee ipv4
...
} else {
# callee ipv6
...
}


- check destination URI if it contains a IPv4 or IPv6 address, e.g. use
http://www.kamailio.org/dokuwiki/doku.php/transformations:devel#resubst_expression
to test if $dd contains '.' which would indicate a ipv4 address.

- use dedicated location tables

> (Because it uses them, for instance here: if (method == "REGISTER")
> { if (af == inet) { save("location-inet4"); } else if (af == inet6)
> { save("location-inet6");...)
>
> If I do not have to use it, I do not need to merge it with my
> kamailio.cfg file, the steps I have to do are: install rtpproxy,
> start it with the appropriate parameters and set the forcing in the
> kamailio.cfg file?!

The more I think about it I prefer the approach with separated location
tables. It should be rather easy to integrate the 2 location tables into
your existing config.

regards
Klaus