[Serusers] rewrite & ACK forwarding problem

[Greg Fausak]

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 at nic.at>
>To: <serusers at 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 at 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 at 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 at xx.xx.xx.xx:5060>
>>
>> (10) SER -> phone
>> SIP/2.0 200 OK
>> Contact: <sip:0699xxxxxxx at xx.xx.xx.xx:5060>
>>
>> [ call established, we can talk, but ... ]
>>
>> (11) phone -> SER
>> ACK sip:0699xxxxxxxx at 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 at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>