Realtime + SIP + ODBC problem

Asterisk Asterisk Support
1

Hi

I have installed and configured Version 1.2 with realtime for sipusers using a postgres database (odbc). My sip clients are registering and dialing ok, but when they log off, I get this messages in the CLI:

– SIP Seeding peer from astdb: ‘2100’ at 2100@10.0.0.1:5062 for 1800
– Unregistered SIP '2100’
Dec 7 00:12:44 WARNING[3517]: res_odbc.c:171 odbc_smart_execute: SQL Execute returned an error -1: 01000: [unixODBC]Error while executing the query (non-fatal);
ERROR: value too long for type character varying(5) (107)
Dec 7 00:12:44 WARNING[3517]: res_odbc.c:171 odbc_smart_execute: SQL Execute returned an error -1: 00000: [unixODBC]Error while executing the query (non-fatal);
ERROR: value too long for type character varying(5) (107)
Dec 7 00:12:44 WARNING[3517]: res_config_odbc.c:399 update_odbc: SQL Execute error!
[UPDATE sip_friends SET ipaddr=?, port=?, regseconds=?, username=? WHERE name=?]

This is not affecting my SIP users, but is kind of unconfortable to get this warnings and obviously something is not working ok.
I found out that asterisk was triying to update a SIP record but the ‘port’ field wasnt big enough, so I made it varchar(128) and now the warning is gone. But something is still wrong because whenever a users deregisters, his IP adrress goes into the ‘port’ field , and I get garbage into the ‘ipaddr’ field:

select name, ipaddr, port from sip_friends where id=200;
name | ipaddr | port
------±-------±---------
2100 | ìIW | 10.0.0.1

Can someone tell me how can I fix this?, and what could be wrong ?

Thanks in advance,

Juan

2

it is a bag in asterisk )
but it is not critical bug.
this info asterisk use for reaching users if you dial them.
so if this fields contains garbage,tehn it can’t reach them and thats all)

3

Well, I would say That its critical.
If my users cannot call themselves, then I have a critical problem :wink:

The fact is…actually my users can call themselves. Asterisk only tries to update SIP tables a while after the user’s registration. So I think it retrieving user’s location (IP and port) directly from memory. Im not sure of this, but this is what I deduce from what Ive seen in the CLI.

Can anyone tell me how could I solve this rapidly (maybe changing the SQL table) :question:
…should I report this as a bug and try to fix the code by myself?

Thanks,

Juan