Call Pickup using dialoginfo or dialog modules

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Call Pickup using dialoginfo or dialog modules

jay1017
Hello Everyone,
I have been reading all the posts and examples regarding the call pickup implementation using opensips but still could not get a clear idea on how make it work in a simplified way.
Basically I have the following questions:
1) Does it require for the endpoint to SUBSCRIBE for the users whose dialog state it needs to learn?
2) Is it possible that we enter some values in a database which opensips can look into and decide which all users should get a NOTIFY for the dialog states of a particular user? Some values in xcap table probably, which will tell opensips about whom to NOTIFY when there is a call for a specific user.
3) If I am looking at only implementing the pickup scenario and no other presence related features, is it possible that only the dialog-event states are PUBLISHED and no other Presence events are required to be PUBLISHED and NOTIFIED?
4) Please correct me if I am wrong; When A calls B and C needs to Pick it up, C should first receive a NOTIFY from Opensips consisting of local/remote elements, C can then send an INVITE with replaces header and the call will be Picked up. I just wanted to make sure if my understanding is correct here.

Finally, is it in some way possible to just use the dialog module and patch/bridge the call of the caller with the one who is trying to pick up as we are aware of the ongoing dialogs? Something like it is explained here:
http://opensips.org/pipermail/users/2012-January/020476.html
In the above post, the call can be caught in the failure route, but can it be bridged to the person who is trying to PickUp. Any examples of how to achieve this will be very much appreciated.

Thanks,

--- Jayesh

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Call Pickup using dialoginfo or dialog modules

jay1017
Hello All,
I had the Call Pickup tested successfully with Polycom Phones and Opensips Devel version. Just for anyone with a similar knowledge deficiency, here are the things that take place in a Call-Pickup Scenario using Event: Dialog. Might help someone :)

1) Scenario: A calls B, and C tries to pickup the call and get connected to A.
2) A calls B and B is now ringing. Dialog State is now Early.
3) The pua_dialoginfo module takes care of sending PUBLISH requests on behalf of the caller and callee to the presense server.
4) Make sure you set the caller_spec and callee_spec parameter so that the PUBLISH requests are sent properly.
5) In Polycom, you need to enable Directed Pickup from the configuration file so as to get a Pickup softkey when you press "New Call".
6) When you press the Pickup button, it gives option to dial the number that you wish to pickup.
7) From C Endpoint, Dial B and press "Directd" softkey on Polycom.
8) This first sends a SUBSCRIBE request to opensips, with Event: Dialog and Accept: application/dialog-info+xml Headers.
9) Opensips should reply with NOTIFY with body containing the dialog information of B. This is very well explained in the pua_dialoginfo module documentation. The NOTIFY primarily contains call-id, tags and local/remote elements.
10) The C then again sends an INVITE to opensips with replaces header containing callid, to-tag, from-tag. The replaces header in the INVITE looks somewhat like this: Replaces: 3f014841f05d7540;to-tag=b43ffb05;from-tag=C3F7DCE0-75F885;early-only
11) Opensips relays this to A.
12) A then sends a CANCEL to the request generated for B.
13) Transaction at B gets Cancelled.
13) A then sends a 200 OK and gets connected to C.

The call initiated by A to B is thus picked up by C. Here is the sample configuration file which does this. Please note: This config file does not have any authentication/authorization set and is only meant to test the call pickup scenario.

####### Global Parameters #########

debug=3
log_stderror=no
log_facility=LOG_LOCAL0

fork=yes
children=4

disable_tcp=yes

listen=udp:203.XXX.53.XXX:5060


####### Modules Section ########

#set module path
mpath="/usr/local/lib64/opensips/modules/"

/* uncomment next line for MySQL DB support */
loadmodule "db_mysql.so"
loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "sipmsgops.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "uri.so"
loadmodule "dialog.so"
loadmodule "nathelper.so"
loadmodule "nat_traversal.so"
loadmodule "presence.so"
loadmodule "presence_xml.so"
loadmodule "presence_dialoginfo.so"
loadmodule "pua.so"
loadmodule "pua_dialoginfo.so"

# ----------------- setting module-specific parameters ---------------

modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")

modparam("rr", "append_fromtag", 0)

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

modparam("uri", "use_uri_table", 0)

modparam("nat_traversal", "keepalive_interval", 25)
modparam("nat_traversal", "keepalive_from", "[hidden email]")

modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 0)

modparam("presence", "db_url", "mysql://user:password@localhost/novanet")
modparam("presence", "server_address", "sip:203.XXX.53.XXX:5060")
modparam("presence", "mix_dialog_presence", 1)
modparam("presence", "fallback2db", 1)

modparam("presence_xml", "force_active", 1)

modparam("pua", "db_table", "pua")
modparam("pua", "db_url", "mysql://user:password@localhost/novanet")

modparam("presence_dialoginfo", "force_single_dialog", 1)

modparam("pua_dialoginfo", "caller_spec_param", "$avp(caller)")
modparam("pua_dialoginfo", "callee_spec_param", "$avp(callee)")


modparam("presence_xml", "integrated_xcap_server", 1)

#---Routing Logic Begins---

route{

    if (!mf_process_maxfwd_header("10")) {
        sl_send_reply("483","Too Many Hops");
        exit;
    }
   
    # record routing
    if (!is_method("REGISTER|MESSAGE")) {
        record_route();
    }
   
    if (is_method("SUBSCRIBE") || is_method("PUBLISH")) {
        route(presence_requests);
        exit;
    }
   
    if (is_method("INVITE") && !has_totag()) {
        if(client_nat_test("7")) {
            add_rr_param(";nat=yes"); #---To identify the NATed clients and Record Route properly---
        }
    }

    if (has_totag()) {
        if (loose_route()) {
            if (is_method("INVITE") || is_method("UPDATE") || is_method("ACK") || is_method("BYE")) {
                if (search("^Route:.*;nat=yes")) {
                    force_rport();
                    fix_nated_contact();
                }
            }
            t_relay();
            exit;
        } else {
            if ( is_method("ACK") ) {
                if ( t_check_trans() ) {
                    t_relay();
                    exit;
                } else {
                    exit;
                }
            }
            sl_send_reply("404","Not here");
        }
        exit;
    }

       
    if (is_method("CANCEL"))
    {
        if (t_check_trans()) {
            route(nat_check);
            t_relay();
        }
        exit;
    }

    t_check_trans();

    if (loose_route()) {
        if (!is_method("ACK"))
            sl_send_reply("403","Preload Route denied");
        exit;
    }

    if (is_method("INVITE")) {
        create_dialog();
        route(invite_requests);
        exit;
    }
   
    if (is_method("REGISTER"))
    {
        route(nat_check);
        if (!save("location"))
            sl_reply_error();

        exit;
    }
}


route[1] {
   
    if (!t_relay()) {
        sl_reply_error();
    };
    exit;
}

route[nat_check] {
    if (client_nat_test("7")) {
        force_rport();
        fix_nated_contact();
        nat_keepalive();
    }
}

route[invite_requests] {
    route(nat_check);

    if(!lookup("location")) {
        sl_send_reply("404", "User Not Found");
        exit;
    }
   
    $var(caller) = "sip:"+$fU+"@203.XXX.53.XXX";
    $var(callee) = "sip:"+$rU+"@203.XXX.53.XXX";
   
    $avp(caller) = $var(caller);
    $avp(callee) = $var(callee);
   
    dialoginfo_set("B");
    t_on_reply("1");
    t_relay();
}

route[presence_requests] {
    route(nat_check);
   
    if(is_method("PUBLISH")) {
        handle_publish();
    }
   
    if(is_method("SUBSCRIBE")) {
        handle_subscribe("1");
    }
}

onreply_route[1] {
    if(client_nat_test("1")) {
        fix_nated_contact();
    }
   
    if(t_was_cancelled()) {
        exit;
    }
}

On Mon, Mar 5, 2012 at 12:02 PM, Jayesh Nambiar <[hidden email]> wrote:
Hello Everyone,
I have been reading all the posts and examples regarding the call pickup implementation using opensips but still could not get a clear idea on how make it work in a simplified way.
Basically I have the following questions:
1) Does it require for the endpoint to SUBSCRIBE for the users whose dialog state it needs to learn?
2) Is it possible that we enter some values in a database which opensips can look into and decide which all users should get a NOTIFY for the dialog states of a particular user? Some values in xcap table probably, which will tell opensips about whom to NOTIFY when there is a call for a specific user.
3) If I am looking at only implementing the pickup scenario and no other presence related features, is it possible that only the dialog-event states are PUBLISHED and no other Presence events are required to be PUBLISHED and NOTIFIED?
4) Please correct me if I am wrong; When A calls B and C needs to Pick it up, C should first receive a NOTIFY from Opensips consisting of local/remote elements, C can then send an INVITE with replaces header and the call will be Picked up. I just wanted to make sure if my understanding is correct here.

Finally, is it in some way possible to just use the dialog module and patch/bridge the call of the caller with the one who is trying to pick up as we are aware of the ongoing dialogs? Something like it is explained here:
http://opensips.org/pipermail/users/2012-January/020476.html
In the above post, the call can be caught in the failure route, but can it be bridged to the person who is trying to PickUp. Any examples of how to achieve this will be very much appreciated.

Thanks,

--- Jayesh


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users