Andrew, Congratulations on your new position as a Kamailio developer! When I saw your module (SCA) I began testing immediately since it may be a stepping stone to help me get the Polycom barge-in feature working with Kamailio. However, I ran into a few difficulties. Can you assist me? To make your existing code work as a K module I had to change a few lines of code and recompile under modules_k. Specifically, since the K definition of the ucontact structure defines ucontact->aor as str* and the S definition as str**, I changed “&c->aor” to “c->aor” in the following lines of sca_usrloc_cb.c:
73: if ( !sca_uri_is_shared_appearance( sca, c->aor )) { 74: LM_DBG( "%.*s is not a shared appearance line", STR_FMT( c->aor )); 79: &SCA_EVENT_NAME_CALL_INFO, c->aor ) < 0 ) {
Since I use PostgreSQL as my SQL engine I created the SCA entries using this code:
INSERT INTO version (table_name, table_version) values ('sca_subscriptions', '0'); CREATE TABLE sca_subscriptions ( id SERIAL PRIMARY KEY NOT NULL, subscriber VARCHAR(255) NOT NULL, aor VARCHAR(255) NOT NULL, event INTEGER NOT NULL, expires INTEGER NOT NULL, state INTEGER NOT NULL, app_idx INTEGER NOT NULL, call_id VARCHAR(255) NOT NULL, from_tag VARCHAR(128) NOT NULL, to_tag VARCHAR(128) NOT NULL, notify_cseq INTEGER NOT NULL, subscribe_cseq INTEGER NOT NULL, CONSTRAINT sca_subscriptions_idx UNIQUE (subscriber, call_id, from_tag, to_tag));
I applied the recommendations from your documentation on configuring Kamailio (3.3.1) and inserted the call to “sca_handle_subscribe ()” in kamailio.cfg. Next, I connected two Polycom phones (SP335 and SP650) to my network and configured them to enable presence and use a shared line. Four lines were configured on the phones as shown below:
SP335 Line 1 (p11) = private line 6013 SP335 Line 1 (p12) = shared line 1519 SP650 Line 1 (p21) = private line 6014 SP650 Line 2 (p22) = shared line 1519
My tests get inconsistent results on the line LEDs and it seems that they do not work as a shared line. When I ran a tcpdump of the SIP communication (see attached pcap files) I found several anomalies:
- Some packets (sca-reboot1 #22, 44, 113, 120 and sca-reboot2 #17, 38) contain spurious NUL characters in the tags section. In all tests it seems to occur in the Expire tag when Kamailio accepts the subscription. - When Kamailio sends call-info NOTIFY the Content-Length tag is missing. - Sometimes the phone does not respond to a call-info NOTIFY event ( sca-reboot1 #23, 45 and sca-reboot2 #18, 39). - I don't have an example here but sometimes the phones respond to the call-info NOTIFY with "481 Call Leg/Transaction Does Not Exist".
I think some of my problems are related to these anomalies. Could you help me to determine if this is a problem with the code itself, my failure to properly port it to the K module, or some other issue? Once again, thank you for making this very useful module for Kamailio and for the documentation to make it work. I hope that resolving my problems may help the code to become a part of Kamailio.
Sincerely yours, Bob Boisvert
On Nov 30, 2012, at 5:23 PM, Robert Boisvert rdboisvert@gmail.com wrote:
Andrew, Congratulations on your new position as a Kamailio developer! When I saw your module (SCA) I began testing immediately since it may be a stepping stone to help me get the Polycom barge-in feature working with Kamailio. However, I ran into a few difficulties. Can you assist me?
Thanks for the kind words. I'll do my best to help.
To make your existing code work as a K module I had to change a few lines of code and recompile under modules_k. Specifically, since the K definition of the ucontact structure defines ucontact->aor as str* and the S definition as str**, I changed “&c->aor” to “c->aor” in the following lines of sca_usrloc_cb.c: 73: if ( !sca_uri_is_shared_appearance( sca, c->aor )) { 74: LM_DBG( "%.*s is not a shared appearance line", STR_FMT( c->aor )); 79: &SCA_EVENT_NAME_CALL_INFO, c->aor ) < 0 ) {
This is no longer necessary, fortunately. The sca module no longer depends on usrloc. I've merged it into the project's master branch, in the modules directory. You should still be able to build it against the 3.3 branch.
Since I use PostgreSQL as my SQL engine I created the SCA entries using this code:
I've also added an sca db schema file, so the db creation scripts get created automatically. Ovidiu generated the PostgreSQL create script, which you can find on the master branch in utils/kamctl/postgres.
I applied the recommendations from your documentation on configuring Kamailio (3.3.1) and inserted the call to “sca_handle_subscribe ()” in kamailio.cfg.
... snip ...
When I ran a tcpdump of the SIP communication (see attached pcap files) I found several anomalies: • Some packets (sca-reboot1 #22, 44, 113, 120 and sca-reboot2 #17, 38) contain spurious NUL characters in the tags section. In all tests it seems to occur in the Expire tag when Kamailio accepts the subscription.
Thanks for the captures. I've tracked down the cause for the NUL in the Expires header, and have committed a fix. (Misplaced parenthesis when writing the Expires value
• When Kamailio sends call-info NOTIFY the Content-Length tag is missing.
It's there, it's just not the last header in the packet. If you do actually find a packet without Content-Length header, please let me know. It *must* be there when using TCP.
• Sometimes the phone does not respond to a call-info NOTIFY event (sca-reboot1 #23, 45 and sca-reboot2 #18, 39).
This may be related to the NUL in the Expires header problem fixed above. Because the Expires line in the response gets mangled, the subscriber may be throwing away the subscription and ignoring the NOTIFY. Please grab the updated source and let me know if it fixes things for you.
I think some of my problems are related to these anomalies.
I agree. I've done the bulk of my testing with UDP to this point, too, so there may be assumptions in the code that are stumbling over TCP. I'll try to remedy that.
Thanks for your very helpful report!
Best, andrew
-
Andrew Mortensen -
Robert Boisvert