[Users] ACK Routing: Best practices?
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Aug 4 08:24:10 CEST 2006
On Fri, August 4, 2006 8:10, raviprakash sunkara said:
> Hi Klaus,
>
> For me the same problem , But problem in Bye message , openser system
> didn't recieve the Bye request from the UAC's.....
1. This is not the same problem
2. You have a NAT problem
3. The client will send the BYE to the iP address in the Record-Route
header (if you use record_route()). Thus, make sure to announce the public
IP address and setup a port forwarding from this public IP to the SIP
proxy.
regards
klaus
> When its connected Behind the NAT with Different networks...
> IN local network its really fine...
>
> that means Not working in outside the world..
>
> On 8/2/06, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>>
>> Hi Carsten!
>>
>> First I would differ between ACK and CANCEL.
>>
>> If you use statefull forwarding, then it is sufficient to just t_relay,
>> as tm will take care of hop-by-hop canceling. There is no need to
>> rewrite the R-URI. There is only one problem: If the INVITE processing
>> takes more time, than it may happen that the CANCEL hits the tm module
>> before the tm module created a transaction. Thus, I discard CANCEL
>> without existing transactions.
>>
>> ACK: There are 3 kinds of possible ACK.
>> 1. stateless, e.g. if you use sl_send_reply("404",""), then the client
>> will send a "stateless" ACK. This ACK will be absorbed by openser as
>> soon as it is received and will never enter the routing logic. Thus, we
>> do not have to care about them.
>>
>> 2. statefull, sucessful call: The INVITE was answered with 200, thus the
>> caller sends an ACK to the callee. This ACK is in-dialog, and thus
>> should be routed by the loose_route block (no need to rewrite any URI)
>>
>> 3. statefull, unsuccessful call: The call was rejected or cancelled.
>> Thus, we have hop-by-hop ACKs. Thus, the ACK must be handled to the tm
>> moudle, which takes care of it (no need to rewrite any URI).
>>
>> here is how I handle ACK and CANCEL. I did not had any issues with this
>> (running now since 1 year).
>>
>>
>> if ( is_method("CANCEL") && !t_check_trans() ) {
>> # CANCEL without matching INVITE transaction, ignore
>> # may happen if the INVITE is slower than the CANCEL
>> # ignore the CANCEL, as the client will retransmit it, and maybe
>> next time
>> # the INVITE transaction is already created
>> xlog("L_WARN","$ci CANCEL without matching transaction ... ignore
>> and discard.\n");
>> exit;
>> }
>> route(8); # disable mediaproxy (needs to see valid CANCEL
>> requests)
>> force_send_socket(83.136.32.160:5060); # force port 5060 as sending
>> port
>> if ( is_method("CANCEL") ) {
>> # CANCEL with matching INVITE transaction, just
>> # t_relay
>> xlog("L_INFO","$ci CANCEL with matching transaction ...
>> t_relay.\n");
>> t_relay();
>> exit;
>> }
>> # check every message for Remote-Party-Id: header and remove it
>> if (is_present_hf("Remote-Party-ID")) {
>> xlog("L_INFO", "$ci Remote-Party-ID header present ...removing\n");
>> remove_hf("Remote-Party-ID");
>> }
>> if (loose_route()) {
>> # loose route requests are not authenticated
>> xlog("L_INFO","$ci beginning loose_route processing...\n");
>> route(32); # handle in-dialog requests
>> exit;
>> }
>> if ( is_method("ACK") ) {
>> if ( t_check_trans() ) {
>> # non loose-route, but stateful ACK; must be an ACK after a 487
>> xlog("L_INFO","$ci local end-to-end ACK for an existent INVITE
>> transaction detected ...t_relay()\n");
>> t_relay();
>> } else {
>> xlog("L_WARN","$ci ACK without matching transaction ... ignore
>> and discard.\n");
>> }
>> exit;
>> }
>> if ( has_totag() ) {
>> # in-dialog requests should be handled by loose_route
>> # this should be fixed in the client or in openser
>> xlog("L_ERR","$ci in-dialog request was not catched by loose_route
>> block, 403... \n");
>> xlog("L_ERR","$ci this is the complete message:\n");
>> xlog("L_ERR","$ci $mb\n");
>> sl_send_reply("403","in-dialog request without loose_route is not
>> allowed, this is a bug in the client or in this proxy\n");
>> exit;
>> }
>> route(7); # proxy authentication
>>
>>
>>
>> regards
>> Klaus
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Carsten Bock wrote:
>> > Hi everybody,
>> >
>> > Short question: Are there any best practices regarding the routing of
>> > ACK Messages?
>> > Currently we have the following logic implemented:
>> >
>> > route {
>> > [...]
>> >
>> >
>> ##################################################################################################################
>> >
>> > # Check for Re-Transmissions (not ACK/CANCEL)
>> >
>> >
>> ###############################################################################################################
>> >
>> > if ((method != "CANCEL") && (method != "ACK")) {
>> > if (t_check_trans()) {
>> > log(1, "Re-Transmission detected, message dropped.\n");
>> > # Drop the message silently.
>> > return;
>> > }
>> > }
>> >
>> >
>> ##################################################################################################################
>> >
>> > # Loose-Routing (RFC3261)
>> >
>> >
>> ###############################################################################################################
>> >
>> > if (loose_route()) {
>> > route(10);
>> > return;
>> > }; # if (loose_route()) {
>> >
>> ##################################################################################################################
>> >
>> > # ACK/CANCEL Messages may be relayed
>> >
>> >
>> ###############################################################################################################
>> >
>> > if ((method == "CANCEL") || (method == "ACK")) {
>> > if (uri != myself) {
>> > # Und das Paket entsprechend weiterleiten
>> > if (!t_relay("udp:outbound_proxy:outbound_proxy_port")) {
>> > log(1, "Not possible to relay\n");
>> > # Fehler melden
>> > sl_reply_error();
>> > return;
>> > }
>> > return;
>> > }
>> > }
>> > [...]
>> >
>> >
>> ##################################################################################################################
>> >
>> > # Rest of "normal" Routing logic with number manipulation / Routing
>> > to different Gateways / User Authorization/Authentication
>> >
>> >
>> ###############################################################################################################
>> >
>> > }
>> >
>> > Is there any other method, to improve the routing of ACK/CANCEL
>> > Messages? I would like to avoid all the number manipulation, checking
>> > and choosing of a proper gateway....
>> > I thought, this must (somehow) be possible since from a technical
>> > perspective the ACK and CANCEL Message can be associated with a
>> > corresponding INVITE Message (and the corresponding Transaction).
>> > I've looked in the manual of the TM-Module and found the following
>> example:
>> > if ( is_method("CANCEL") ) {
>> > if ( t_check_trans() )
>> > t_relay();
>> > exit;
>> > }
>> > (http://openser.org/docs/modules/1.1.x/tm.html#AEN460)
>> >
>> > I guess, this example does not mean, that the URI gets rewritten
>> > properly and the CANCEL-/ACK-Message would get properly relayed to the
>> > destination, where it is supposed to end.
>> > Is there any way to do it best? I've seen, that some clients do proper
>> > loose-routing for ACK-Messages, but not all clients, so this is not a
>> > solution.
>> > Are there any other suggestions?
>> >
>> > Thanks in advance,
>> >
>> > Carsten
>> >
>> >
>> >
>> > ____________
>> > Virus checked by G DATA AntiVirusKit
>> >
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at openser.org
>> > http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
> --
> Thanks and Regards with cheers
> Sunkara Ravi Prakash (Voip Developer)
> Hyperion Technology
> Kondapur, Hi-tech city,
> Hyderabad.
> www.hyperion-tech.com
> +91-9985077535
>
More information about the Users
mailing list