I have also had problems with getting the ACK back. I don't completely understand your configuration, you must allow for packets going both directions, right? Here is my config :

route { # check to see if the message has been around too long # probably means that it is looping # if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break; };

# # make sure the length of the message isn't too long! # if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; };

# # do the loose-routing thing, this is important! # if(loose_route()) { log(1,"doing top loose route"); t_relay(); break; };

# this is where I was dropping the ACKS. # I was simply dropping these, but they must be relayed # because they can be ACKs if(!(uri==myself)) { if(!t_relay()) { sl_reply_error(); break; }; break; };

This gets the ACKs through for me.

By the way, I have this configured with Cisco ATAs, version 2.16. ---greg

I have the same problem and posed it to the group yesterday ([Serusers] Ignored 200 OK message.) So far the only workaround that I have found is to use the rules in my gateway to rewrite the dialed digits before sending them to the PSTN PRI, thus leaving the origianl URI intact for SIP communications.

One person told me that this is a bug in the Cisco ATA, but it happens on my IPDialog phones also. It seems to me that the INVITE is being processed by the SER dial rules and is rewritten, but the ACK is not.

Sean _______________________________________________

Sean Robertson

NETXUSA p. 800-289-6389 f. 864-233-4344 "Ask me about Voice over IP." http://www.netxusa.com/

----- Original Message ----- From: "Alexander Mayrhofer" axelm@nic.at To: serusers@lists.iptel.org Sent: Friday, June 27, 2003 12:15 PM Subject: [Serusers] rewrite & ACK forwarding problem

...

Hi,

we're running SER together with a PSTN Gateway. Before a call get's forwarded to the gateway, we are rewriting the request URI to make rewriting on the GW as simple as possible:

route { ... strip(3); # +43xxx -> xxx prefix("0"); # xxx -> 0xxx rewritehostport(xxx.xxx.xxx.xxx, 5060); # request to gateway route(1); break; ...

SIP call flow looks like (record route enabled):

(1) phone -> SER INVITE sip:*43699xxxxxxxx@nic.at43.at SIP/2.0

(2) SER -> phone SIP/2.0 100 trying -- your call is important to us

(3) SER -> GW INVITE sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0

(4) GW -> SER SIP/2.0 100 Trying

(5) GW -> SER SIP/2.0 183 Session Progress

(6) SER -> phone SIP/2.0 183 Session Progress

(7) GW -> SER SIP/2.0 180 Ringing

(8) SER -> phone SIP/2.0 180 Ringing

(9) GW -> SER SIP/2.0 200 OK Contact: sip:0699xxxxxxxx@xx.xx.xx.xx:5060

(10) SER -> phone SIP/2.0 200 OK Contact: sip:0699xxxxxxx@xx.xx.xx.xx:5060

[ call established, we can talk, but ... ]

(11) phone -> SER ACK sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0

--> Here starts the problem. That ACK (11) never gets forwarded to the Gateway, so after a few seconds, the GW starts over at (9). Those three packets (9-11) repeat a few times until GW runs into a timeout and drops the call.

I have the impression that SER can't match the packet to the previous requests because of the rewritten URI. Is that correct?

The only output at debug level 3 is:

Warning: sl_send_reply: I won't send a reply for ACK!!

Is that a routing goof somewhere in our scripts or is that a more generic problem? Is the problem that the warning indicates somehow related to the fact that the ACK is not being forwarded?

Help appreciated.

cheers

axelm

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers