Hi Edoardo,

Normally this would be handled by an Record-Route/Loose-Route construct. When doing record-routing/loose-routing, the in-dialog request "Re-INVITE" (for Music-On-Hold) should take the same route as the initial request (following the route headers) and you should no longer need to query the dispatcher-module for these in-dialog requests. Maybe you could post your config, i guess then we could help a little more.

Carsten

Am Montag, den 12.03.2007, 13:10 +0100 schrieb Edoardo Serra:

Daniel, thanks for your interest in the problem.

I better analyzed the problem and found the point in it. I try to describe where I guess the problem is

When one of our users receive a call from the PSTN, the PSTN Gateway (Asterisk) sends an INVITE at username@openser, the INVITE is correctly forwarded to the user and the call is set up without problems. (RTP from PSTN gw to USER and SIP through OpenSER)

When the user wants to put the caller OnHold it sends an INVITE to OpenSER but OpenSER forwards the INVITE to one of the PSTN GW using dispatcher module. This way, if the INVITE is not forwarded to the PSTN GW which is handling the call a second call is generated.

Do you have any suggestion ? Every kind of help is appreciated.

Sorry for not having sent a network capture, but is quite difficult to prepare such a capture on our system because it's always very busy

Hoping to hear from you soon

Regards

Edoardo

Daniel-Constantin Mierla ha scritto:

...

Hello,

a network trace (ngrep or wireshark) will help to spot what might be the problem, otherwise is hard to guess.

Cheers, Daniel

On 03/04/07 17:32, Edoardo Serra wrote:

...

Hi all, I have an OpenSER server in front of serveral Asterisk acting as a load balancer and registrar server.

We're offering both, inbound and outbound call services.

When an outbound call is made, OpenSER, through the dispatcher module, choose an Asterisk server to handle the media of the call.

When an inbound call is received (by a PSTN GW interconnected with one of the Asterisks), Asterisk calls SIP/username@openser.

Media flows directly from user to Asterisks without using RTPProxy as every Asterisk server has got a public IP Address..

I have the following problem with MOH.

If a user tries to put on hold an outbound call (placed by him) everything is OK, Asterisk start playing MOH and stops when the user wants to stop it.

But, if a user wants to put on hold an inbound call (a call just answered), as soon as it press the hold button another call to the caller is originated and the first call is not put on hold by the Asterisk

I guess the problem is that, in this case, the asterisk doesn't recognise the INVITE as a re-INVITE and originate a new call instead of putting the other on hold.

Do you have any idea on how to solve the problem ? Every suggestion is appreciated.

Regards

Edoardo Serra

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi all, I don't want to bother you about this problem again but I'm a little bit stuck.

Someone can help ?

Tnx in advance

Regards

Edoardo

Edoardo Serra ha scritto:

Tnx Carsten for attention.

My openser.cfg is following I probably contains some misconfiguration as I'm still new to OpenSER

Tnx in advance

Regards

# ----------- global configuration parameters ------------------------ check_via=yes # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 fifo="/tmp/ser_fifo"

# ------------------ module loading ----------------------------------

loadmodule "/usr/lib/openser/modules/sl.so" loadmodule "/usr/lib/openser/modules/tm.so" loadmodule "/usr/lib/openser/modules/rr.so" loadmodule "/usr/lib/openser/modules/maxfwd.so" loadmodule "/usr/lib/openser/modules/usrloc.so" loadmodule "/usr/lib/openser/modules/registrar.so" loadmodule "/usr/lib/openser/modules/nathelper.so" loadmodule "/usr/lib/openser/modules/textops.so" loadmodule "/usr/lib/openser/modules/exec.so" loadmodule "/usr/lib/openser/modules/uri.so" loadmodule "/usr/lib/openser/modules/uri_db.so" loadmodule "/usr/lib/openser/modules/dispatcher.so" loadmodule "/usr/lib/openser/modules/mysql.so" loadmodule "/usr/lib/openser/modules/auth.so" loadmodule "/usr/lib/openser/modules/auth_db.so"

modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "mysql://XXX:XXX@192.168.252.5/openser") modparam("usrloc", "timer_interval", 120)

modparam("auth_db", "calculate_ha1", 0) modparam("auth_db", "db_url", "mysql://XXX:XXX@192.168.252.5/userdb")

modparam("uri_db", "db_url", "mysql://XXX:XXX@192.168.252.5/openser")

modparam("rr", "enable_full_lr", 1)

modparam("registrar", "nat_flag", 6) modparam("registrar", "max_expires", 3600) modparam("registrar", "min_expires", 60) modparam("registrar", "append_branches", 0) modparam("registrar", "desc_time_order", 1)

modparam("nathelper", "natping_interval", 20) # Ping interval 20 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT

modparam("dispatcher", "force_dst", 1)

# ------------------------- request routing logic -------------------

# main routing logic

route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); exit; };

    if ( (method=="OPTIONS") || (method=="SUBSCRIBE") || 

(method=="NOTIFY") ) { sl_send_reply("405", "Method Not Allowed"); exit; }

    if (!method=="REGISTER") {
            record_route();
    };


    if ((src_ip==111.222.333.444) || (src_ip==555.666.777.888)) {
    # IPs of our PSTN gateways
            if (!lookup("location")) {
                    sl_send_reply("486", "Busy here");
                    exit;
            };
            # forward to current uri now; use stateful forwarding; that
            # works reliably even if we forward from TCP to UDP
            if (!t_relay()) {
                    sl_reply_error();
            };
            exit;
    };

    if (nat_uac_test("3")) {
            if ((method=="REGISTER") || (method=="INVITE") || 

(method=="OPTIONS")) { fix_nated_contact(); force_rport(); setflag(6); # Mark as NATed } } # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (method=="REGISTER") { if (!proxy_authorize("exorsa", "openser_view")) { proxy_challenge("exorsa", "0"); exit; } if (!check_to()) { sl_send_reply("403", "Digest username and URI username do NOT match! Stay away!"); exit; }

            save("location");

            exit;
    };


if (method=="INVITE") {
    if (!proxy_authorize("exorsa", "openser_view")) {
        proxy_challenge("exorsa", "0");
        exit;
    }

    if (!check_from()) {
        sl_send_reply("403", "Digest username and URI username do 

NOT match! Stay away!"); exit; } }

    # loose-route processing
    if (loose_route()) {
            # mark routing logic in request
            append_hf("P-hint: rr-enforced\r\n");
            route(1);
            exit;
    };

    if (!uri==myself) {
            # mark routing logic in request
            append_hf("P-hint: outbound\r\n");
            route(1);
            exit;
    };

    append_hf("P-hint: usrloc applied\r\n");
    route(1);

}

route[1] { # !! Nathelper if (uri=~"[@:](192.168.|10.|172.(1[6-9]|2[0-9]|3[0-1]).)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); exit; };

    # NAT processing of replies; apply to all transactions (for 

example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1");

    # send it out now; use stateful forwarding as it works reliably
    # even for UDP2TCP
if ((src_ip!=111.222.333.444) && (src_ip!=555.666.777.888)) {
#IPs of our PSTN Gateways
        ds_select_dst("1", "0");
    }

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

}

# !! Nathelper onreply_route[1] { # NATed transaction ? if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); # otherwise, is it a transaction behind a NAT and we did not # know at time of request processing ? (RFC1918 contacts) } else if (nat_uac_test("1")) { fix_nated_contact(); }; } Carsten Bock ha scritto:

...

Hi Edoardo,

Normally this would be handled by an Record-Route/Loose-Route construct. When doing record-routing/loose-routing, the in-dialog request "Re-INVITE" (for Music-On-Hold) should take the same route as the initial request (following the route headers) and you should no longer need to query the dispatcher-module for these in-dialog requests. Maybe you could post your config, i guess then we could help a little more.

Carsten

Am Montag, den 12.03.2007, 13:10 +0100 schrieb Edoardo Serra:

...

Daniel, thanks for your interest in the problem.

I better analyzed the problem and found the point in it. I try to describe where I guess the problem is

When one of our users receive a call from the PSTN, the PSTN Gateway (Asterisk) sends an INVITE at username@openser, the INVITE is correctly forwarded to the user and the call is set up without problems. (RTP from PSTN gw to USER and SIP through OpenSER)

When the user wants to put the caller OnHold it sends an INVITE to OpenSER but OpenSER forwards the INVITE to one of the PSTN GW using dispatcher module. This way, if the INVITE is not forwarded to the PSTN GW which is handling the call a second call is generated.

Do you have any suggestion ? Every kind of help is appreciated.

Sorry for not having sent a network capture, but is quite difficult to prepare such a capture on our system because it's always very busy

Hoping to hear from you soon

Regards

Edoardo

Daniel-Constantin Mierla ha scritto:

...

Hello,

a network trace (ngrep or wireshark) will help to spot what might be the problem, otherwise is hard to guess.

Cheers, Daniel

On 03/04/07 17:32, Edoardo Serra wrote:

...

Hi all, I have an OpenSER server in front of serveral Asterisk acting as a load balancer and registrar server.

We're offering both, inbound and outbound call services.

When an outbound call is made, OpenSER, through the dispatcher module, choose an Asterisk server to handle the media of the call.

When an inbound call is received (by a PSTN GW interconnected with one of the Asterisks), Asterisk calls SIP/username@openser.

Media flows directly from user to Asterisks without using RTPProxy as every Asterisk server has got a public IP Address..

I have the following problem with MOH.

If a user tries to put on hold an outbound call (placed by him) everything is OK, Asterisk start playing MOH and stops when the user wants to stop it.

But, if a user wants to put on hold an inbound call (a call just answered), as soon as it press the hold button another call to the caller is originated and the first call is not put on hold by the Asterisk

I guess the problem is that, in this case, the asterisk doesn't recognise the INVITE as a re-INVITE and originate a new call instead of putting the other on hold.

Do you have any idea on how to solve the problem ? Every suggestion is appreciated.

Regards

Edoardo Serra

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users