Charles,
One problem I see is that the value for the forwarded number is not a
valid SIP URI.
The values stored in the usr_preferences table must look like this:
sip:4075551212@mycompany.com
As for you question about the "-", "dom", and "int" avp
lines, these
are not database related. Instead this is a bit of a hack. I use these
three values as AVPs which get referenced in other route blocks. The
reason I call this a hack is that it would be better to move this kind
of validation to a custom C module.
Anyhow, the whole point of that route block is to validate the
destination number that the user is trying to have forwarded to. For
example, the user should not be allowed to forward to 911 or an
international number (unless they are entitled to international
dialing).
One more note: That ser.cfg that you're referencing is very unwieldy.
I've since restructured the entire thing for simplicity reasons. This
ser.cfg follows the very simple concepts shown in the default ser.cfg
example.
I feel it is much better to follow a per-method-type approach. For
example in the main route block I now have:
if (method=="BYE") {
route(1); # BYE message handler
} else if (method=="ACK") {
route(2); # ACK message handler
} else ....
I'm hoping to post my entire reworked ser.cfg to the mailing list this
week and seek comments and feedback on establishing "best coding
practices" for ser because as far as I know this hasn't been
addressed. My hopes are that the next ser.cfg I post, would at a
minimum, get the ball rolling on defining how best to code ser.cfg
logic.
Regards,
Paul
On Sun, 20 Feb 2005 12:23:32 +0800, Charles Wang <lazy.charles(a)gmail.com> wrote:
Dear ALL:
I think it is a very good chance to study Paul's ser.cfg file.
I use the 0.9.0 sample cfg and try to implement a call forward, busy
forward, no answer forward function.
But I got a 503 message when I use make a call from UA 1011 to UA
1022(registed on the same ser) with callforward to a PSTN .