9 Oct
2008
9 Oct
'08
10:05 p.m.
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(a)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(a)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!