Re: [SR-Users] Kphone

2010-06-02 Thread Alex Balashov

It would be great if it had anything to do with Kamailio/SR.



On Jun 2, 2010, at 11:31 PM, Saz  wrote:


hii

Can anyone help me with Kphone-vic installation I will really  
appreciate for any documentation or manuals.


Thanks in advance.

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing  
list

sr-users@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Kphone

2010-06-02 Thread Saz
hii

Can anyone help me with Kphone-vic installation I will really appreciate for
any documentation or manuals.

Thanks in advance.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Failed to make module db_mysql on Solaris 10 Sparc

2010-06-02 Thread JinKevin

Hi All,

While [ gmake prefix="/usr/local/kamailio-3.0" all ] I got the error below 
regarding the db_mysql, however I have already installed the mysql server in 
the path /usr/local/mysql and all the .h and lib files are there.

 

Please suggest what's wrong here and how to fix the issue.

 

=

 

Makefile.defs defs skipped
gmake[1]: Entering directory 
`/usr/local/src/kamailio-3.0.0/kamailio/modules/db_mysql'
gcc -fPIC -DPIC -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc 
-Wall-DNAME='"kamailio"' -DVERSION='"3.0.2"' -DARCH='"sparc64"' 
-DOS='solaris_' -DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 3.4.6"' 
-D__CPU_sparc64 -D__OS_solaris -DSER_VER=302 
-DCFG_DIR='"/usr/local/kamailio-3.0/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM 
-DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE 
-DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST 
-DUSE_NAPTR -DF_MALLOC -DUSE_TLS -DTLS_HOOKS -DSTATISTICS -DMALLOC_STATS 
-DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM 
-DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD 
-DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT -DHAVE_FILIO_H  
-DSER_MOD_INTERFACE -I/usr/local/include -I/usr/local/include/mysql 
-I/usr/local/mysql/include -I/usr/include/mysql -DMOD_NAME='"db_mysql"' -c 
km_dbase.c -o km_dbase.o -MMD -MP
km_dbase.c:38:25: warning: mysql/mysql.h: No such file or directory
km_dbase.c:39:26: warning: mysql/errmsg.h: No such file or directory
km_dbase.c:40:33: warning: mysql/mysql_version.h: No such file or directory
In file included from km_dbase.c:47:
km_my_con.h:47: error: syntax error before "MYSQL_RES"
km_my_con.h:47: warning: no semicolon at end of struct or union
km_my_con.h:48: warning: type defaults to `int' in declaration of `con'
km_my_con.h:48: warning: data definition has no type or storage class
km_my_con.h:49: error: syntax error before "row"
km_my_con.h:49: warning: type defaults to `int' in declaration of `row'
km_my_con.h:49: warning: data definition has no type or storage class
km_my_con.h:51: error: syntax error before '}' token
km_dbase.c: In function `db_mysql_submit_query':
km_dbase.c:81: error: dereferencing pointer to incomplete type
km_dbase.c:82: warning: implicit declaration of function `mysql_ping'
km_dbase.c:82: error: dereferencing pointer to incomplete type
km_dbase.c:83: warning: implicit declaration of function `mysql_error'
km_dbase.c:83: error: dereferencing pointer to incomplete type
km_dbase.c:83: warning: format argument is not a pointer (arg 7)
km_dbase.c:83: error: dereferencing pointer to incomplete type
km_dbase.c:83: error: dereferencing pointer to incomplete type
km_dbase.c:83: warning: format argument is not a pointer (arg 6)
km_dbase.c:83: error: dereferencing pointer to incomplete type
km_dbase.c:83: error: dereferencing pointer to incomplete type
km_dbase.c:91: error: dereferencing pointer to incomplete type
km_dbase.c:109: warning: implicit declaration of function `mysql_real_query'
km_dbase.c:109: error: dereferencing pointer to incomplete type
km_dbase.c:112: warning: implicit declaration of function `mysql_errno'
km_dbase.c:112: error: dereferencing pointer to incomplete type
km_dbase.c:113: error: `CR_SERVER_GONE_ERROR' undeclared (first use in this 
function)
km_dbase.c:113: error: (Each undeclared identifier is reported only once
km_dbase.c:113: error: for each function it appears in.)
km_dbase.c:113: error: `CR_SERVER_LOST' undeclared (first use in this function)
km_dbase.c:117: error: dereferencing pointer to incomplete type
km_dbase.c:117: warning: format argument is not a pointer (arg 7)
km_dbase.c:117: error: dereferencing pointer to incomplete type
km_dbase.c:117: error: dereferencing pointer to incomplete type
km_dbase.c:117: warning: format argument is not a pointer (arg 6)
km_dbase.c:117: error: dereferencing pointer to incomplete type
km_dbase.c:117: error: dereferencing pointer to incomplete type
km_dbase.c: In function `db_mysql_store_result':
km_dbase.c:166: error: dereferencing pointer to incomplete type
km_dbase.c:166: warning: implicit declaration of function `mysql_store_result'
km_dbase.c:166: error: dereferencing pointer to incomplete type
km_dbase.c:167: error: dereferencing pointer to incomplete type
km_dbase.c:168: warning: implicit declaration of function `mysql_field_count'
km_dbase.c:168: error: dereferencing pointer to incomplete type
km_dbase.c:173: error: dereferencing pointer to incomplete type
km_dbase.c:173: warning: format argument is not a pointer (arg 7)
km_dbase.c:173: error: dereferencing pointer to incomplete type
km_dbase.c:173: error: dereferencing pointer to incomplete type
km_dbase.c:173: warning: format argument is not a pointer (arg 6)
km_dbase.c:173: error: dereferencing pointer to incomplete type
km_dbase.c:173: error: dereferencing pointer to incomplete type
km_dbase.c:188: warning: implicit declaration of function `mysql_free_result'
km_d

Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make kamailio on solaris 10

2010-06-02 Thread JinKevin


 

> Date: Wed, 2 Jun 2010 19:51:01 +0200
> From: and...@iptel.org
> To: kevin@hotmail.com
> CC: sr-users@lists.sip-router.org
> Subject: Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make 
> kamailio on solaris 10
> 
> On Jun 03, 2010 at 01:36, JinKevin  wrote:
> > 
> > 
> > 
> > 
> > > Date: Wed, 2 Jun 2010 16:54:26 +0200
> > > From: and...@iptel.org
> > > To: kevin@hotmail.com
> > > CC: sr-users@lists.sip-router.org
> > > Subject: Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make 
> > > kamailio on solaris 10
> > > 
> > > On Jun 02, 2010 at 08:32, JinKevin  wrote:
> > > > 
> > > > 
> > > > 
> > > > Hi Andrei,
> > > > 
> > > > 
> > > > 
> > > > gcc -dM -E -x c /dev/null
> > > > #define __sparc__ 1
> > > > 
> > > [...]
> > > > 
> > > > 
> > > > isainfo -n
> > > > sparcv9
> > > > 
> > > > 
> > > > 
> > > > isainfo -b
> > > > 64
> > > > 
> > > > uname -m
> > > > sun4u
> > > 
> > > Now I remembered :-)
> > > The problem on sparcv9 is that you can build either sparc32 or sparc64
> > > code. The make system tries to use the configured compiler and use its
> > > default architecture, in this case sparc32.
> > > This changed from older ser or kamailio version, where IIRC
> > > 64 bits was always used on sparcv9 (the isainfo arch was used).
> > > The change was needed for better cross-compiler support, snow leopard
> > > (boots 32 bits kernel, but gcc is configured to produce 64 bit
> > > binaries).
> > > 
> > > So if you have all the needed 64 bits libs installed, you should compile
> > > for sparc64.
> > > Either make config CC_EXTRA_OPTS=-m64 or
> > > make config ARCH=sparc64
> > > should do it (don't forget to re-run it after any make proper).
> > > 
> > > 
> > > [...]
> > > > 
> > > > And bison is also installed, 
> > > > 
> > > > yacc -V 
> > > 
> > > 
> > > I couldn't reproduce the yacc/bison problem.
> > > For me it compiles flawlessly on an old sparcv9 (solaris 9, bison
> > > 1.875d).
> > > 
> > > Could you try running:
> > > yacc -d -b cfg cfg.y
> > > by hand and see what happens? (any error? cfg.tab.h and cfg.tab.c
> > > created?)
> > >
> > 
> > 
> > 
> > It just reports "Broken Pipe"
> > 
> > $ yacc -d -b cfg cfg.y
> > Broken Pipe
> 
> Looks like your bison or bison package is broken.
> One cause might be that you don't have GNU m4 installed or it's not in
> the PATH (it's used by bison).
> See http://old.nabble.com/Broken-pipe-td1225149.html.
> 
> > 
> > 
> > If I removed the bison , then got some other error as below:
> > 
> > $ yacc -d -b cfg cfg.y
> > "cfg.y", line 103: fatal: invalid escape, or illegal reserved word: expect
> 
> You can safely comment out "%expect 5" at line 103. It's just a warning
> killer and for some unkown reason the solaris yacc doesn't seem to like
> it (bison understands it and berkley yacc just ignores it).
> If you want to compile with this yacc version (after removing %expect
> from cfg.y), you would need to run something like:
> make config YACC=/usr/ccs/bin/yacc
> 
> 
 Andrei,
Many thanks!

After comment out the "%expect 5" at line 103, it can go through the "yacc -d 
-b cfg cfg.y" as below:

snip=

gcc -g -O9 -funroll-loops -m64 -mcpu=ultrasparc -mtune=ultrasparc -Wall
-DNAME='"kamailio"' -DVERSION='"3.0.2"' -DARCH='"sparc64"' -DOS='solaris_' 
-DOS_QUOTED='"solaris"' -DCOMPILER='"gcc 3.4.6"' -D__CPU_sparc64 -D__OS_solaris 
-DSER_VER=302 -DCFG_DIR='"/usr/local/kamailio-3.0/etc/kamailio/"' 
-DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST 
-DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER 
-DUSE_DST_BLACKLIST -DUSE_NAPTR -DF_MALLOC -DUSE_TLS -DTLS_HOOKS -DSTATISTICS 
-DMALLOC_STATS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 
-DCC_GCC_LIKE_ASM -DSPARC64_MODE -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H 
-DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION -DHAVE_DEVPOLL -DHAVE_SELECT 
-DHAVE_FILIO_H   -c cfg.tab.c -o cfg.tab.o -MMD -MP
/usr/ccs/bin/yaccpar:5: warning: ignoring #pragma ident 
/usr/ccs/bin/yaccpar: In function `yyparse':
/usr/ccs/bin/yaccpar:164: warning: label `yynewstate' defined but not used
gcc -m64 -O2  action.o atomic_ops.o basex.o bit_scan.o cfg_core.o cfg_parser.o 
core_cmd.o crc.o daemonize.o data_lump_rpl.o data_lump.o dns_cache.o dprint.o 
dset.o dst_blacklist.o endianness.o error.o events.o flags.o forward.o 
hash_func.o id.o io_wait.o ip_addr.o local_timer.o lock_ops.o lvalue.o main.o 
md5.o md5utils.o mod_fix.o modparam.o msg_translator.o nonsip_hooks.o pass_fd.o 
proxy.o pt.o pv_core.o pvapi.o qvalue.o re.o receive.o resolve.o route_struct.o 
route.o rpc_lookup.o rvalue.o script_cb.o sctp_options.o sctp_server.o 
select_buf.o select_core.o select.o ser_stun.o shm_init.o signals.o 
sip_msg_clone.o socket_info.o sr_compat.o sr_module.o stats.o switch.o 
tcp_main.o tcp_options.o tcp_read.o timer_proc.o timer.o tls_hooks.o tsend.o 
udp_server.o usr_avp.o ut.o xavp.o mem/dl_malloc.o mem/f_malloc.o 
mem/ll_malloc.o mem/mem.o mem/memtest.o me

Re: [SR-Users] check_from and check_to: case sensitive?

2010-06-02 Thread Iñaki Baz Castillo
2010/6/2 Henning Westerholt :
>> Yes, this is correct. Then:
>>
>> - check_from / check_to should b fixed to use case sensitive comparison.
>
> Hi Iñaki,
>
> this should be properly documented, as it has the potential of breaking some
> configurations.
>
>> - MySQL database schema should use case sensitive columns for
>> 'username' in subscriber, location and any other tables containing an
>> 'username' column.
>
> I think we should think a bit more about this step, as it would be a major
> change in the way most people expect the database to work, which happens to be
> mostly mysql in our case. Add devel list as CC.

Sure, it would involve an important change so it should be part of a
new version and be properly documented.
I will check out all the stuf that this would require (table columns,
module functions and so) and will document it.

Regards.


-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make kamailio on solaris 10

2010-06-02 Thread Andrei Pelinescu-Onciul
On Jun 03, 2010 at 01:36, JinKevin  wrote:
> 
> 
>  
> 
> > Date: Wed, 2 Jun 2010 16:54:26 +0200
> > From: and...@iptel.org
> > To: kevin@hotmail.com
> > CC: sr-users@lists.sip-router.org
> > Subject: Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make 
> > kamailio on solaris 10
> > 
> > On Jun 02, 2010 at 08:32, JinKevin  wrote:
> > > 
> > > 
> > > 
> > > Hi Andrei,
> > > 
> > > 
> > > 
> > > gcc -dM -E -x c /dev/null
> > > #define __sparc__ 1
> > > 
> > [...]
> > > 
> > > 
> > > isainfo -n
> > > sparcv9
> > > 
> > > 
> > > 
> > > isainfo -b
> > > 64
> > > 
> > > uname -m
> > > sun4u
> > 
> > Now I remembered :-)
> > The problem on sparcv9 is that you can build either sparc32 or sparc64
> > code. The make system tries to use the configured compiler and use its
> > default architecture, in this case sparc32.
> > This changed from older ser or kamailio version, where IIRC
> > 64 bits was always used on sparcv9 (the isainfo arch was used).
> > The change was needed for better cross-compiler support, snow leopard
> > (boots 32 bits kernel, but gcc is configured to produce 64 bit
> > binaries).
> > 
> > So if you have all the needed 64 bits libs installed, you should compile
> > for sparc64.
> > Either make config CC_EXTRA_OPTS=-m64 or
> > make config ARCH=sparc64
> > should do it (don't forget to re-run it after any make proper).
> > 
> > 
> > [...]
> > > 
> > > And bison is also installed, 
> > > 
> > > yacc -V 
> > 
> > 
> > I couldn't reproduce the yacc/bison problem.
> > For me it compiles flawlessly on an old sparcv9 (solaris 9, bison
> > 1.875d).
> > 
> > Could you try running:
> > yacc -d -b cfg cfg.y
> > by hand and see what happens? (any error? cfg.tab.h and cfg.tab.c
> > created?)
> >
> 
>  
> 
> It just reports "Broken Pipe"
> 
> $ yacc -d -b cfg cfg.y
> Broken Pipe

Looks like your bison or bison package is broken.
One cause might be that you don't have GNU m4 installed or it's not in
the PATH (it's used by bison).
See http://old.nabble.com/Broken-pipe-td1225149.html.

>  
> 
> If I removed the bison , then got some other error as below:
> 
> $ yacc -d -b cfg cfg.y
> "cfg.y", line 103: fatal: invalid escape, or illegal reserved word: expect

You can safely comment out  "%expect 5" at line 103. It's just a warning
killer and for some unkown reason the solaris yacc doesn't seem to like
it (bison understands it and berkley yacc just ignores it).
If you want to compile with this yacc version (after removing %expect
from cfg.y), you would need to run something like:
make config YACC=/usr/ccs/bin/yacc



Andrei

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make kamailio on solaris 10

2010-06-02 Thread JinKevin


 

> Date: Wed, 2 Jun 2010 16:54:26 +0200
> From: and...@iptel.org
> To: kevin@hotmail.com
> CC: sr-users@lists.sip-router.org
> Subject: Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make 
> kamailio on solaris 10
> 
> On Jun 02, 2010 at 08:32, JinKevin  wrote:
> > 
> > 
> > 
> > Hi Andrei,
> > 
> > 
> > 
> > gcc -dM -E -x c /dev/null
> > #define __sparc__ 1
> > 
> [...]
> > 
> > 
> > isainfo -n
> > sparcv9
> > 
> > 
> > 
> > isainfo -b
> > 64
> > 
> > uname -m
> > sun4u
> 
> Now I remembered :-)
> The problem on sparcv9 is that you can build either sparc32 or sparc64
> code. The make system tries to use the configured compiler and use its
> default architecture, in this case sparc32.
> This changed from older ser or kamailio version, where IIRC
> 64 bits was always used on sparcv9 (the isainfo arch was used).
> The change was needed for better cross-compiler support, snow leopard
> (boots 32 bits kernel, but gcc is configured to produce 64 bit
> binaries).
> 
> So if you have all the needed 64 bits libs installed, you should compile
> for sparc64.
> Either make config CC_EXTRA_OPTS=-m64 or
> make config ARCH=sparc64
> should do it (don't forget to re-run it after any make proper).
> 
> 
> [...]
> > 
> > And bison is also installed, 
> > 
> > yacc -V 
> 
> 
> I couldn't reproduce the yacc/bison problem.
> For me it compiles flawlessly on an old sparcv9 (solaris 9, bison
> 1.875d).
> 
> Could you try running:
> yacc -d -b cfg cfg.y
> by hand and see what happens? (any error? cfg.tab.h and cfg.tab.c
> created?)
>

 

It just reports "Broken Pipe"

$ yacc -d -b cfg cfg.y
Broken Pipe

 

If I removed the bison , then got some other error as below:

$ yacc -d -b cfg cfg.y
"cfg.y", line 103: fatal: invalid escape, or illegal reserved word: expect


Thanks,

Kevin

  
_
SkyDrive电子画册,带你领略精彩照片,分享“美”时“美”刻!
http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] check_from and check_to: case sensitive?

2010-06-02 Thread Henning Westerholt
On Wednesday 02 June 2010, Iñaki Baz Castillo wrote:
> >> The problem is that more SIP username related stuff is also case
> >> insensitive in Kamailio, i.e. the database columns. For example a user
> >> "TEST" with a location entry with username "test" woudl be retrieved
> >> because the location.username column is case insensitive.
> >
> > IIRC that depends on the DB backend: MySQL is by default case
> > insensitive, Postgresql is by default case sensitive.
> 
> Yes, this is correct. Then:
> 
> - check_from / check_to should b fixed to use case sensitive comparison.

Hi Iñaki,

this should be properly documented, as it has the potential of breaking some 
configurations.
 
> - MySQL database schema should use case sensitive columns for
> 'username' in subscriber, location and any other tables containing an
> 'username' column.

I think we should think a bit more about this step, as it would be a major 
change in the way most people expect the database to work, which happens to be 
mostly mysql in our case. Add devel list as CC.

Henning

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] check_from and check_to: case sensitive?

2010-06-02 Thread Iñaki Baz Castillo
2010/6/1 Klaus Darilion :

>> The problem is that more SIP username related stuff is also case
>> insensitive in Kamailio, i.e. the database columns. For example a user
>> "TEST" with a location entry with username "test" woudl be retrieved
>> because the location.username column is case insensitive.
>
> IIRC that depends on the DB backend: MySQL is by default case insensitive,
> Postgresql is by default case sensitive.

Yes, this is correct. Then:

- check_from / check_to should b fixed to use case sensitive comparison.

- MySQL database schema should use case sensitive columns for
'username' in subscriber, location and any other tables containing an
'username' column.

Do I miss something?


-- 
Iñaki Baz Castillo


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] join the freeswitch public conference today to listen to daniel!

2010-06-02 Thread Meftah Tayeb

hi sr folk,
please join #freeswitch public weekly conference to listen to daniel, 
our guest about integration betwan freeswitch and kamailio

sip-URI: sip:8...@conference.freeswitch.org
iveryone is welcome to join!

--
Meftah Tayeb
algérie télécom SPA
phone: +21321761805
phone (INUM): +883510001289101
mobile : +213660347746
mobile (INUM: +883510001289110
http://www.algerietelecom.dz


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] [Kamailio-Business] Audio Conference: Kamailio and FreeSWTICH - Wed, June 2, 2010

2010-06-02 Thread Daniel-Constantin Mierla
quick update: the 1800UTC translates to 19:00 Central Europe Time, so 
the conference is starting like now.


Cheers,
Daniel


On 6/2/10 4:10 PM, Daniel-Constantin Mierla wrote:

Hello,

short reminder for those willing to join, just few hours till the 
start of audio conference.


Details to dial in at:

http://wiki.freeswitch.org/wiki/FS_weekly_2010_06_02

Cheers,
Daniel



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] gmake: *** [cfg.tab.h] Broken Pipe while make kamailio on solaris 10

2010-06-02 Thread Andrei Pelinescu-Onciul
On Jun 02, 2010 at 08:32, JinKevin  wrote:
> 
>  
> 
> Hi Andrei,
> 
>  
> 
>  gcc -dM -E -x c /dev/null
> #define __sparc__ 1
> 
[...]
>  
> 
> isainfo -n
> sparcv9
> 
>  
> 
> isainfo -b
> 64
> 
> uname -m
> sun4u

Now I remembered :-)
The problem on sparcv9 is that you can build either sparc32 or sparc64
code. The make system tries to use the configured compiler and use its
default architecture, in this case sparc32.
This changed from older ser or kamailio version, where IIRC
 64 bits was always used on sparcv9 (the isainfo arch was used).
The change was needed for better cross-compiler support, snow leopard
 (boots 32 bits kernel, but gcc is configured to produce 64 bit
 binaries).

So if you have all the needed 64 bits libs installed, you should compile
for sparc64.
Either make config CC_EXTRA_OPTS=-m64  or
   make config ARCH=sparc64
should do it (don't forget to re-run it after any make proper).


[...]
> 
> And bison is also installed, 
> 
>  yacc -V


I couldn't reproduce the yacc/bison problem.
For me it compiles flawlessly on an old sparcv9 (solaris 9, bison
1.875d).

Could you try running:
yacc -d -b cfg cfg.y
by hand and see what happens? (any error? cfg.tab.h and cfg.tab.c
created?)


Andrei

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Juha Heinanen
Daniel-Constantin Mierla writes:

> I think Juha added a new way lately, to encode/decode source ip/port in 
> the contact uri.

yes, but that only replaces with fix_nated_contact and can be used if
someone wants to re-use tcp connections between proxy and UAs and wants
to always deliver to UAs correct request-uris.  tutorial is here:

http://sip-router.org/wiki/tutorials/alias-example

-- juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Daniel-Constantin Mierla



On 6/2/10 4:01 PM, Andrei Pelinescu-Onciul wrote:

On Jun 02, 2010 at 15:35, Daniel-Constantin Mierla  wrote:
   


On 6/2/10 3:00 PM, Andrei Pelinescu-Onciul wrote:
 

[...]
   

On 6/1/10 9:07 PM, Alex Balashov wrote:
 

No, it'll store the fixed one, in the proper contact column, not the
received column. I do this all the time, even though it's not the
"proper" way.
   

should be the original one with the last version, afaik. There were
issues with phones accepting calls which had a different uri than the
address they set in contact of register.

So, the contact details were brocken in:
- contact - the address from header
- received - built from source ip and port
- socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and
fix_nated_registrar().
 

I know. I always use fix_nated_register. I just wonder why save()
saves the fixed contact in case of fix_nated_contact(), because
usually we have the problem that changes to the message are only
visible when the message is forwarded (lumps are applied)

   

but are you sure the fixed contact is saved? I quick look in the
registrar code seems to take the contact from headers, which are
pointing inside original message.
 

I just tested with kamailio 3.0 and you are right. Yesterday I tested
with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
contact header - strange.
   

I have to correct myself - I made an error during the test. Kamailio
3.0 with fix_nated_contact() saves the fixed contact URI (see
below).
 

In all versions (older ser, ser, sip-router, kamailio), the changes done
by fix_nated_contact() will be visible when the contact is save()'d.
fix_nated_contact() directly modifies the parsed contact, which is then
used by save().

fix_nated_register() behaves differently. In older ser version and in
kamailio it sets and avp with the received information. This avp is then
checked by save() and used as received info.
In newer ser versions and sip-router modules_s/nathelper  it adds
a received=... parameter to each contact (it doesn't set any avp).
In this case save() will generate itself the received uri if the message
is flagged as coming from before a NAT. save() from modules_s/registrar
and newer sers, doesn't need fix_nated_register(), it only needs that the
message was properly flagged in the script. It will also not look at any
avp.
ser's fix_nated_register() is used for replicated REGISTERs or when the
outbound proxy is not also the registrar. It will add a "received="
parameter to each contact and the non-local registrar
(or the replication peer) can use it to recover the original ip:port.
   

Interesting, thanks for these details. I never used
fix_nated_contact() for REGISTER as fix_nated_registrar() is the
natural way for me. You saved me some time to dig in the sources.

To understand that fix_nated_contact() translates the pointers to
the new lump? If yes, that means the PVs for contact go there as
well.
 

It does  c->uri.s = buf, where buf is pkg_malloc'ed and contains the
  "fixed" uri (and it's used also in insert_new_lump_after()).

I wouldn't use fix_nated_contact() for REGISTERs, but sometimes it's
  useful to fix contacts in dialogs.

   

for dialogs is used indeed. Default K config has it to fix natted calls.

I think Juha added a new way lately, to encode/decode source ip/port in 
the contact uri.


Cheers,
Daniel

--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] [Kamailio-Business] Audio Conference: Kamailio and FreeSWTICH - Wed, June 2, 2010

2010-06-02 Thread Daniel-Constantin Mierla

Hello,

short reminder for those willing to join, just few hours till the start 
of audio conference.


Details to dial in at:

http://wiki.freeswitch.org/wiki/FS_weekly_2010_06_02

Cheers,
Daniel


On 5/30/10 7:55 PM, Daniel-Constantin Mierla wrote:

Hello,

next Wednesday (June 2, 2010), at 18:00UTC, I will participate to 
FreeSWITCH weekly conference call, talking about using Kamailio and 
FreeSWITCH together.


The draft of agenda is:

* Goals of Kamailio, how it differentiates from FreeSWITCH and why 
using them together creates a very powerful framework to build large 
VoIP systems.
* Kamailio for sip routing and FreeSWITCH as media server 
(conferencing, voicemail, IVR, announcements)
* FreeSWITCH as a B2BUA for Kamailio (topology hiding, 
transcoding, call interrupt detection)

* FreeSWITCH as prepaid engine for Kamailio
* Load balancing FreeSWITCH servers with Kamailio

Is an open debate, join and ask your questions. You can dial in via 
SIP, Skype, PSTN, see access details at:


http://wiki.freeswitch.org/wiki/FS_weekly_2010_06_02

Cheers,
Daniel




--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Andrei Pelinescu-Onciul
On Jun 02, 2010 at 15:35, Daniel-Constantin Mierla  wrote:
> 
> 
> On 6/2/10 3:00 PM, Andrei Pelinescu-Onciul wrote:
> >[...]
> >>
> >>On 6/1/10 9:07 PM, Alex Balashov wrote:
> >>>No, it'll store the fixed one, in the proper contact column, not the
> >>>received column. I do this all the time, even though it's not the
> >>>"proper" way.
> >>should be the original one with the last version, afaik. There were
> >>issues with phones accepting calls which had a different uri than the
> >>address they set in contact of register.
> >>
> >>So, the contact details were brocken in:
> >>- contact - the address from header
> >>- received - built from source ip and port
> >>- socket - local socket where the register was received
> >>
> >>Note that there are two functions, fix_nated_contact() and
> >>fix_nated_registrar().
> >I know. I always use fix_nated_register. I just wonder why save()
> >saves the fixed contact in case of fix_nated_contact(), because
> >usually we have the problem that changes to the message are only
> >visible when the message is forwarded (lumps are applied)
> >
> but are you sure the fixed contact is saved? I quick look in the
> registrar code seems to take the contact from headers, which are
> pointing inside original message.
> >>>I just tested with kamailio 3.0 and you are right. Yesterday I tested
> >>>with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
> >>>contact header - strange.
> >>I have to correct myself - I made an error during the test. Kamailio
> >>3.0 with fix_nated_contact() saves the fixed contact URI (see
> >>below).
> >In all versions (older ser, ser, sip-router, kamailio), the changes done
> >by fix_nated_contact() will be visible when the contact is save()'d.
> >fix_nated_contact() directly modifies the parsed contact, which is then
> >used by save().
> >
> >fix_nated_register() behaves differently. In older ser version and in
> >kamailio it sets and avp with the received information. This avp is then
> >checked by save() and used as received info.
> >In newer ser versions and sip-router modules_s/nathelper  it adds
> >a received=... parameter to each contact (it doesn't set any avp).
> >In this case save() will generate itself the received uri if the message
> >is flagged as coming from before a NAT. save() from modules_s/registrar
> >and newer sers, doesn't need fix_nated_register(), it only needs that the
> >message was properly flagged in the script. It will also not look at any
> >avp.
> >ser's fix_nated_register() is used for replicated REGISTERs or when the
> >outbound proxy is not also the registrar. It will add a "received="
> >parameter to each contact and the non-local registrar
> >(or the replication peer) can use it to recover the original ip:port.
> Interesting, thanks for these details. I never used
> fix_nated_contact() for REGISTER as fix_nated_registrar() is the
> natural way for me. You saved me some time to dig in the sources.
> 
> To understand that fix_nated_contact() translates the pointers to
> the new lump? If yes, that means the PVs for contact go there as
> well.

It does  c->uri.s = buf, where buf is pkg_malloc'ed and contains the
 "fixed" uri (and it's used also in insert_new_lump_after()).

I wouldn't use fix_nated_contact() for REGISTERs, but sometimes it's
 useful to fix contacts in dialogs.


Andrei

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Daniel-Constantin Mierla



On 6/2/10 3:00 PM, Andrei Pelinescu-Onciul wrote:

[...]


On 6/1/10 9:07 PM, Alex Balashov wrote:
 

No, it'll store the fixed one, in the proper contact column, not the
received column. I do this all the time, even though it's not the
"proper" way.
   

should be the original one with the last version, afaik. There were
issues with phones accepting calls which had a different uri than the
address they set in contact of register.

So, the contact details were brocken in:
- contact - the address from header
- received - built from source ip and port
- socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and
fix_nated_registrar().
 

I know. I always use fix_nated_register. I just wonder why save()
saves the fixed contact in case of fix_nated_contact(), because
usually we have the problem that changes to the message are only
visible when the message is forwarded (lumps are applied)

   

but are you sure the fixed contact is saved? I quick look in the
registrar code seems to take the contact from headers, which are
pointing inside original message.
 

I just tested with kamailio 3.0 and you are right. Yesterday I tested
with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
contact header - strange.
   

I have to correct myself - I made an error during the test. Kamailio
3.0 with fix_nated_contact() saves the fixed contact URI (see
below).
 

In all versions (older ser, ser, sip-router, kamailio), the changes done
by fix_nated_contact() will be visible when the contact is save()'d.
fix_nated_contact() directly modifies the parsed contact, which is then
used by save().

fix_nated_register() behaves differently. In older ser version and in
kamailio it sets and avp with the received information. This avp is then
checked by save() and used as received info.
In newer ser versions and sip-router modules_s/nathelper  it adds
a received=... parameter to each contact (it doesn't set any avp).
In this case save() will generate itself the received uri if the message
is flagged as coming from before a NAT. save() from modules_s/registrar
and newer sers, doesn't need fix_nated_register(), it only needs that the
message was properly flagged in the script. It will also not look at any
avp.
ser's fix_nated_register() is used for replicated REGISTERs or when the
outbound proxy is not also the registrar. It will add a "received="
parameter to each contact and the non-local registrar
(or the replication peer) can use it to recover the original ip:port.
   
Interesting, thanks for these details. I never used fix_nated_contact() 
for REGISTER as fix_nated_registrar() is the natural way for me. You 
saved me some time to dig in the sources.


To understand that fix_nated_contact() translates the pointers to the 
new lump? If yes, that means the PVs for contact go there as well.


Cheers,
Daniel

--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Andrei Pelinescu-Onciul
On Jun 02, 2010 at 10:58, Klaus Darilion  wrote:
> 
> 
> Am 02.06.2010 10:46, schrieb Klaus Darilion:
> >
> >
> >Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:
> >>
> >>
> >>On 6/1/10 10:02 PM, Klaus Darilion wrote:
> >>>Daniel-Constantin Mierla wrote:
> 
> 
> On 6/1/10 9:07 PM, Alex Balashov wrote:
> >No, it'll store the fixed one, in the proper contact column, not the
> >received column. I do this all the time, even though it's not the
> >"proper" way.
> should be the original one with the last version, afaik. There were
> issues with phones accepting calls which had a different uri than the
> address they set in contact of register.
> 
> So, the contact details were brocken in:
> - contact - the address from header
> - received - built from source ip and port
> - socket - local socket where the register was received
> 
> Note that there are two functions, fix_nated_contact() and
> fix_nated_registrar().
> >>>
> >>>I know. I always use fix_nated_register. I just wonder why save()
> >>>saves the fixed contact in case of fix_nated_contact(), because
> >>>usually we have the problem that changes to the message are only
> >>>visible when the message is forwarded (lumps are applied)
> >>>
> >>but are you sure the fixed contact is saved? I quick look in the
> >>registrar code seems to take the contact from headers, which are
> >>pointing inside original message.
> >
> >I just tested with kamailio 3.0 and you are right. Yesterday I tested
> >with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
> >contact header - strange.
> 
> I have to correct myself - I made an error during the test. Kamailio
> 3.0 with fix_nated_contact() saves the fixed contact URI (see
> below).

In all versions (older ser, ser, sip-router, kamailio), the changes done
by fix_nated_contact() will be visible when the contact is save()'d.
fix_nated_contact() directly modifies the parsed contact, which is then
used by save().

fix_nated_register() behaves differently. In older ser version and in
kamailio it sets and avp with the received information. This avp is then
checked by save() and used as received info.
In newer ser versions and sip-router modules_s/nathelper  it adds
a received=... parameter to each contact (it doesn't set any avp).
In this case save() will generate itself the received uri if the message
is flagged as coming from before a NAT. save() from modules_s/registrar
and newer sers, doesn't need fix_nated_register(), it only needs that the
message was properly flagged in the script. It will also not look at any
avp.
ser's fix_nated_register() is used for replicated REGISTERs or when the
outbound proxy is not also the registrar. It will add a "received="
parameter to each contact and the non-local registrar 
(or the replication peer) can use it to recover the original ip:port.


Andrei

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Daniel-Constantin Mierla



On 6/2/10 10:58 AM, Klaus Darilion wrote:



Am 02.06.2010 10:46, schrieb Klaus Darilion:



Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:



On 6/1/10 10:02 PM, Klaus Darilion wrote:

Daniel-Constantin Mierla wrote:



On 6/1/10 9:07 PM, Alex Balashov wrote:

No, it'll store the fixed one, in the proper contact column, not the
received column. I do this all the time, even though it's not the
"proper" way.

should be the original one with the last version, afaik. There were
issues with phones accepting calls which had a different uri than the
address they set in contact of register.

So, the contact details were brocken in:
- contact - the address from header
- received - built from source ip and port
- socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and
fix_nated_registrar().


I know. I always use fix_nated_register. I just wonder why save()
saves the fixed contact in case of fix_nated_contact(), because
usually we have the problem that changes to the message are only
visible when the message is forwarded (lumps are applied)


but are you sure the fixed contact is saved? I quick look in the
registrar code seems to take the contact from headers, which are
pointing inside original message.


I just tested with kamailio 3.0 and you are right. Yesterday I tested
with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
contact header - strange.


I have to correct myself - I made an error during the test. Kamailio 
3.0 with fix_nated_contact() saves the fixed contact URI (see below).


I will do some tests and look at it later. I checked my devel server and 
when using fix_nated_registrar() (like in default config) it is the 
address from contact header...


Thanks,
Daniel



regards
Klaus


U 2010/06/02 10:54:44.731304 83.136.33.3:46772 -> 83.136.32.159:5060
REGISTER sip:labs.nic.at SIP/2.0
Via: SIP/2.0/UDP 
10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport

Max-Forwards: 70
Contact: 
 


To: 
From: ;tag=59004f11
Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM.
CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, 
SUBSCRIBE, INFO

Content-Length: 0

U 2010/06/02 10:54:44.731304 83.136.32.159:5060 -> 83.136.33.3:46772
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport=46772;received=83.136.33.3 

To: 
;tag=5fcf32020f171aefa0445747f7988cba.e233 


From: ;tag=59004f11
Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM.
CSeq: 2 REGISTER
Contact: 
;expires=60 


Server: kamailio (3.0.1 (i386/linux))
Content-Length: 0




# kamctl ul show
Domain:: location table=512 records=1 max_slot=1
Contact:: 
sip:klaus.daril...@83.136.33.3:46772;rinstance=cdb12231d83fce68 Q=

Expires:: 54
Callid:: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3OD
Cseq:: 2
User-agent:: eyeBeam release 1102q stamp 51814
State:: CS_SYNC
Flags:: 0
Cflag:: 64
Socket:: udp:83.136.32.159:5060
Methods:: 5087






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Klaus Darilion



Am 02.06.2010 10:46, schrieb Klaus Darilion:



Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:



On 6/1/10 10:02 PM, Klaus Darilion wrote:

Daniel-Constantin Mierla wrote:



On 6/1/10 9:07 PM, Alex Balashov wrote:

No, it'll store the fixed one, in the proper contact column, not the
received column. I do this all the time, even though it's not the
"proper" way.

should be the original one with the last version, afaik. There were
issues with phones accepting calls which had a different uri than the
address they set in contact of register.

So, the contact details were brocken in:
- contact - the address from header
- received - built from source ip and port
- socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and
fix_nated_registrar().


I know. I always use fix_nated_register. I just wonder why save()
saves the fixed contact in case of fix_nated_contact(), because
usually we have the problem that changes to the message are only
visible when the message is forwarded (lumps are applied)


but are you sure the fixed contact is saved? I quick look in the
registrar code seems to take the contact from headers, which are
pointing inside original message.


I just tested with kamailio 3.0 and you are right. Yesterday I tested
with ser 0.9.? and fix_nated_contact() seemed to save the rewritten
contact header - strange.


I have to correct myself - I made an error during the test. Kamailio 3.0 
with fix_nated_contact() saves the fixed contact URI (see below).


regards
Klaus


U 2010/06/02 10:54:44.731304 83.136.33.3:46772 -> 83.136.32.159:5060
REGISTER sip:labs.nic.at SIP/2.0
Via: SIP/2.0/UDP 
10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport

Max-Forwards: 70
Contact: 


To: 
From: ;tag=59004f11
Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM.
CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, 
SUBSCRIBE, INFO

Content-Length: 0

U 2010/06/02 10:54:44.731304 83.136.32.159:5060 -> 83.136.33.3:46772
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport=46772;received=83.136.33.3
To: 
;tag=5fcf32020f171aefa0445747f7988cba.e233

From: ;tag=59004f11
Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM.
CSeq: 2 REGISTER
Contact: 
;expires=60

Server: kamailio (3.0.1 (i386/linux))
Content-Length: 0




# kamctl ul show
Domain:: location table=512 records=1 max_slot=1
Contact:: 
sip:klaus.daril...@83.136.33.3:46772;rinstance=cdb12231d83fce68 Q=

Expires:: 54
Callid:: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3OD
Cseq:: 2
User-agent:: eyeBeam release 1102q stamp 51814
State:: CS_SYNC
Flags:: 0
Cflag:: 64
Socket:: udp:83.136.32.159:5060
Methods:: 5087






___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] fix_nated_contact() on REGISTER

2010-06-02 Thread Klaus Darilion



Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:



On 6/1/10 10:02 PM, Klaus Darilion wrote:

Daniel-Constantin Mierla wrote:



On 6/1/10 9:07 PM, Alex Balashov wrote:

No, it'll store the fixed one, in the proper contact column, not the
received column. I do this all the time, even though it's not the
"proper" way.

should be the original one with the last version, afaik. There were
issues with phones accepting calls which had a different uri than the
address they set in contact of register.

So, the contact details were brocken in:
- contact - the address from header
- received - built from source ip and port
- socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and
fix_nated_registrar().


I know. I always use fix_nated_register. I just wonder why save()
saves the fixed contact in case of fix_nated_contact(), because
usually we have the problem that changes to the message are only
visible when the message is forwarded (lumps are applied)


but are you sure the fixed contact is saved? I quick look in the
registrar code seems to take the contact from headers, which are
pointing inside original message.


I just tested with kamailio 3.0 and you are right. Yesterday I tested 
with ser 0.9.? and fix_nated_contact() seemed to save the rewritten 
contact header - strange.


Thanks
klaus

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users