[SR-Users] Regd. Stored procedure support in Kamailio

[Shankar]

Hello All,

 

Does Kamailio support invoking stored procedures instead of sending plain DB
queries already? 

 

We have been asked to migrate to stored procedures. I am trying to estimate
the effort involved in migrating Kamailio code to support stored procedure. 

 

Other question that comes to my mind is whether stored procedures are really
needed in Kamailio. Can someone please clarify?

 

Regards,

Shankar



___
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] sqlops crash after out of memory

[Juha Heinanen]

pkg memory run out here:

Mar  4 09:00:20 localhost /usr/sbin/sip-proxy[31923]: ERROR: sqlops 
[sql_api.c:318]: sql_do_query(): no more memory

then sip proxy crashed here:

(gdb) where
#0  0xb5fce89b in sql_reset_result (res=0xb6ce3438) at sql_api.c:233
#1  0xb5fd18db in sql_do_query (con=0xb6cd1e28, query=0xbfecd248, 
res=0xb6ce3438) at sql_api.c:410
#2  0xb5fd630d in sql_query (msg=0xb6ce8788, dbl=0xb6cd1e28 "\230\035Ͷ\t", 
query=0xb70436a8 "\310Y\004\267P", res=0xb6ce3438 "\245\246=|\r3ζ\006") at 
sqlops.c:209
...

goto error was executed when if(res->vals[i]==NULL) was true and at
error sql_reset_result was called.  there the crash happened here:

if(res->vals)
{
for(i=0; inrows; i++)
{
for(j=0; jncols; j++)
{
if(res->vals[i][j].flags&PV_VAL_STR
&& 
res->vals[i][j].value.s.len>0)  /* here */

looks to me that it should be tested if res->vals[i] is not null before
executing the if statement.

-- juha

ps. it there any chance to find out from the core dump, why memory run
out, i.e., how was most of it used?  amount of pkg memory in this host
was defined to be 8 MB.

-- 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] p-cscf - out of mem

[Jason Penton]

Thanks Daniel,

How much pkg and shm memory is assigned to your Kamailio instance? Also,
how many users are you registering concurrently? Please also recreate and
dump shm memory when you get a chance. If you are not sure how to dump shm
memory - see here -
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory

Cheers
Jason


On Mon, Mar 3, 2014 at 11:07 PM, Daniel Ciprus wrote:

>  Jason,
>
> HW configuration : this is a virtual machine running 4 cores with 24GB ram
> (VM hosting).
>
> processor   : 3
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 26
> model name  : Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz
> stepping: 4
> cpu MHz : 2900.000
> cache size  : 15360 KB
> fpu : yes
> fpu_exception   : yes
> cpuid level : 11
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm
> constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc
> aperfmperf unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor
> lahf_lm ida arat epb pln pts dts
> bogomips: 5800.00
> clflush size: 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
>
> As far as scenario: it's a mixture of REGISTER/MESSAGE/SUBSCRIBE/NOTIFY. I
> will send logs (configs + /var/log/messages) privately .. but generally
> speaking config is almost identical with configs from samples directory for
> p-cscf.
>
> Dan
>
>
>
> On 03/03/2014 04:02 PM, Jason Penton wrote:
>
> Hi Daniel,
>
>  no we have not seen that... Can you provide details around the scenario
> - registration, calling, mixture, etc? Load? We have done extensive testing
> especially w.r.t. memory usage so I am very interested in this. Could you
> do a memory dump and send us the log?
>
>  Also, will you share your cfg file? you can send the cfg file directly
> to me if you prefer...
>
>  Cheers
> Jason
>
>
> On Mon, Mar 3, 2014 at 10:58 PM, Daniel Ciprus 
> wrote:
>
>> Hi,
>>
>> Has anybody seen this :
>>
>> Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: 
>> [msg_translator.c:2011]: generate_res_buf_from_sip_res(): *out of mem*
>> Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]:
>> relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
>>
>> followed by:
>>
>> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: 
>> [msg_translator.c:2011]: generate_res_buf_from_sip_res(): *out of mem*
>> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]:
>> relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
>> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: 
>> [msg_translator.c:2168]: build_res_buf_from_sip_req(): *ERROR:
>> build_res_buf_from_sip_req: out of memory  ; needs 386*
>>
>> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
>> [parser/contact/contact.c:194]: parse_contacts(): parse_contacts(): *No
>> memory left*
>> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
>> [parser/contact/parse_contact.c:59]: contact_parser(): contact_parser():
>> Error while parsing contacts
>> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
>> [parser/contact/parse_contact.c:88]: parse_contact(): parse_contact():
>> Error while parsing
>>
>>
>> However, seems like we still had enough mem:
>>
>> [root@kamailio kamailio]# vmstat 1
>> procs ---memory-- ---swap-- -io --system--
>> -cpu-
>>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy
>> id wa st
>>  3  0  0 9526348 230308 1328247200 0 401  6
>> 0 94  0  0
>>  1  0  0 9526216 230308 1328252400 0 0 1313 84424 17
>> 8 75  0  0
>>  1  0  0 9526092 230308 1328261600 0 0 1482 86882 16
>> 9 75  0  0
>>
>> [root@kamailio monit.d]# kamailio -v
>> version: kamailio 4.2.0-dev0 (x86_64/linux)
>> flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: unknown
>> compiled on 17:42:42 Dec 18 2013 with gcc 4.4.7
>>
>> Unfortunately I had to reload p-cscf to get service working again.
>>
>> --
>> *Daniel Ciprus*
>> Integration engineer
>> http://www.acision.com
>>
>> 9954 Mayland Dr
>> Suite 3100
>> Richmond, VA 23233
>> USA
>> T: +1 804 762 5601
>> E: daniel.cip...@acision.com
>>
>> --
>> This e-mail and any attachment is for authorised use by the intended
>> recipient(s) only. It may contain proprietary material, confidential
>> information and/or be subject to legal privilege. It should

Re: [SR-Users] p-cscf - out of mem

[Daniel Ciprus]

Jason,

HW configuration : this is a virtual machine running 4 cores with 24GB ram (VM 
hosting).

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 26
model name  : Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz
stepping: 4
cpu MHz : 2900.000
cache size  : 15360 KB
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc 
arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf 
unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida arat 
epb pln pts dts
bogomips: 5800.00
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

As far as scenario: it's a mixture of REGISTER/MESSAGE/SUBSCRIBE/NOTIFY. I will 
send logs (configs + /var/log/messages) privately .. but generally speaking 
config is almost identical with configs from samples directory for p-cscf.

Dan


On 03/03/2014 04:02 PM, Jason Penton wrote:
Hi Daniel,

no we have not seen that... Can you provide details around the scenario - 
registration, calling, mixture, etc? Load? We have done extensive testing 
especially w.r.t. memory usage so I am very interested in this. Could you do a 
memory dump and send us the log?

Also, will you share your cfg file? you can send the cfg file directly to me if 
you prefer...

Cheers
Jason


On Mon, Mar 3, 2014 at 10:58 PM, Daniel Ciprus 
mailto:daniel.cip...@acision.com>> wrote:
Hi,

Has anybody seen this :

Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2011]: generate_res_buf_from_sip_res(): out of mem
Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]: 
relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer

followed by:

Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2011]: generate_res_buf_from_sip_res(): out of mem
Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]: 
relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2168]: build_res_buf_from_sip_req(): ERROR: 
build_res_buf_from_sip_req: out of memory  ; needs 386

Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/contact.c:194]: parse_contacts(): parse_contacts(): No memory left
Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/parse_contact.c:59]: contact_parser(): contact_parser(): Error while 
parsing contacts
Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/parse_contact.c:88]: parse_contact(): parse_contact(): Error while 
parsing


However, seems like we still had enough mem:

[root@kamailio kamailio]# vmstat 1
procs ---memory-- ---swap-- -io --system-- -cpu-
r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
3  0  0 9526348 230308 1328247200 0 401  6  0 94  0 
 0
1  0  0 9526216 230308 1328252400 0 0 1313 84424 17  8 75  
0  0
1  0  0 9526092 230308 1328261600 0 0 1482 86882 16  9 75  
0  0

[root@kamailio monit.d]# kamailio -v
version: kamailio 4.2.0-dev0 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, 
USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, 
USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, 
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 17:42:42 Dec 18 2013 with gcc 4.4.7

Unfortunately I had to reload p-cscf to get service working again.

--
Daniel Ciprus
Integration engineer
http://www.acision.com

9954 Mayland Dr
Suite 3100
Richmond, VA 23233
USA
T: +1 804 762 5601
E: daniel.cip...@acision.com


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you for understanding.


___
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




--


Jason Penton
Senior Manager: Applications and Services
Smile Communications Pty (Ltd)
Mobile: +27 (0) 83 283 7000
Skype: 

Re: [SR-Users] p-cscf - out of mem

[Jason Penton]

Hi Daniel,

no we have not seen that... Can you provide details around the scenario -
registration, calling, mixture, etc? Load? We have done extensive testing
especially w.r.t. memory usage so I am very interested in this. Could you
do a memory dump and send us the log?

Also, will you share your cfg file? you can send the cfg file directly to
me if you prefer...

Cheers
Jason


On Mon, Mar 3, 2014 at 10:58 PM, Daniel Ciprus wrote:

>  Hi,
>
> Has anybody seen this :
>
> Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: 
> [msg_translator.c:2011]: generate_res_buf_from_sip_res(): *out of mem*
> Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]:
> relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
>
> followed by:
>
> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: 
> [msg_translator.c:2011]: generate_res_buf_from_sip_res(): *out of mem*
> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]:
> relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
> Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: 
> [msg_translator.c:2168]: build_res_buf_from_sip_req(): *ERROR:
> build_res_buf_from_sip_req: out of memory  ; needs 386*
>
> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
> [parser/contact/contact.c:194]: parse_contacts(): parse_contacts(): *No
> memory left*
> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
> [parser/contact/parse_contact.c:59]: contact_parser(): contact_parser():
> Error while parsing contacts
> Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR: 
> [parser/contact/parse_contact.c:88]: parse_contact(): parse_contact():
> Error while parsing
>
>
> However, seems like we still had enough mem:
>
> [root@kamailio kamailio]# vmstat 1
> procs ---memory-- ---swap-- -io --system--
> -cpu-
>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
> wa st
>  3  0  0 9526348 230308 1328247200 0 401  6  0
> 94  0  0
>  1  0  0 9526216 230308 1328252400 0 0 1313 84424 17
> 8 75  0  0
>  1  0  0 9526092 230308 1328261600 0 0 1482 86882 16
> 9 75  0  0
>
> [root@kamailio monit.d]# kamailio -v
> version: kamailio 4.2.0-dev0 (x86_64/linux)
> flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled on 17:42:42 Dec 18 2013 with gcc 4.4.7
>
> Unfortunately I had to reload p-cscf to get service working again.
>
> --
> *Daniel Ciprus*
> Integration engineer
> http://www.acision.com
>
> 9954 Mayland Dr
> Suite 3100
> Richmond, VA 23233
> USA
> T: +1 804 762 5601
> E: daniel.cip...@acision.com
>
> --
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you for
> understanding.
>
>
> ___
> 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
>
>


-- 

*Jason Penton**Senior Manager: Applications and Services**Smile
Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:*
jason.barry.pentonjason.pen...@smilecoms.com 
www.smilecoms.com

-- 


This email is subject to the disclaimer of Smile Communications at 
http://www.smilecoms.com/home/email-disclaimer/ 


___
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] p-cscf - out of mem

[Daniel Ciprus]

Hi,

Has anybody seen this :

Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2011]: generate_res_buf_from_sip_res(): out of mem
Mar  2 17:25:16 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]: 
relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer

followed by:

Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2011]: generate_res_buf_from_sip_res(): out of mem
Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR: tm [t_reply.c:1943]: 
relay_reply(): ERROR: relay_reply: no mem for outbound reply buffer
Mar  2 17:27:03 kamailio kam-pcscf[20741]: ERROR:  
[msg_translator.c:2168]: build_res_buf_from_sip_req(): ERROR: 
build_res_buf_from_sip_req: out of memory  ; needs 386

Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/contact.c:194]: parse_contacts(): parse_contacts(): No memory left
Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/parse_contact.c:59]: contact_parser(): contact_parser(): Error while 
parsing contacts
Mar  2 17:27:53 kamailio kam-pcscf[20741]: ERROR:  
[parser/contact/parse_contact.c:88]: parse_contact(): parse_contact(): Error while 
parsing


However, seems like we still had enough mem:

[root@kamailio kamailio]# vmstat 1
procs ---memory-- ---swap-- -io --system-- -cpu-
r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
3  0  0 9526348 230308 1328247200 0 401  6  0 94  0 
 0
1  0  0 9526216 230308 1328252400 0 0 1313 84424 17  8 75  
0  0
1  0  0 9526092 230308 1328261600 0 0 1482 86882 16  9 75  
0  0

[root@kamailio monit.d]# kamailio -v
version: kamailio 4.2.0-dev0 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, 
USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, 
USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, 
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 17:42:42 Dec 18 2013 with gcc 4.4.7

Unfortunately I had to reload p-cscf to get service working again.

--
Daniel Ciprus
Integration engineer
http://www.acision.com

9954 Mayland Dr
Suite 3100
Richmond, VA 23233
USA
T: +1 804 762 5601
E: daniel.cip...@acision.com


This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you for understanding.

___
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] geoip crash

[Juha Heinanen]

Daniel-Constantin Mierla writes:

> No, but you can do it and if all goes fine, it can be pushed to remote 
> repository. I don't have a geoip deployment at hand these days.

i backported the patch to my 4.1 source and still got a crash (i don't
remember if this is the same or new one).

-- juha

Program terminated with signal 11, Segmentation fault.
#0  pv_get_geoip (msg=0xb72316a4, param=0xb6fe0ce4, res=0xbfb622fc)
at geoip_pv.c:332
332 return pv_geoip_get_strzval(msg, param, res,
(gdb) where
#0  pv_get_geoip (msg=0xb72316a4, param=0xb6fe0ce4, res=0xbfb622fc)
at geoip_pv.c:332
#1  0x080d7714 in pv_get_spec_value (msg=0xb72316a4, sp=0xb6fe0cd8, 
value=0xbfb622fc) at pvapi.c:1266
#2  0x080a6841 in lval_pvar_assign (h=0xbfb6272c, msg=0xb72316a4, 
lv=0xb6fe097c, rv=0xb6fe0cd0) at lvalue.c:345
#3  0x080a6ecc in lval_assign (h=0xbfb6272c, msg=0xb72316a4, lv=0xb6fe097c, 
rve=0xb6fe0ccc) at lvalue.c:410
#4  0x080665e3 in do_action (h=0xbfb6272c, a=0xb6fe1080, msg=0xb72316a4)
at action.c:1478
#5  0x08067293 in run_actions (h=0xbfb6272c, a=0xb6fe1080, msg=0xb72316a4)
at action.c:1599
#6  0x0806797a in run_top_route (a=0xb6fe1080, msg=0xb72316a4, c=0x0)
at action.c:1685
#7  0x080e2973 in receive_msg (
buf=0x9df95e8 "REGISTER sip:test.tutpro.com SIP/2.0\r\nVia: SIP/2.0/TCP 
192.98.102.30:5064;branch=z9hG4bK7db1d82ab09c855c;rport\r\nContact: 
;expires=600;+sip.instance=\";expires=600;+sip.instance=\"http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] geoip crash

[Daniel-Constantin Mierla]

On 03/03/14 19:29, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:


Not clear for me -- have you tested with 4.1 and all is ok?

i thought that you didn't cherry pick the commit to 4.1 yet.
No, but you can do it and if all goes fine, it can be pushed to remote 
repository. I don't have a geoip deployment at hand these days.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


___
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] geoip crash

[Juha Heinanen]

Daniel-Constantin Mierla writes:

> Not clear for me -- have you tested with 4.1 and all is ok?

i thought that you didn't cherry pick the commit to 4.1 yet.

-- 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] REGISTER failure_route 401 problem

[Marc Soda]

On Mon, Mar 3, 2014 at 12:24 PM, Daniel-Constantin Mierla  wrote:

>
> On 03/03/14 18:08, Marc Soda wrote:
>
> I resolved the issue, but I not quite sure why is worked.  Rather than
> sending the REGISTER with t_reply()
>
>
> t_reply() is not sending REGISTER anywhere, it is sending a reply (sip
> response) for a request.
>

Oops, I meant t_relay().  I forwarded the register by calling
on_failure_route(), then route(RELAY), rather than on_failure_route(), then
t_relay().  I realize that route(RELAY) eventually calls t_relay(), I'm
just not sure why that fixed the issue.


>
> In short, be sure you set the appropriate failure route for the request
> and forward it with t_relay().
>
> Cheers,
> Daniel
>
>
>  , I changed it to call route(RELAY) which does this:
>
>  route[RELAY] {
>   xlog("L_NOTICE","route[RELAY] ($rm)\n");
>
>   if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
> if (!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
>   }
>
>   if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
> if (!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
>   }
>
>   if (is_method("INVITE")) {
> if (!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
>   }
>
>   xlog("L_NOTICE","t_relay()'ing ($rm)\n");
>
>   if (!t_relay()) {
> sl_reply_error();
>   }
>   exit;
> }
>
>  I thought that maybe the issue was that I was getting a 100 TRYING right
> before the 401, and maybe I needed to setup a reply route as well.
>  However, as you can see above, MANAGE_REPLY isn't set for REGISTERs.  Why
> did this fix the problem?
>
>  Marc
>
> On Mon, Mar 3, 2014 at 11:52 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>>  Are you sure you have set t_on_failure() for the respective transaction?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 03/03/14 17:44, Marc Soda wrote:
>>
>>  So I've found out that NAT has nothing to do with it.  The bit about
>> things working when the NAT device is removed was wrong.
>>
>>  So my question becomes:  Why would Kamailio ignore a 401 rather sending
>> it to a failure route?
>>
>>  Thanks in advance,
>> Marc
>>
>>
>> On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda  wrote:
>>
>>> I forget to mention, the nat device is in front of the Kamailio servers,
>>> not the endpoints.
>>>
>>>
>>> On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda  wrote:
>>>
 I have a Kamailio server setup which is registers to a back end server
 on behalf of endpoints.  The endpoints can register to Kamailio but
 Kamailio is failing to register to the server when I put a NAT device in
 front of it.  Without the NAT device it works fine.

  The problem is the 401 that comes back seems to be ignored by
 Kamailio.  I have a failure route setup to auth, but it is never hit.  I
 see the 401 in onrely_route, but not the failure_route.  I'm assuming it's
 a NAT issue because removing the device fixes the issue.

  Anyone have any ideas?

  The 401 being ignored:

  SIP/2.0 401 Unauthorized
  Via: SIP/2.0/UDP
 10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
 Via: SIP/2.0/UDP 127.0.0.1:12354
 ;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
 From: ;tag=1
 To: ;tag=as00e32130
 Call-ID: 1-1879@127.0.0.1
 CSeq: 2 REGISTER
 User-Agent: CoreDialPBX
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
  Supported: replaces
 WWW-Authenticate: Digest algorithm=MD5, realm="fe-c7c5-9o.domain.com",
 nonce="151e4f60"
 Content-Length: 0

  Thanks,
 Marc

>>>
>>
>>  ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
>> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> --
>> Daniel-Constantin Mierla - 
>> http://www.asipto.comhttp://twitter.com/#!/miconda - 
>> http://www.linkedin.com/in/miconda
>>
>>
>> ___
>> 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 - http://www.asipto.comhttp://twitter.com/#!/miconda 
> - http://www.linkedin.com/in/miconda
>
>
___
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] geoip crash

[Daniel-Constantin Mierla]

On 02/03/14 02:59, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:


I just pushed a patch to master, but I didn't have the geoip libs
installed, thus no test.

If everything is ok, you can backport at your convenience, otherwise I
will do it when I get the first chance.

i tried and noticed that i don't have a working master at this time,
only 4.1.

Not clear for me -- have you tested with 4.1 and all is ok?

Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


___
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] REGISTER failure_route 401 problem

[Daniel-Constantin Mierla]

On 03/03/14 18:08, Marc Soda wrote:
I resolved the issue, but I not quite sure why is worked.  Rather than 
sending the REGISTER with t_reply()


t_reply() is not sending REGISTER anywhere, it is sending a reply (sip 
response) for a request.


In short, be sure you set the appropriate failure route for the request 
and forward it with t_relay().


Cheers,
Daniel


, I changed it to call route(RELAY) which does this:

route[RELAY] {
  xlog("L_NOTICE","route[RELAY] ($rm)\n");

  if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
  }

  if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
  }

  if (is_method("INVITE")) {
if (!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
  }

  xlog("L_NOTICE","t_relay()'ing ($rm)\n");

  if (!t_relay()) {
sl_reply_error();
  }
  exit;
}

I thought that maybe the issue was that I was getting a 100 TRYING 
right before the 401, and maybe I needed to setup a reply route as 
well.  However, as you can see above, MANAGE_REPLY isn't set for 
REGISTERs.  Why did this fix the problem?


Marc

On Mon, Mar 3, 2014 at 11:52 AM, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


Are you sure you have set t_on_failure() for the respective
transaction?

Cheers,
Daniel


On 03/03/14 17:44, Marc Soda wrote:

So I've found out that NAT has nothing to do with it.  The bit
about things working when the NAT device is removed was wrong.

So my question becomes:  Why would Kamailio ignore a 401 rather
sending it to a failure route?

Thanks in advance,
Marc


On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda mailto:ms...@coredial.com>> wrote:

I forget to mention, the nat device is in front of the
Kamailio servers, not the endpoints.


On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda
mailto:ms...@coredial.com>> wrote:

I have a Kamailio server setup which is registers to a
back end server on behalf of endpoints.  The endpoints
can register to Kamailio but Kamailio is failing to
register to the server when I put a NAT device in front
of it.  Without the NAT device it works fine.

The problem is the 401 that comes back seems to be
ignored by Kamailio.  I have a failure route setup to
auth, but it is never hit.  I see the 401 in
onrely_route, but not the failure_route.  I'm assuming
it's a NAT issue because removing the device fixes the issue.

Anyone have any ideas?

The 401 being ignored:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
Via: SIP/2.0/UDP

127.0.0.1:12354;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
From: ;tag=1
To: ;tag=as00e32130
Call-ID: 1-1879@127.0.0.1 
CSeq: 2 REGISTER
User-Agent: CoreDialPBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY, INFO
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5,
realm="fe-c7c5-9o.domain.com
", nonce="151e4f60"
Content-Length: 0

Thanks,
Marc



___
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 -http://www.asipto.com

http://twitter.com/#!/miconda    
-http://www.linkedin.com/in/miconda


___
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
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] REGISTER failure_route 401 problem

[Marc Soda]

I resolved the issue, but I not quite sure why is worked.  Rather than
sending the REGISTER with t_reply(), I changed it to call route(RELAY)
which does this:

route[RELAY] {
  xlog("L_NOTICE","route[RELAY] ($rm)\n");

  if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
  }

  if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if (!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
  }

  if (is_method("INVITE")) {
if (!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
  }

  xlog("L_NOTICE","t_relay()'ing ($rm)\n");

  if (!t_relay()) {
sl_reply_error();
  }
  exit;
}

I thought that maybe the issue was that I was getting a 100 TRYING right
before the 401, and maybe I needed to setup a reply route as well.
 However, as you can see above, MANAGE_REPLY isn't set for REGISTERs.  Why
did this fix the problem?

Marc

On Mon, Mar 3, 2014 at 11:52 AM, Daniel-Constantin Mierla  wrote:

>  Are you sure you have set t_on_failure() for the respective transaction?
>
> Cheers,
> Daniel
>
>
> On 03/03/14 17:44, Marc Soda wrote:
>
> So I've found out that NAT has nothing to do with it.  The bit about
> things working when the NAT device is removed was wrong.
>
>  So my question becomes:  Why would Kamailio ignore a 401 rather sending
> it to a failure route?
>
>  Thanks in advance,
> Marc
>
>
> On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda  wrote:
>
>> I forget to mention, the nat device is in front of the Kamailio servers,
>> not the endpoints.
>>
>>
>> On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda  wrote:
>>
>>> I have a Kamailio server setup which is registers to a back end server
>>> on behalf of endpoints.  The endpoints can register to Kamailio but
>>> Kamailio is failing to register to the server when I put a NAT device in
>>> front of it.  Without the NAT device it works fine.
>>>
>>>  The problem is the 401 that comes back seems to be ignored by
>>> Kamailio.  I have a failure route setup to auth, but it is never hit.  I
>>> see the 401 in onrely_route, but not the failure_route.  I'm assuming it's
>>> a NAT issue because removing the device fixes the issue.
>>>
>>>  Anyone have any ideas?
>>>
>>>  The 401 being ignored:
>>>
>>>  SIP/2.0 401 Unauthorized
>>>  Via: SIP/2.0/UDP
>>> 10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
>>> Via: SIP/2.0/UDP 127.0.0.1:12354
>>> ;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
>>> From: ;tag=1
>>> To: ;tag=as00e32130
>>> Call-ID: 1-1879@127.0.0.1
>>> CSeq: 2 REGISTER
>>> User-Agent: CoreDialPBX
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>>  Supported: replaces
>>> WWW-Authenticate: Digest algorithm=MD5, realm="fe-c7c5-9o.domain.com",
>>> nonce="151e4f60"
>>> Content-Length: 0
>>>
>>>  Thanks,
>>> Marc
>>>
>>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda 
> - http://www.linkedin.com/in/miconda
>
>
> ___
> 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

Re: [SR-Users] REGISTER failure_route 401 problem

[Daniel-Constantin Mierla]

Are you sure you have set t_on_failure() for the respective transaction?

Cheers,
Daniel

On 03/03/14 17:44, Marc Soda wrote:
So I've found out that NAT has nothing to do with it.  The bit about 
things working when the NAT device is removed was wrong.


So my question becomes:  Why would Kamailio ignore a 401 rather 
sending it to a failure route?


Thanks in advance,
Marc


On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda > wrote:


I forget to mention, the nat device is in front of the Kamailio
servers, not the endpoints.


On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda mailto:ms...@coredial.com>> wrote:

I have a Kamailio server setup which is registers to a back
end server on behalf of endpoints.  The endpoints can register
to Kamailio but Kamailio is failing to register to the server
when I put a NAT device in front of it.  Without the NAT
device it works fine.

The problem is the 401 that comes back seems to be ignored by
Kamailio.  I have a failure route setup to auth, but it is
never hit.  I see the 401 in onrely_route, but not the
failure_route.  I'm assuming it's a NAT issue because removing
the device fixes the issue.

Anyone have any ideas?

The 401 being ignored:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
Via: SIP/2.0/UDP

127.0.0.1:12354;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
From: ;tag=1
To: ;tag=as00e32130
Call-ID: 1-1879@127.0.0.1 
CSeq: 2 REGISTER
User-Agent: CoreDialPBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5,
realm="fe-c7c5-9o.domain.com ",
nonce="151e4f60"
Content-Length: 0

Thanks,
Marc



___
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
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] REGISTER failure_route 401 problem

[Marc Soda]

So I've found out that NAT has nothing to do with it.  The bit about things
working when the NAT device is removed was wrong.

So my question becomes:  Why would Kamailio ignore a 401 rather sending it
to a failure route?

Thanks in advance,
Marc


On Mon, Mar 3, 2014 at 9:10 AM, Marc Soda  wrote:

> I forget to mention, the nat device is in front of the Kamailio servers,
> not the endpoints.
>
>
> On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda  wrote:
>
>> I have a Kamailio server setup which is registers to a back end server on
>> behalf of endpoints.  The endpoints can register to Kamailio but Kamailio
>> is failing to register to the server when I put a NAT device in front of
>> it.  Without the NAT device it works fine.
>>
>> The problem is the 401 that comes back seems to be ignored by Kamailio.
>>  I have a failure route setup to auth, but it is never hit.  I see the 401
>> in onrely_route, but not the failure_route.  I'm assuming it's a NAT issue
>> because removing the device fixes the issue.
>>
>> Anyone have any ideas?
>>
>> The 401 being ignored:
>>
>> SIP/2.0 401 Unauthorized
>> Via: SIP/2.0/UDP
>> 10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
>> Via: SIP/2.0/UDP 127.0.0.1:12354
>> ;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
>> From: ;tag=1
>> To: ;tag=as00e32130
>> Call-ID: 1-1879@127.0.0.1
>> CSeq: 2 REGISTER
>> User-Agent: CoreDialPBX
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>>  Supported: replaces
>> WWW-Authenticate: Digest algorithm=MD5, realm="fe-c7c5-9o.domain.com",
>> nonce="151e4f60"
>> Content-Length: 0
>>
>> Thanks,
>> Marc
>>
>
___
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] REGISTER failure_route 401 problem

[Marc Soda]

I forget to mention, the nat device is in front of the Kamailio servers,
not the endpoints.


On Fri, Feb 28, 2014 at 6:22 PM, Marc Soda  wrote:

> I have a Kamailio server setup which is registers to a back end server on
> behalf of endpoints.  The endpoints can register to Kamailio but Kamailio
> is failing to register to the server when I put a NAT device in front of
> it.  Without the NAT device it works fine.
>
> The problem is the 401 that comes back seems to be ignored by Kamailio.  I
> have a failure route setup to auth, but it is never hit.  I see the 401 in
> onrely_route, but not the failure_route.  I'm assuming it's a NAT issue
> because removing the device fixes the issue.
>
> Anyone have any ideas?
>
> The 401 being ignored:
>
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP
> 10.0.10.11;branch=z9hG4bKe5d6.178378f7.0;received=198.XXX.XXX.XXX
> Via: SIP/2.0/UDP 127.0.0.1:12354
> ;rport=6545;received=198.XXX.YYY.YYY;branch=z9hG4bK-1879-1-3
> From: ;tag=1
> To: ;tag=as00e32130
> Call-ID: 1-1879@127.0.0.1
> CSeq: 2 REGISTER
> User-Agent: CoreDialPBX
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces
> WWW-Authenticate: Digest algorithm=MD5, realm="fe-c7c5-9o.domain.com",
> nonce="151e4f60"
> Content-Length: 0
>
> Thanks,
> Marc
>



-- 

Marc Soda, Sr. Systems Engineer
*CoreDial, LLC* | www.coredial.com

1787 Sentry Parkway West, Building 16, Suite 100, Blue Bell, PA 19422
Office: (215) 297-4400 x203 | Fax: (215) 297-4401 | Email:
ms...@coredial.com

- - - - -

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
___
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] New official Debian and Ubuntu repository

[Frank Carmickle]

On Mar 3, 2014, at 8:16 AM, Victor Seva  
wrote:

> The new build system for Debian and Ubuntu packages is now in place.
> This service is kindly sponsored by SipWise [0] thanks to Andreas
> Granig [1]. Sipwise is providing the hosting and man power to create
> and manage this new system.
> 
> deb.kamailio.org is based on jenkins-debian-glue[2] project running on
> AWS EC2 environment thanks to Michael Prokop [3] and myself. All the
> needed files, scripts and info to reproduce this system is kept public
> at [4].


This is fantastic.  Thank you very much for doing this.

--FC


___
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] usrloc preload

[Daniel-Constantin Mierla]

Hello,

locations records are loaded from database at startup based on detection 
of use for registrar functions save/lookup, whose parameters include the 
name of database table.


But in case you want to use an embedded language, such as Lua, the 
config interpreter cannot detect if any location tables have to be 
loaded, thus you have to give them as parameters to usrloc module.


Cheers,
Daniel

On 06/02/14 14:55, Victor V. Kustov wrote:

Hi all!

Please give expanded tips about usrloc preload(). What exactly it
doing?

modparam("usrloc", "db_mode", 0)
modparam("usrloc", "preload", "location")

This case kamailio load from db on startup and operate in memory after?

--
  WBR, Victor
   JID: coy...@bks.tv
   JID: coy...@bryansktel.ru
   I use FREE operation system: 3.12.9-calculate GNU/Linux

___
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


___
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] New official Debian and Ubuntu repository

[Victor Seva]

The new build system for Debian and Ubuntu packages is now in place.
This service is kindly sponsored by SipWise [0] thanks to Andreas
Granig [1]. Sipwise is providing the hosting and man power to create
and manage this new system.

deb.kamailio.org is based on jenkins-debian-glue[2] project running on
AWS EC2 environment thanks to Michael Prokop [3] and myself. All the
needed files, scripts and info to reproduce this system is kept public
at [4].

In [5] is described all the repositories available.

* nightly builds are been built if a change is detected in the branch,
once by night.
- kamailiodev-nightly
branch:
   - 'master'
distributions: jessie, wheezy, squeeze, precise

- kamailio41-nightly
 branch:
  - '4.1'
distributions: jessie, wheezy, squeeze, precise

- kamailio40-nightly
  branch:
  - '4.0'
distributions: lenny, squeeze, wheezy, lucid, precise

- kamailio33-nightly
branch:
  - '3.3'
distributions: lenny, squeeze, wheezy, lucid, precise

* tags are been built if a new tag is detected once by night.
- kamailio41
branch:
  - '*/tags/4.1*'
distributions: jessie, wheezy, squeeze, precise

- kamailio40
branch:
  - '*/tags/4.0*'
distributions: lenny, squeeze, wheezy, lucid, precise

- kamailio33
branch:
  - '*/tags/3.3*'
distributions: lenny, squeeze, wheezy, lucid, precise

Now there is no 4.1.1 package built so the default kamailio repository
is pointing to a empty repository. As soon as we release 4.1.2 this
will be fixed.

Regards,
Victor Seva ( kamailio admin hat on )

[0] http://www.sipwise.com/
[1] http://www.kamailio.org/w/andreas-granig/
[2] https://github.com/mika/jenkins-debian-glue
[3] http://michael-prokop.at/
[4] https://github.com/sipwise/kamailio-deb-jenkins
[5] http://deb.kamailio.org/index.html

___
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] Strange, can you help me to understand?

[Daniel-Constantin Mierla]

You have to provide the traffic taken on kamailio server, with both 
sides of the call. Now it looks like with one side, not saying which one 
is the proxy.


As I blind guess, in case there are more proxies involved, I expect one 
of the proxy in the chain not fixing properly for nat traversal, 
replacing the contact with the ip of the other proxy, by using 
fix_nated_contact(). In kamailio we recommend now the way of using 
contact alias parameter (set_contact_alias() along with 
handle_ruri_alias() -- see latest default config).


Cheers,
Daniel

On 03/03/14 13:02, rupert.or...@bt.com wrote:

The ACK to the Answer is not making it back...200OK repeated until it times out.

I haven't looked at it long enough to figure out why the ACK not making it 
back, but as its your set up, you may know why?

Rupert

-Original Message-
From: sr-users-boun...@lists.sip-router.org 
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Olivier Taylor
Sent: 03 March 2014 11:56
To: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] Strange, can you help me to understand?

I have one client and only one having this problem, everything ok but after 10 
seconds the call stop, hangup by the caller

Thanks,

Olivier




U 2014/03/03 11:55:32.516859 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239 
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Content-Type: application/sdp.
Supported: timer.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013497 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.518911 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Proxy-Authenticate: Digest realm="sip.z.be",
nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af".
Server: z Proxy Server.
Content-Length: 0.
.


U 2014/03/03 11:55:32.543757 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
ACK sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 ACK.
Max-Forwards: 16.
Content-Length: 0.
.



U 2014/03/03 11:55:32.555243 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Proxy-Authorization: Digest
username="778987068",realm="sip.z.be",nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af",response="3ff2d60377789a2624eb5d479c5460e2",uri="sip:0485336...@sip.z.be".
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Supported: timer.
Content-Type: application/sdp.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013498 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.591291 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0;rport=53239;received=XXX.XXX.XX.165.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Server: z Proxy Server.
Content-Length: 0.
.




U 2014/03/03 11:55:32.770059 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53

Re: [SR-Users] Strange, can you help me to understand?

[rupert.organ]

The ACK to the Answer is not making it back...200OK repeated until it times out.

I haven't looked at it long enough to figure out why the ACK not making it 
back, but as its your set up, you may know why?

Rupert

-Original Message-
From: sr-users-boun...@lists.sip-router.org 
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Olivier Taylor
Sent: 03 March 2014 11:56
To: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] Strange, can you help me to understand?

I have one client and only one having this problem, everything ok but after 10 
seconds the call stop, hangup by the caller

Thanks,

Olivier




U 2014/03/03 11:55:32.516859 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239 
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Content-Type: application/sdp.
Supported: timer.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013497 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.518911 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Proxy-Authenticate: Digest realm="sip.z.be",
nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af".
Server: z Proxy Server.
Content-Length: 0.
.


U 2014/03/03 11:55:32.543757 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
ACK sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 ACK.
Max-Forwards: 16.
Content-Length: 0.
.



U 2014/03/03 11:55:32.555243 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Proxy-Authorization: Digest
username="778987068",realm="sip.z.be",nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af",response="3ff2d60377789a2624eb5d479c5460e2",uri="sip:0485336...@sip.z.be".
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Supported: timer.
Content-Type: application/sdp.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013498 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.591291 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0;rport=53239;received=XXX.XXX.XX.165.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.
From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Server: z Proxy Server.
Content-Length: 0.
.




U 2014/03/03 11:55:32.770059 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP
XXX.XXX.XX.165:53239;rport=53239;received=XXX.XXX.XX.165;branch=z9hG4bK060b.f4bc6cb2.0.
Via: SIP/2.0/UDP
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.
Record-Route: .
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=as7545f954.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Server: z Gateway.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Contact: .
Content-Type: application/sdp.
Content-Length: 337.
.
v=0.
o=root 463087396 463087396

[SR-Users] Strange, can you help me to understand?

[Olivier Taylor]

I have one client and only one having this problem, everything ok but 
after 10 seconds the call stop, hangup by the caller


Thanks,

Olivier




U 2014/03/03 11:55:32.516859 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP 
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.

From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Content-Type: application/sdp.
Supported: timer.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013497 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.518911 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
Via: SIP/2.0/UDP 
172.27.8.2:5060;rport=5060;branch=z9hG4bKd558fc6e05cd7294b8649eee778732cc.

From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 INVITE.
Proxy-Authenticate: Digest realm="sip.z.be", 
nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af".

Server: z Proxy Server.
Content-Length: 0.
.


U 2014/03/03 11:55:32.543757 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
ACK sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK360b.26510824.0.
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=022de94afdc7c6186b2ed0d3f634dcc7.8da5.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333191 ACK.
Max-Forwards: 16.
Content-Length: 0.
.



U 2014/03/03 11:55:32.555243 XXX.XXX.XX.165:53239 -> YYY.YY.YYY.174:53239
INVITE sip:0485336...@sip.z.be:53239 SIP/2.0.
Via: SIP/2.0/UDP XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0.
Via: SIP/2.0/UDP 
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.

From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Contact: "3242271698" .
Max-Forwards: 16.
Proxy-Authorization: Digest 
username="778987068",realm="sip.z.be",nonce="53145fc28ccf4aff67544d9ca500a56bf70264daa4af",response="3ff2d60377789a2624eb5d479c5460e2",uri="sip:0485336...@sip.z.be".

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE.
Supported: timer.
Content-Type: application/sdp.
Content-Length: 353.
User-Agent: creativeOne SIP Server at c00262ldpj.
.
v=0.
o=UserA 3638030359 3453013498 IN IP4 XXX.XXX.XX.165.
s=Session SDP.
c=IN IP4 XXX.XXX.XX.165.
t=0 0.
m=audio 49154 RTP/AVP 18 8 0 4 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:4 G723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=oldmediaip:172.27.8.2.
a=oldmediaip:172.27.8.2.


U 2014/03/03 11:55:32.591291 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 
XXX.XXX.XX.165:53239;branch=z9hG4bK060b.f4bc6cb2.0;rport=53239;received=XXX.XXX.XX.165.
Via: SIP/2.0/UDP 
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.

From: "3242271698" ;tag=8713a99116b6a69b.
To: .
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Server: z Proxy Server.
Content-Length: 0.
.




U 2014/03/03 11:55:32.770059 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 
XXX.XXX.XX.165:53239;rport=53239;received=XXX.XXX.XX.165;branch=z9hG4bK060b.f4bc6cb2.0.
Via: SIP/2.0/UDP 
172.27.8.2:5060;rport=5060;branch=z9hG4bK3dc641d7cf50df62500e0dd8e1da4559.

Record-Route: .
From: "3242271698" ;tag=8713a99116b6a69b.
To: ;tag=as7545f954.
Call-ID: 6e8539f27de55f839ad3241b53f1d915@172.27.8.2.
CSeq: 1846333192 INVITE.
Server: z Gateway.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Contact: .
Content-Type: application/sdp.
Content-Length: 337.
.
v=0.
o=root 463087396 463087396 IN IP4 YYY.YY.YYY.176.
s=Asterisk PBX 1.6.2.22.
c=IN IP4 YYY.YY.YYY.176.
t=0 0.
m=audio 16018 RTP/AVP 18 8 0 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.





U 2014/03/03 11:55:44.230021 YYY.YY.YYY.174:53239 -> XXX.XXX.XX.165:53239
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 
XXX.XXX.XX.165:53239;rport=53239;received=XXX.XXX.XX.1

[SR-Users] Releasing 4.1.2, 4.0.6 and 3.3.7

[Daniel-Constantin Mierla]

Hello,

we are considering to release new versions from stable branches of 
Kamailio starting with Thursday, March 6. First is v4.1.2 from latest 
stable branch and if the time allows in the same day, the v4.0.6.


The reason to release v3.3.7 is to have a proper debian packages built 
and hosted on the new repositories -- the specs had a conflict for 
latest 3.3 version of some sub-packages.


If there are known issues that were not addressed, please report them to 
the tracker.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, in Berlin, Germany
http://www.kamailioworld.com


___
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] Ubuntu precise apt repositories unavailable

[Josef Stautner]

Hi,

thanks for the fast response!

I ran some DNS lookups and found some servers which returned the new IP.
Well, seems that our DNS didn't get the change so far.
I'll just wait 12 more hourses. I hope until then everything should be fine!

Thanks,

Josef Stautner


Am 03.03.2014 09:51, schrieb Victor Seva:
> Hi,
>
> 2014-03-03 8:46 GMT+01:00 Josef Stautner :
>> Is this just a temporary probleme and are there any fallback mirrors?
> This is a temporary problem, we are changing the DNS record. So
> 87.106.140.63 is the old one. The new one should be 54.195.245.207.
>
> Please try again and report any further problems.
>
> Cheers,
> Victor
>
> ___
> 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
>

-- 
R-KOM GmbH & Co. KG
Greflingerstr. 26, 93055 Regensburg

Telefon +49 (9 41) 69 85 - 1 83
Telefax +49 (9 41) 69 85 - 2 83
mailto:josef.staut...@r-kom.de
http://www.r-kom.de


___
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] Ubuntu precise apt repositories unavailable

[Victor Seva]

Hi,

2014-03-03 8:46 GMT+01:00 Josef Stautner :
> Is this just a temporary probleme and are there any fallback mirrors?

This is a temporary problem, we are changing the DNS record. So
87.106.140.63 is the old one. The new one should be 54.195.245.207.

Please try again and report any further problems.

Cheers,
Victor

___
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