I have a situation where SER is gumming up the works. The problem is that I have a call where the INVITE fails because a PSTN gateway hasn't authorized the SIP invitee to call a given number, as intended. The PSTN switch is returning a "503 Service Unavailable" as is expected, but SER is then sending the SIP invitee a "500 Service Unavailable" instead of the original message, which is wrong in several ways.

Here is the ngrep of what SER received from the PSTN switch (which is the desired answer in this situation):

# U 2008/10/09 18:08:45.045015 10.133.0.2:5060 -> 10.133.90.6:5060 SIP/2.0 503 Service Unavailable. Call-ID: 14407805-3432564525-49719@sbc1.sometelco.com. CSeq: 1 INVITE. From: sip:8019995678@209.x.x.x;tag=3432564525-49731. To: sip:9179891234@208.x.x.x:5060;user=phone;tag=000a0285+1+4bae000a+de6c6831. Via: SIP/2.0/UDP 10.133.90.6;branch=z9hG4bKaa0f.96addb37.0. Via: SIP/2.0/UDP 209.x.x.x:5060;branch=z9hG4bKafec84c056d5d9ac97d27cc12d3dbb92. Server: DC-SIP/2.0. Content-Length: 0. Retry-After: 3. .

That response code (503 Service Unavailable) is what should be sent back to the call originator, who can cope with it and redirect the call. However, here is the ngrep of what SER transmitted on to the invitee instead:

# U 2008/10/09 18:08:45.050440 10.133.90.6:5060 -> 209.x.x.x:5060 SIP/2.0 500 Service Unavailable. To: sip:9179891234@208.x.x.x:5060;user=phone;tag=b11e68d9aa35b34c54f995457fe194f9-0069. From: sip:8019995678@209.x.x.x;tag=3432564525-49731. Call-ID: 14407805-3432564525-49719@sbc1.sometelco.com. CSeq: 1 INVITE. Via: SIP/2.0/UDP 209.x.x.x:5060;branch=z9hG4bKafec84c056d5d9ac97d27cc12d3dbb92. Server: Sip EXpress router (2.0.0-rc1 (x86_64/freebsd)). Content-Length: 0. .

And the calling party receives the confusing "503 Service Unavailable".

The onreply_route routine in use is a strip-down of what is found in the PSTN sample (page 54 of the SER Getting Started manual), and it makes no attempt to alter response codes:

onreply_route["PSTN_REPLY"] { xlog("L_ERR","In onreply_route %rs %rr"); force_send_socket("10.133.90.6"); #emit on em1 fix_nated_contact("208.x.x.x"); /*Fixes Contact:*/

# Apply RTP proxy if necessary, but only for INVITE transactions # and 183 or 2xx replies

if (@cseq.method != "INVITE") return; xlog("L_ERR","onreply_route[INVITE_REPLY] R1 %rs %rr");

if ((status =~ "(183)|2[0-9][0-9]") && search("^(Content-Type|c):.*application/sdp")) { xlog("L_ERR","In onreply_route FIXING PROXY"); force_rtp_proxy("e","208.x.x.x"); } return; }

From debug messages (show below), the call to force_rtp_proxy() is not being performed, so in theory this routine is left with the 503 still intact.

The xlog message shows the 503 value was still there on entry to onreply_route as well as near the end of the routine:

Oct 9 18:08:45 ser1 /usr/local/sbin/ser[1820]: In onreply_route 503 Service Unavailable Oct 9 18:08:45 ser1 /usr/local/sbin/ser[1820]: onreply_route[INVITE_REPLY] R1 503 Service Unavailable The "FIXING PROXY' debug message was not reached, as expected.

So what is causing:

503 Service Unavailable.

to mysteriously turn into

500 Service Unavailable.

which isn't even the correct RFC textual response for a 500 code. This is being seen in ser-2.0.0-rc1 and is completely repeatable.

Ideas? Suggestions? Thanks in advance!