Re: [SR-Users] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Peter Dunkley
> Peter,
> I know the weekend is coming up, but I would love seeing this in the RLS
> README. Could you put that on your to-do list? We can't have TOO MUCH
> documentation...
>

It's all a matter of perspective.  If you are writing the documentation
and there is lots to do it can certainly seem like TOO MUCH :-)

I'll add it to my list though, probably do something next time I am in there.

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd


___
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] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Peter Dunkley
Hello,

I have added comments inline below...

>Appreciate your detailed response. The client we are using is compliant
> with the GSM RCS spec and the xml (including the use of external anchors)
> comes straight from the specs. Are you aware of  any  RLS capable clients
> that doesn't use external anchors but comply with the RCS specifications
> for presence? We've used Jitsi - but that doesn't seem to support rls.
>

Jitsi doesn't support RLS.  I believe Blink does, but I don't know whether
it works with Kamailio.

If you are not getting any errors relating to the external anchors, and
you are seeing a back-end subscription for each  in your
resource-list then it may be the case that Kamailio is ignoring the
external anchors and they aren't causing you problems.  As long as you
don't require subscriptions to the resources in the external anchors you
might be OK.

>
> This seems to resolve the looping issue. However, now I don't see an entry
> for the dialog in the rls_watchers table. I see the following entries in
> the respective tables:
>

Unless you are using DB only mode for RLS the rls_watchers() entry will
not appear immediately.  When using the memory hash table new RLS
subscriptions are flushed to the DB on a timer.

>- One presentity in the presentity table - *Yes*
>- One presence.winfo dialog in the active_watchers table- *Yes* *+ 1
>presence entry *

So this looks like it is working.  You have one entry for presence.winfo
and one entry for a resource subscription - which based on the
resource-list document in your email that contains a single 
would be correct.

If you are testing presence and having problems it is helpful to stop
Kamailio, clear out the active_watchers, presentity, pua, rls_presentity,
rls_watchers, and watchers, and start Kamailio between each test.  You
won't need to do this once you have it working - but keeping the tables
clean will help you debug problems.

> Again appreciate you taking the time to respond. Is there any plan to add
> support for external anchors in the new future?
>

I don't know about anyone else, but I don't have any immediate plans to
add support for external anchors.  Adding external anchor support would be
a significant change to the RLS module.  You would have to:
- Perform an HTTP GET whenever you come across an anchor (inefficient) or
just fetch the first time and cache the fully resolved resource lists in a
new DB table (as is done with pres-rules in watchers).  If the new table
is added rls_update_subs() would need be extended to update the table as
required.
- Have Kamailio block after sending the HTTP GET for the external anchor
(inefficient) or use t_(suspend|continue)() to pause the SIP transaction
(freeing the Kamailio process to handle other requests) until the HTTP
response arrives.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd


___
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] web homer not displaying data

2012-10-26 Thread Christopher Holland
I've checked my apache errors.log There are no errors. also I've checked 
phpinfo.php and it shows pdo drivers mysql enabled. So I'll email 
supp...@sipcature.org


Thanks all for the help


On 10/26/12 14:06, Alexandr Dubovikov wrote:

Hi Christopher,

at first please check your apache errors.log. Seems you have problem 
with PDO driver. If you want get support for Webhomer, please contact 
us by email: supp...@sipcapture.org


Wbr,
Alexandr


10/26/2012 7:17 PM, Christopher Holland wrote:
I have  sipcapture and siptrace setup on the same server using 
kamailio 3.4.0-dev4 and webhomer 3.3.0 setup to capture sip traffic 
from a mirriored port on the LAN. Interface ETH1 is to capture and 
ETH0 is for managment.


The sipcapture database is getting data put into it. I can log into 
webhomer, but see no data in the graphes nor can I search. I have 
double checked my database permissions and they seem to be set up 
correctly.


webserver is set up with:

Apache/2.2.16 (Debian)
PHP5
MYSQL
Json
phpmyadmin

Here is a copy of my kamailio.cfg and configuration.php

rev_dns=no
auto_aliases=no

debug=1
log_stderror=no

memdbg=5
memlog=5

log_facility=LOG_LOCAL0

fork=yes
children=5

/* uncomment the next line to disable TCP (default on) */
disable_tcp=yes

/* IP and port for HEP capturing) */
listen=udp:127.0.0.1:9060

mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/" 



loadmodule "pv.so"
loadmodule "db_mysql.so"
loadmodule "sipcapture.so"
loadmodule "textops.so"
loadmodule "siptrace.so"

# - mi_fifo params -

### Routing Logic 
modparam("sipcapture", "db_url", 
"mysql://openser:**@localhost/homerdb")

modparam("sipcapture", "capture_on", 1)
/* activate HEP capturing */
modparam("sipcapture", "hep_capture_on", 1)
/* IP to listen. Port/Portrange apply only on mirroring port 
capturing */

modparam("sipcapture", "raw_socket_listen", "10.0.0.0:5060-5080")
/* Name of interface to bind on raw socket */
modparam("sipcapture", "raw_interface", "eth1")
/* activate IPIP capturing */
#modparam("sipcapture", "raw_ipip_capture_on", 1)
/* My table name*/
modparam("sipcapture", "table_name", "sip_capture")
/* children for raw socket */
modparam("sipcapture", "raw_sock_children", 4)
/* insert delayed */
#modparam("sipcapture", "db_insert_mode", 1)
/* activate monitoring/mirroring port capturing. Linux only */
modparam("sipcapture", "raw_moni_capture_on", 1)
/* Promiscious mode RAW socket. Mirroring port. Linux only */
modparam("sipcapture", "promiscious_on", 1)
/* activate Linux Socket Filter (LSF/BPF) on mirroring interface. 
Linux only */

#modparam("sipcapture", "raw_moni_bpf_on", 1)
/* sipcapture node */
modparam("sipcapture", "capture_node", "homer01")

# check IP and port of your capture node
modparam("siptrace", "duplicate_uri","sip:127.0.0.1:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag",22)
modparam("siptrace", "trace_on", 1)

# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
route {
   sip_capture();
   drop;
}
onreply_route {
   sip_capture();
   drop;
}

##

configuration.php

/*/ 


/* Access db of homer */
define('HOST', "localhost");
define('PORT', 3306);
define('USER', "webhomer");
define('PW', "**");
define('DB', "web_homer");

/* Homer connection
*  this user must have the same password for all Homer nodes
*  please define all your nodes in homer_nodes table
*/
define('HOMER_HOST', "localhost"); /* DEFAULT. Don't forget insert 
this host to your DB nodes table */

define('HOMER_PORT', 3306);
define('HOMER_USER', "openser");
define('HOMER_PW', "**");
define('HOMER_DB', "homerdb");
define('HOMER_TABLE', "sip_capture");

/*/ 



/* webHomer Settings
*  Adjust to reflect your system preferences
*/

define('PCAPDIR',"/var/www/webhomer/tmp/");
define('WEBPCAPLOC',"/webhomer/tmp/");
define('APIURL',"http://localhost";);
define('APILOC',"/webhomer/api/");

/* INCLUDE preferences */

include("preferences.php");

?>



___
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




___
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] web homer not displaying data

2012-10-26 Thread Alexandr Dubovikov

Hi Christopher,

at first please check your apache errors.log. Seems you have problem 
with PDO driver. If you want get support for Webhomer, please contact us 
by email: supp...@sipcapture.org


Wbr,
Alexandr


10/26/2012 7:17 PM, Christopher Holland wrote:
I have  sipcapture and siptrace setup on the same server using 
kamailio 3.4.0-dev4 and webhomer 3.3.0 setup to capture sip traffic 
from a mirriored port on the LAN. Interface ETH1 is to capture and 
ETH0 is for managment.


The sipcapture database is getting data put into it. I can log into 
webhomer, but see no data in the graphes nor can I search. I have 
double checked my database permissions and they seem to be set up 
correctly.


webserver is set up with:

Apache/2.2.16 (Debian)
PHP5
MYSQL
Json
phpmyadmin

Here is a copy of my kamailio.cfg and configuration.php

rev_dns=no
auto_aliases=no

debug=1
log_stderror=no

memdbg=5
memlog=5

log_facility=LOG_LOCAL0

fork=yes
children=5

/* uncomment the next line to disable TCP (default on) */
disable_tcp=yes

/* IP and port for HEP capturing) */
listen=udp:127.0.0.1:9060

mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/" 



loadmodule "pv.so"
loadmodule "db_mysql.so"
loadmodule "sipcapture.so"
loadmodule "textops.so"
loadmodule "siptrace.so"

# - mi_fifo params -

### Routing Logic 
modparam("sipcapture", "db_url", 
"mysql://openser:**@localhost/homerdb")

modparam("sipcapture", "capture_on", 1)
/* activate HEP capturing */
modparam("sipcapture", "hep_capture_on", 1)
/* IP to listen. Port/Portrange apply only on mirroring port capturing */
modparam("sipcapture", "raw_socket_listen", "10.0.0.0:5060-5080")
/* Name of interface to bind on raw socket */
modparam("sipcapture", "raw_interface", "eth1")
/* activate IPIP capturing */
#modparam("sipcapture", "raw_ipip_capture_on", 1)
/* My table name*/
modparam("sipcapture", "table_name", "sip_capture")
/* children for raw socket */
modparam("sipcapture", "raw_sock_children", 4)
/* insert delayed */
#modparam("sipcapture", "db_insert_mode", 1)
/* activate monitoring/mirroring port capturing. Linux only */
modparam("sipcapture", "raw_moni_capture_on", 1)
/* Promiscious mode RAW socket. Mirroring port. Linux only */
modparam("sipcapture", "promiscious_on", 1)
/* activate Linux Socket Filter (LSF/BPF) on mirroring interface. 
Linux only */

#modparam("sipcapture", "raw_moni_bpf_on", 1)
/* sipcapture node */
modparam("sipcapture", "capture_node", "homer01")

# check IP and port of your capture node
modparam("siptrace", "duplicate_uri","sip:127.0.0.1:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag",22)
modparam("siptrace", "trace_on", 1)

# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
route {
   sip_capture();
   drop;
}
onreply_route {
   sip_capture();
   drop;
}

##

configuration.php

/*/ 


/* Access db of homer */
define('HOST', "localhost");
define('PORT', 3306);
define('USER', "webhomer");
define('PW', "**");
define('DB', "web_homer");

/* Homer connection
*  this user must have the same password for all Homer nodes
*  please define all your nodes in homer_nodes table
*/
define('HOMER_HOST', "localhost"); /* DEFAULT. Don't forget insert 
this host to your DB nodes table */

define('HOMER_PORT', 3306);
define('HOMER_USER', "openser");
define('HOMER_PW', "**");
define('HOMER_DB', "homerdb");
define('HOMER_TABLE', "sip_capture");

/*/ 



/* webHomer Settings
*  Adjust to reflect your system preferences
*/

define('PCAPDIR',"/var/www/webhomer/tmp/");
define('WEBPCAPLOC',"/webhomer/tmp/");
define('APIURL',"http://localhost";);
define('APILOC',"/webhomer/api/");

/* INCLUDE preferences */

include("preferences.php");

?>



___
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] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Olle E. Johansson

26 okt 2012 kl. 19:07 skrev Peter Dunkley :

> Hi,
> 
> External anchors are not currently supported by the Kamailio RLS module.  The 
> presence of these do not explain all of the symptoms you are seeing - but you 
> are not going to be able to get your resource-lists working properly if they 
> are in there - at best these will be ignored, at worst they will cause errors.
> 
> For each  in your resource list the RLS module will create a 
> back-end subscription (using the PUA module) to a Presence Server.  When 
> using Kamailio it is often the case that this Presence Server is actually the 
> Kamailio presence module running on the same instance of Kamailio as RLS and 
> PUA - but even in this case Kamailio will create and send a real SUBSCRIBE 
> request (it'll just loop to itself).
> 
> After logging in with an RLS capable client you should end up with the 
> following:
> One presentity in the presentity table
> One presence.winfo dialog in the active_watchers table
> One presence dialog in the rls_watchers table
> One presence dialog for each  in the resource-list in the pua table
> One presence dialog for each  in the resource-list in the 
> active_watchers table
> One entry in the watchers table for each watcher/presentity relationship 
> indicating state (active, pending, terminated, etc) - these are the cached 
> (to avoid the overhead of continually re-parsing the same XML document) 
> results of the presence module processing pres-rules for each presence 
> subscription
> The rls_presentity table will be empty until you have multiple clients signed 
> in concurrently and are sharing presence between them.
> 
Peter,
I know the weekend is coming up, but I would love seeing this in the RLS 
README. Could you put that on your to-do list? We can't have TOO MUCH 
documentation...

Thanks,
/O
> Regards,
> 
> Peter
> 
> On Fri, 2012-10-26 at 10:44 -0500, Sangeeta Shah wrote:
>> 
>> Hugh,
>>Thanks for the response.
>> 
>> When the client subscribes to the presence.winfo event - it does
>> result in an entry in the active_watchers table.
>> 
>> Then it is sending a subscribe to the presence event with the
>> supported header set to "eventlist"
>> 
>> Also I am starting from an empty database. So as you said, the client
>> is getting a 404 back and then putting the pres-rules, rls-services,
>> and resource-lists documents. The client that is connecting has no
>> contacts. All 3 documents have external anchors which I unfortunately
>> cannot disable :(
>> 
>> So the resource-list XML is as follows:
>> 
>>   
>> All Contacts
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D";
>> />
>> 
>>   
>>   
>> Blocked Contacts
>>   
>>   
>> Revoked Contacts
>>   
>>   
>> OMA All Contacts
>>   
>>   
>> OMA Blocked Contacts
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D";
>> />
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D";
>> />
>>   
>>   
>> OMA BuddyList
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
>> />
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D";
>> />
>>   
>>   
>> OMA Granted Contacts
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
>> />
>> > anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D";
>> />
>>   
>>   
>> OMA POC BuddyList
>>   
>>   
>> My Default Contacts
>>   
>> 
>> 
>> Now when I run tcpdump on the loopback interface I see a ton of
>> messages generated from the server - to the server as follows
>> (excerpt), there are a ton of presence subscribes and corresponding
>> notifies that are going back to the server, only one instance of the
>> publish below:
>> 
>> PUBLISH sip:8475551001@ip SIP/2.0
>> 
>> Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0
>> 
>> To: sip:8475551001@kamailio-ip
>> 
>> From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e
>> 
>> CSeq: 10 PUBLISH
>> 
>> Call-ID: 3a1e3ea20824a642-1670@127.0.0.1
>> 
>> Content-Length: 499
>> 
>> User-Agent: kamailio (3.3.2 (x86_64/linux))
>> 
>> Max-Forwards: 70
>> 
>> Event: reg
>> 
>> Expires: 3601
>> 
>> Content-Type: application/reginfo+xml
>> 
>> 
>> 
>> 
>> 
>>   > state="active">
>> > expires="60" callid="ea899804-de89-fdff-2f22-176bd8996221"
>> cseq="15648" received="" path="" user_agent="IM-client/OMA1.0
>> Boghe/v2.0.97.687">
>>   sip:8475

[SR-Users] web homer not displaying data

2012-10-26 Thread Christopher Holland
I have  sipcapture and siptrace setup on the same server using kamailio 
3.4.0-dev4 and webhomer 3.3.0 setup to capture sip traffic from a 
mirriored port on the LAN. Interface ETH1 is to capture and ETH0 is for 
managment.


The sipcapture database is getting data put into it. I can log into 
webhomer, but see no data in the graphes nor can I search. I have double 
checked my database permissions and they seem to be set up correctly.


webserver is set up with:

Apache/2.2.16 (Debian)
PHP5
MYSQL
Json
phpmyadmin

Here is a copy of my kamailio.cfg and configuration.php

rev_dns=no
auto_aliases=no

debug=1
log_stderror=no

memdbg=5
memlog=5

log_facility=LOG_LOCAL0

fork=yes
children=5

/* uncomment the next line to disable TCP (default on) */
disable_tcp=yes

/* IP and port for HEP capturing) */
listen=udp:127.0.0.1:9060

mpath="/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/"

loadmodule "pv.so"
loadmodule "db_mysql.so"
loadmodule "sipcapture.so"
loadmodule "textops.so"
loadmodule "siptrace.so"

# - mi_fifo params -

### Routing Logic 
modparam("sipcapture", "db_url", "mysql://openser:**@localhost/homerdb")
modparam("sipcapture", "capture_on", 1)
/* activate HEP capturing */
modparam("sipcapture", "hep_capture_on", 1)
/* IP to listen. Port/Portrange apply only on mirroring port capturing */
modparam("sipcapture", "raw_socket_listen", "10.0.0.0:5060-5080")
/* Name of interface to bind on raw socket */
modparam("sipcapture", "raw_interface", "eth1")
/* activate IPIP capturing */
#modparam("sipcapture", "raw_ipip_capture_on", 1)
/* My table name*/
modparam("sipcapture", "table_name", "sip_capture")
/* children for raw socket */
modparam("sipcapture", "raw_sock_children", 4)
/* insert delayed */
#modparam("sipcapture", "db_insert_mode", 1)
/* activate monitoring/mirroring port capturing. Linux only */
modparam("sipcapture", "raw_moni_capture_on", 1)
/* Promiscious mode RAW socket. Mirroring port. Linux only */
modparam("sipcapture", "promiscious_on", 1)
/* activate Linux Socket Filter (LSF/BPF) on mirroring interface. Linux 
only */

#modparam("sipcapture", "raw_moni_bpf_on", 1)
/* sipcapture node */
modparam("sipcapture", "capture_node", "homer01")

# check IP and port of your capture node
modparam("siptrace", "duplicate_uri","sip:127.0.0.1:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag",22)
modparam("siptrace", "trace_on", 1)

# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
route {
   sip_capture();
   drop;
}
onreply_route {
   sip_capture();
   drop;
}

##

configuration.php

define('HOMER_HOST', "localhost"); /* DEFAULT. Don't forget insert this 
host to your DB nodes table */

define('HOMER_PORT', 3306);
define('HOMER_USER', "openser");
define('HOMER_PW', "**");
define('HOMER_DB', "homerdb");
define('HOMER_TABLE', "sip_capture");

/*/

/* webHomer Settings
*  Adjust to reflect your system preferences
*/

define('PCAPDIR',"/var/www/webhomer/tmp/");
define('WEBPCAPLOC',"/webhomer/tmp/");
define('APIURL',"http://localhost";);
define('APILOC',"/webhomer/api/");

/* INCLUDE preferences */

include("preferences.php");

?>



___
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] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Peter Dunkley
Hi,

External anchors are not currently supported by the Kamailio RLS module.
The presence of these do not explain all of the symptoms you are seeing
- but you are not going to be able to get your resource-lists working
properly if they are in there - at best these will be ignored, at worst
they will cause errors.

For each  in your resource list the RLS module will create a
back-end subscription (using the PUA module) to a Presence Server.  When
using Kamailio it is often the case that this Presence Server is
actually the Kamailio presence module running on the same instance of
Kamailio as RLS and PUA - but even in this case Kamailio will create and
send a real SUBSCRIBE request (it'll just loop to itself).

After logging in with an RLS capable client you should end up with the
following:

  * One presentity in the presentity table
  * One presence.winfo dialog in the active_watchers table
  * One presence dialog in the rls_watchers table
  * One presence dialog for each  in the resource-list in
the pua table
  * One presence dialog for each  in the resource-list in
the active_watchers table
  * One entry in the watchers table for each watcher/presentity
relationship indicating state (active, pending, terminated, etc)
- these are the cached (to avoid the overhead of continually
re-parsing the same XML document) results of the presence module
processing pres-rules for each presence subscription

The rls_presentity table will be empty until you have multiple clients
signed in concurrently and are sharing presence between them.

Regards,

Peter

On Fri, 2012-10-26 at 10:44 -0500, Sangeeta Shah wrote:

> Hugh,
>Thanks for the response.
> 
> When the client subscribes to the presence.winfo event - it does
> result in an entry in the active_watchers table.
> 
> Then it is sending a subscribe to the presence event with the
> supported header set to "eventlist"
> 
> Also I am starting from an empty database. So as you said, the client
> is getting a 404 back and then putting the pres-rules, rls-services,
> and resource-lists documents. The client that is connecting has no
> contacts. All 3 documents have external anchors which I unfortunately
> cannot disable :(
> 
> So the resource-list XML is as follows:
> 
>   
> All Contacts
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D";
> />
> 
>   
>   
> Blocked Contacts
>   
>   
> Revoked Contacts
>   
>   
> OMA All Contacts
>   
>   
> OMA Blocked Contacts
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D";
> />
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D";
> />
>   
>   
> OMA BuddyList
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
> />
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D";
> />
>   
>   
> OMA Granted Contacts
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
> />
>  anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D";
> />
>   
>   
> OMA POC BuddyList
>   
>   
> My Default Contacts
>   
> 
> 
> Now when I run tcpdump on the loopback interface I see a ton of
> messages generated from the server - to the server as follows
> (excerpt), there are a ton of presence subscribes and corresponding
> notifies that are going back to the server, only one instance of the
> publish below:
> 
> PUBLISH sip:8475551001@ip SIP/2.0
> 
> Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0
> 
> To: sip:8475551001@kamailio-ip
> 
> From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e
> 
> CSeq: 10 PUBLISH
> 
> Call-ID: 3a1e3ea20824a642-1670@127.0.0.1
> 
> Content-Length: 499
> 
> User-Agent: kamailio (3.3.2 (x86_64/linux))
> 
> Max-Forwards: 70
> 
> Event: reg
> 
> Expires: 3601
> 
> Content-Type: application/reginfo+xml
> 
> 
> 
> 
> 
>state="active">
>  expires="60" callid="ea899804-de89-fdff-2f22-176bd8996221"
> cseq="15648" received="" path="" user_agent="IM-client/OMA1.0
> Boghe/v2.0.97.687">
>   sip:8475551001@10.51.2.181:63311;transport=udp
> 
>   
> 
> SIP/2.0 200 OK
> 
> Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0
> 
> To: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-a070
> 
> From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e
> 
> CSeq: 10 PUBLISH
> 
> Call-ID

Re: [SR-Users] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Sangeeta Shah
Hugh,
   Thanks for the response.

When the client subscribes to the presence.winfo event - it does
result in an entry in the active_watchers table.

Then it is sending a subscribe to the presence event with the
supported header set to "eventlist"

Also I am starting from an empty database. So as you said, the client
is getting a 404 back and then putting the pres-rules, rls-services,
and resource-lists documents. The client that is connecting has no
contacts. All 3 documents have external anchors which I unfortunately
cannot disable :(

So the resource-list XML is as follows:

  
All Contacts
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D";
/>

  
  
Blocked Contacts
  
  
Revoked Contacts
  
  
OMA All Contacts
  
  
OMA Blocked Contacts
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D";
/>
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D";
/>
  
  
OMA BuddyList
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
/>
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D";
/>
  
  
OMA Granted Contacts
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D";
/>
http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D";
/>
  
  
OMA POC BuddyList
  
  
My Default Contacts
  


Now when I run tcpdump on the loopback interface I see a ton of
messages generated from the server - to the server as follows
(excerpt), there are a ton of presence subscribes and corresponding
notifies that are going back to the server, only one instance of the
publish below:

PUBLISH sip:8475551001@ip SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0

To: sip:8475551001@kamailio-ip

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e

CSeq: 10 PUBLISH

Call-ID: 3a1e3ea20824a642-1670@127.0.0.1

Content-Length: 499

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: reg

Expires: 3601

Content-Type: application/reginfo+xml





  

  sip:8475551001@10.51.2.181:63311;transport=udp

  

SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0

To: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-a070

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e

CSeq: 10 PUBLISH

Call-ID: 3a1e3ea20824a642-1670@127.0.0.1

Expires: 3600

SIP-ETag: a.1351264309.1668.1.0

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0



SUBSCRIBE sip:8475551001@kamailio-ip SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0

To: sip:8475551001@kamailio-ip

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd

CSeq: 10 SUBSCRIBE

Call-ID: 3a1e3ea20824a642-1668@127.0.0.1

Content-Length: 0

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: presence

Contact: 

Expires: 7210

Supported: eventlist

Accept: application/pidf+xml, application/rlmi+xml,
application/watcherinfo+xml, multipart/related



SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0

To: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8fd4

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd

CSeq: 10 SUBSCRIBE

Call-ID: 3a1e3ea20824a642-1668@127.0.0.1

Expires: 7200

Contact: 

Require: eventlist

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0



SUBSCRIBE sip:8475551001@kamailio-ip SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0

To: sip:8475551001@kamailio-ip

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4

CSeq: 10 SUBSCRIBE

Call-ID: 3a1e3ea20824a642-1672@127.0.0.1

Content-Length: 0

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: presence

Contact: 

Expires: 7210

Supported: eventlist

Accept: application/pidf+xml, application/rlmi+xml,
application/watcherinfo+xml, multipart/related



SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0

To: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-ceeb

From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4

CSeq: 10 SUBSCRIBE

Call-ID: 3a1e3ea20824a642-1672@127.0.0.1

Expires: 7200

Contact: 

Require: eventlist

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0

I am not sure if it's the nature of the resource-list document or
something in the config file that's causing this loop. I am guessing
it might be the following entry:

Re: [SR-Users] Message Routing To/From Gateway

2012-10-26 Thread Vitaliy Aleksandrov
If you want to receive any suggestions it would be better to show you 
config file with some comments.
It will reduce a time to understand you configuration and will increase 
a chance to get any help here.



After further testing it was found that setting the alias like this 
somehow broke outgoing messages. I'm not certain exactly how Kamailio 
handles aliases, but it seems like it is not as simple as I expected. 
I am working on figuring out a new solution now if anyone has any 
thoughts.



Thanks,
Ed




On Wed, Oct 24, 2012 at 12:27 AM, Ed Brady > wrote:


I was able to resolve the issue by setting the return domain as a
local domain alias. With the previous setting I had made to
forward all non-local accounts to our gateway domain, this would
allow the improper return domain to be seamlessly switched to the
correct domain before being forwarded out of our server. Now users
can have normal two way conversations despite a poor design by our
vendor.

Thanks for a giant push in the right direction!


Ed





On Mon, Oct 22, 2012 at 4:02 PM, Ed Brady mailto:ebr...@talkforgood.com>> wrote:

I have this all working now. I had previously configured this
as a gateway and once issues were fixed on our vendor's end,
it worked. Is there a disadvantage to using this method rather
than the permissions module?

On a related note (though maybe not related enough), when we
get responses from their system it comes back with a different
domain in the URI than what they require us to send to. When
questioned about this they said we would need to handle it on
our end. Is there a common method for checking the to URI for
a particular string (in this case the domain), changing it,
and then forwarding it?


Thanks,
Ed




On Sat, Oct 20, 2012 at 7:23 PM, Vitaliy Aleksandrov
mailto:vitalik.v...@gmail.com>> wrote:

"Permissions" module should help you. If allowed ip
addresses are kept in a database you can reload them by MI
command without kamailio restart.
As I remember "permissions" module allows to create groups
of ip addresses, so you can create such a group for hosts
which you want to receive MESSAGE requests from.


I tested this example and it worked for me. I was
misunderstanding some of the values and thought they
applied to users being registered or not.

I am still uncertain what setting applies to allowing all
traffic inbound from a particular address. Any tips on
this would be appreciated.


Thanks,
Ed



On Fri, Oct 19, 2012 at 1:41 PM, Ed Brady
mailto:ebr...@talkforgood.com>>
wrote:

I was looking at this logic some more and wanted to
clarify my configuration. I need to base the R-URI
rewrite and MESSAGE forward based on whether the
account exists as a local subscriber or not rather
than whether the user is registered or not. This is
connecting to an SMS provider using SIP.

I excitedly looked into the SMS module but this
appears to only be if you are dealing with a GSM
modem and not sending/receiving SIP MESSAGEs with an
SMS gateway.

Any resources you can point me to would be extremely
helpful, thanks!


Ed



On Fri, Oct 19, 2012 at 10:42 AM, Ed Brady
mailto:ebr...@talkforgood.com>> wrote:

Will this also permit incoming messages from this
domain? Do I need to add the gateway in any other
settings besides the one you outlined?


Thanks,
Ed




On Fri, Oct 19, 2012 at 6:17 AM, Vitaliy
Aleksandrov mailto:vitalik.v...@gmail.com>> wrote:

If I understood you right you just need to
rewrite R-URI domain and forward MESSAGE if a
user in not registered.

if (!lookup("location")) {
switch($retcode) {
case -1:
$rd = "gatewaydomain.com
";
t_relay();
exit;
default:
sl_send_reply("404", "Not Found");
exit;
}
}



I am trying to route SIP messages to a
   

Re: [SR-Users] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Hugh Waite

Hi,

I don't know what might cause exactly the issues you are seeing, but 
here's what I would do to track it down.


1. If no xcap documents exist on the system, the client will get a 404 
and should usually PUT some new (empty) documents.


Assuming these 'empty' documents exist, the following should happen when 
the client logs in.
a. When the SUBSCRIBE to presence.winfo arrives it should create a 
single entry in the 'active-watchers' table. It should show a single 
subscription to presence.winfo where the watcher and presentity URI are 
the same user.
c. When the SUBSCRIBE to RLS arrives, it should create a single entry in 
'rls_watchers'. As there are no contacts in the resource-list doc, there 
are no rls subscriptions.


My questions to try and debug would be:
1. Does the above happen when starting from a clean database and not 
having any contacts or external links in the resource-list?


2. If that works, can you add contacts directly to the resource-list 
(like below) and try again. Does that cause a problem? You should see 
entries in 'pua' and 'active-watchers' for the added contacts.


   
   


16


160001


   

3. Finally add the external documents and external anchors and try again.

I haven't personally used anything that uses the external anchors 
feature, but if it is only the external URIs that are causing the 
problem, kamailio may think it is subscribing to the same URI each time 
causing a recursive loop. This may be visible on a network trace taken 
on the loopback interface.


Regards,
Hugh


On 26/10/2012 13:36, Sangeeta Shah wrote:

Did anyone get a chance to look at this post. I upgraded to Kamailio
3.3.2 since the changelog indicated several RLS fixes. But as soon as
I bring my client up I see 4000 entries in my PUA table and about 500+
entries in the rls_watchers table for the same presentity.

What would trigger behavior like this? Either I have an error or am
missing something in the config file or it's my XML. Any thoughts. I
have included my config params in this email chain and my
rls-services, pres-rules and resource-lists documents are from the OMA
specs with external anchors etc.

Thanks,
Sangeeta

On Mon, Oct 22, 2012 at 3:32 PM, Sangeeta Shah  wrote:

Hello All,
I am hoping the authors of the RLS/PUA modules can answer this
question since I am not sure what's going on. I have the rls module
enabled, with the following config spec:

# --rls module params --
modparam("rls", "db_url", DBURL)
modparam("rls", "db_mode", 2)
modparam("rls", "integrated_xcap_server", 1)
modparam("rls", "to_presence_code" ,10)
modparam("rls", "server_address", "sip:rls@ip:5060")


#!endif

and
modparam("pua_reginfo", "default_domain", "ip")
modparam("pua_reginfo", "server_address", "sip:reginfo@ip")
modparam("pua", "db_mode", 2)

So for both I have DB_MODE set to DB ONLY. For whatever reason, even
though all I am doing is bringing up my client I see over 250+ entries
in the rls_watchers table for the same watcher and over 100 entries in
the pua list table for the same presentity?

Anyone have any idea what would be triggering this. There is
definitely not anymore more than the normal messaging going on between
the client and the server.

Only error I see in the syslog:
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry
'1350937406' for key 'expires_idx'
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
presence [subscribe.c:1216]: subs->contact= sip:rls@ip:5060 - len = 25
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
 [db_val.c:117]: converting STRING [8475551001]
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
 [parser/msg_parser.c:626]:  method:  
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
 [db_query.c:210]: error while submitting query
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
rls [rls.h:241]: did=
41826031568472f9-11752@127.0.0.1;533cb9e91f4b999cf76861cbb9ed54ed-93a3;a6a1c5f60faecf035a1ae5b6e96e979a-464d
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
 [db_val.c:117]: converting STRING [10.50.251.12]
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
 [parser/msg_parser.c:628]:  uri: 
Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
pua [pua_db.c:1149]: DB insert failed



--
Sangeeta Shah






--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.

___
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] [OT] the role of SBCs

2012-10-26 Thread Richard Brady
A bit late to dig up this old conversation but my thoughts:

The simplest SIP relationship is from one UA to another UA without proxies.

I love proxies, I really do, they are so powerful. But putting a proxy
between UAs (or B2BUAs) places higher interoperability requirements on
them. For example take record routing. In a simple UA to UA scenario there
is no requirement for either to support record routing. But as soon as
there is a proxy in place, they need to support record routing and/or the
configuration of an outbound proxy and/or the proxy dropping out of the
dialog.

So if you are a pragmatic ITSP and you want to support many types of SIP
UAs behind many types of routers, including badly broken ones with missing
or poorly implemented features, you will benefit from putting a B2BUA right
on the edge.

It's a sorry state of affairs, but I think it's why there is some method to
the SBC madness.


On 31 August 2012 13:25, Fred Posner  wrote:

> When I first got into VoIP, my knowledge was less than stellar. The main
> decision make and I had believed that if we hired quality (and not cheap)
> SME we would be given great information and the money spent would pay for
> itself. We ended up working with a broadsoft system and an acme packet sbc.
> We were really sold that this would be the creme de la creme-- no nat
> issues, failover media, security, stability.
>
> Crap. Problems galore, especially with residential NAT users. Despite
> having 2 acme's in a failover, an outage from the main isp resulted in a
> crippling thundering herd when connection was restored. Immediately, and
> know with some decent knowledge, I started working with (at the time)
> openser.
>
> We deployed it within 2 weeks. There was no feature lost. In fact, we had
> only gains. All the NAT problems suddenly went away. We purposely tried to
> kill the openser with a thundering herd. Couldn't do it. There was a
> learning curve, but when is there not a learning curve?
>
> Honestly, at that time... the savings (which were incredible) wasn't an
> issue. If it were more than an acme, we would have paid it. We needed
> something that worked, and the best product we could find was openser.
>
> Since then, I've been a strong supporter. With the recent modifications
> (do we still consider anti_flood recent?), there's really no other choice
> for me. Yes, it takes programming, customization, and set-up. So does a
> commercial product. It's life.
>
> When I first deployed kamailio, I didn't consider it an SBC. I considered
> it an SBC replacement.
>
> With best regards,
>
> Fred
> http://qxork.com
>
> On Aug 31, 2012, at 3:47 AM, Olle E. Johansson wrote:
>
> > In most, but not all, cases it's a political/business decision outside
> of the scope of the technichal specifications. A commercial SBC delivers a
> cloud of magic dust that makes some people feel better and more secure. I
> have audited several SBC installations that are totally insecure, where the
> local techies lack knowledge on how to operate it. Management people think
> the SBC is secure by design. I can't blame the vendors here - it's more
> correct to blame the decision process.
>
>
> ___
> 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] Entries in PUA List and RLS Watchers List

2012-10-26 Thread Sangeeta Shah
Did anyone get a chance to look at this post. I upgraded to Kamailio
3.3.2 since the changelog indicated several RLS fixes. But as soon as
I bring my client up I see 4000 entries in my PUA table and about 500+
entries in the rls_watchers table for the same presentity.

What would trigger behavior like this? Either I have an error or am
missing something in the config file or it's my XML. Any thoughts. I
have included my config params in this email chain and my
rls-services, pres-rules and resource-lists documents are from the OMA
specs with external anchors etc.

Thanks,
Sangeeta

On Mon, Oct 22, 2012 at 3:32 PM, Sangeeta Shah  wrote:
> Hello All,
>I am hoping the authors of the RLS/PUA modules can answer this
> question since I am not sure what's going on. I have the rls module
> enabled, with the following config spec:
>
> # --rls module params --
> modparam("rls", "db_url", DBURL)
> modparam("rls", "db_mode", 2)
> modparam("rls", "integrated_xcap_server", 1)
> modparam("rls", "to_presence_code" ,10)
> modparam("rls", "server_address", "sip:rls@ip:5060")
>
>
> #!endif
>
> and
> modparam("pua_reginfo", "default_domain", "ip")
> modparam("pua_reginfo", "server_address", "sip:reginfo@ip")
> modparam("pua", "db_mode", 2)
>
> So for both I have DB_MODE set to DB ONLY. For whatever reason, even
> though all I am doing is bringing up my client I see over 250+ entries
> in the rls_watchers table for the same watcher and over 100 entries in
> the pua list table for the same presentity?
>
> Anyone have any idea what would be triggering this. There is
> definitely not anymore more than the normal messaging going on between
> the client and the server.
>
> Only error I see in the syslog:
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
> db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry
> '1350937406' for key 'expires_idx'
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
> presence [subscribe.c:1216]: subs->contact= sip:rls@ip:5060 - len = 25
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
>  [db_val.c:117]: converting STRING [8475551001]
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
>  [parser/msg_parser.c:626]:  method:  
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
>  [db_query.c:210]: error while submitting query
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
> rls [rls.h:241]: did=
> 41826031568472f9-11752@127.0.0.1;533cb9e91f4b999cf76861cbb9ed54ed-93a3;a6a1c5f60faecf035a1ae5b6e96e979a-464d
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
>  [db_val.c:117]: converting STRING [10.50.251.12]
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
>  [parser/msg_parser.c:628]:  uri: 
> Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
> pua [pua_db.c:1149]: DB insert failed
>
>
>
> --
> Sangeeta Shah



-- 
Sangeeta Shah

___
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] MSRP: Generation of REPORTs on the relay

2012-10-26 Thread Peter Dunkley
Hello,

One of my colleagues at Crocodile has been doing some testing with the
msrp module.  With the auth change that was made yesterday, and the
updated configuration I put in the README example it seems to mostly
work.  However, there is one set of scenarios relating to failure
REPORTs that don't seem to be possible with the current module.

RFC 4976 section 6.4.1 paragraph 3 states:


   If the Failure-Report header is "yes" or "partial", and if there is a
   problem processing the SEND request or if an error response is
   received for that SEND request, then the relay MUST respond with an
   appropriate error response in a REPORT back to the original source of
   the message.


This means that when a SEND request that contains a Failure-Report:
header with value of "yes" or "partial" is relayed by Kamailio we need
to maintain some state so that when the TCP send fails, or we receive a
failure response from the next hop, Kamailio can generate and send a
REPORT.  At the moment I don't think the msrp module has these
capabilities.

If the module is getting some re-work before the next release it would
be good to get this in there.  I am quite happy to help out in any way I
can, but I am not sure of the best way to proceed with this.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
___
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] TLS Certificate Verification Issue

2012-10-26 Thread Kamal Palei
Dear Klaus
I am little bit new to linux debugging. Please let me know below stuff.

1. Whats the extension of core file.
2. Will the core files be generated in /home/user path or some other
default path
3. Do I need to recompile Kamailio source with -g option , or by default it
is compiled with -g option
4. I hope we need to run "ulimit" before we start the program or it is not
required.

My observation is if I run directly kamailio it is crashing, if I run with
gdb it is not crashing, not sure why this happens.

Best Regards
kamal



On Thu, Oct 25, 2012 at 8:01 PM, Klaus Darilion <
klaus.mailingli...@pernau.at> wrote:

> SIGABRT  6   CoreAbort signal from abort(3)
>
> This means that there was an error condition detected in the Kamailio code
> and the abort(3) function was called. As you see in the logs a core file
> was generated. Find the core file and load it into gdb and execute
> "backtrace". It will show you were the problem happened and post it here.
>
> regards
> Klaus
>
>
> On 25.10.2012 16:23, Kamal Palei wrote:
>
>> Dear Klaus
>> The certificate verification I have disabled.
>>
>> Facing a new problem.
>> When there is a connection reset, that time Kamailio is crashing.
>> During crash, I get below logs. Any idea why it is crashing and how can
>> I avoid it.
>>
>> /oot@B2BUA:/usr/local/src/**scripts#  9(9557) : 
>>
>> [mem/q_malloc.c:431]: BUG: qm_free: bad pointer (nil) (out of memory
>> block!) - aborting
>>   0(9548) ALERT:  [main.c:742]: child process 9557 exited by a
>> signal 6
>>   0(9548) ALERT:  [main.c:745]: core was generated
>>   0(9548) INFO:  [main.c:757]: INFO: terminating due to SIGCHLD
>>   6(9554) INFO:  [main.c:808]: INFO: signal 15 received
>>   8(9556) INFO:  [main.c:808]: INFO: signal 15 received
>>   4(9552) INFO:  [main.c:808]: INFO: signal 15 received
>>   5(9553) INFO:  [main.c:808]: INFO: signal 15 received
>>   3(9551) INFO:  [main.c:808]: INFO: signal 15 received
>>   7(9555) INFO:  [main.c:808]: INFO: signal 15 received
>>   1(9549) INFO:  [main.c:808]: INFO: signal 15 received
>>   2(9550) INFO:  [main.c:808]: INFO: signal 15 received
>>   0(9548) :  [mem/q_malloc.c:431]: BUG: qm_free: bad pointer (nil)
>> (out of memory block!) - aborting
>>
>>
>> THANKS
>> kamal
>> /
>> On Thu, Oct 25, 2012 at 7:43 PM, Klaus Darilion
>> > >
>> wrote:
>>
>> Hi Kamal!
>>
>> Are you familiar with SSL/TLS and certificates? With TLS the trust
>> between TLS server and TLS client is usually via a trusted
>> certification authority (CA). For example, if the intermediate proxy
>> uses a certificate which is issued by CA FOOBAR-XYZ, the you have to
>> configure Kamailio to accept certificates singed by FOOBAR-XYZ. This
>> is done by copying the public root certificate of FOOBAR-XYZ to the
>> Kamailio server and configure Kamailio to use the FOOBAR-XYZ
>> certificate as trusted CA. Of course then you automatically also
>> trust all others certificates issued by FOOBAR-XYZ.
>>
>> To configure the trusted CAs use:
>> http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#ca_list
>>
>> 
>> 
>> >
>>
>> You could also disable the certificate validation with:
>> http://kamailio.org/docs/__**modules/3.3.x/modules/tls.__**
>> html#verify_certificate
>>
>> > html#verify_certificate
>> >
>>
>> But of course this reduces TLS benefits to encryption-only.
>>
>> regards
>> Klaus
>>
>>
>> On 22.10.2012 13:53, Kamal Palei wrote:
>>
>> Dear All
>> I have modified kamailio,cfg and compiled all the modules with TLS
>> enabled, and able to bring up the kamailio proxy properly.
>>
>> Kamailio proxy will receive the REGISTER message from endpoints
>> in UDP ,
>> and want to send this REGISTER message to another intermediate
>> proxy in
>> TLS. For this purpose, I have added few lines in kamailio.cfg
>> file as below.
>>
>> I have created the certificates, private keys as explained by
>> README
>> file in kamailio-3.1.5/modules/tls/ path.
>>
>>   if(is_method("REGISTER"))
>>   {
>>   t_relay_to("tls:115.114.48.75:**__443
>> 
>>
>> ");
>>
>>   exit();
>>   }
>>
>> Looks like this is taking effect. When Kamailio receives REGISTER
>> message it is trying to do handshake with intermediate proxy.
>>

[SR-Users] Kamailio on Twitter: @kamailioproject

2012-10-26 Thread Olle E. Johansson
The marketing arm of the Kamailio project has without further discussion opened 
up a Twitter account for Kamailio, to support our web site news, G+ and 
Facebook pages. Feel free to contribute with case stories and news we can 
publish on the web site and follow up in the social media flow.

The twitter account is @kamailioproject - please follow it.

And yes, Kamailio is THE best thing since the invention of sliced bread! 

This week's EXTRAORDINARY offer: Download TWO licenses of Kamailio for the same 
licensing cost as we've been offering for ONE license! And get an unlimited 
number of user licenses for your Kamailio SIP accounts! 

Kamailio greetings! Have a great SIP weekend!

/Marketing
___
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