[Devel] failure route and lcr (non standard routing/scenario)

[Ovidiu Sas]

Hi,


I'm trying this non standard scenario and I almost got it working ...
I would like to re-route a call in case of a failure via lcr, after
the call was routed via usrloc.

Here's the scenario:
A call is placed to a registered user.  The user is found in the
usrloc db and the INVITE is forwarded to the callee (the call is in
progress between the two users).
Then the callee doesn't answer the call, and when the timer fires.
In the failure route, lcr is used to route the call via the gws, but
because Icr is invoked first time in a failure route, we need to
manually set the ruri_user_avp.


Everything seems to work ok, except that the INVITE that is sent out
is malformed.

Here are the relevant logs:

caller: 2110105
callee: 2110103

The INVITE is received by openser and the callee is found in the usrloc db:
Mar 13 23:52:36 LKG7BE78E oser[3238]: parsed uri:  type=1
user=<2110103>(7)  passwd=<>(0)  host=<192.168.2.22>(12)  port=<>(0):
0  params=<>(0)  headers=<>(0)
Mar 13 23:52:36 LKG7BE78E oser[3238]:  uri params:    transport=<>,
val=<>, proto=0
Mar 13 23:52:36 LKG7BE78E oser[3238]:    user-param=<>, val=<>
Mar 13 23:52:36 LKG7BE78E oser[3238]:    method=<>, val=<>
Mar 13 23:52:36 LKG7BE78E oser[3238]:    ttl=<>, val=<>
Mar 13 23:52:36 LKG7BE78E oser[3238]:    maddr=<>, val=<>
Mar 13 23:52:36 LKG7BE78E oser[3238]:    lr=<>
Mar 13 23:52:36 LKG7BE78E oser[3238]: rewrite_uri: Rewriting
Request-URI with 'sip:2110103 at 192.168.2.100:5052'


the callee doesn't answer, we handle this in the failure_route, and a
new request URI is constructed inside an avp and then pushed to $ru:

$avp(i:1) = "4169771414"
$avp(i:1) = "sip:" + $avp(i:1) + "@" + "192.168.2.22";
$ru = $avp(i:1);
$avp(i:1) = null;
$avp(i:1) = null;
setflag(5);
route(20);

In the route[20]:

if (lookup("location")) {
 ...
} else if (does_uri_exist()) {
 ...
} else {
  if (isflagset(5)) {
    resetflag(5);
    $avp(i:500) = $rU;  # <<< here we set the ruri_user_avp
    load_gws()
    next_gw()

and here are the logs:

The 408 is received:
Mar 13 23:52:45 LKG7BE78E oser[3243]: DEBUG:t_check_status: checked
status is <408>
Mar 13 23:52:45 LKG7BE78E oser[3243]: parsed uri:  type=1
user=<2110103>(7)  passwd=<>(0)  host=<192.168.2.100>(13)
port=<5052>(4): 5052  params=<>(0)  headers=<>(0)
Mar 13 23:52:45 LKG7BE78E oser[3243]:  uri params:    transport=<>,
val=<>, proto=0
Mar 13 23:52:45 LKG7BE78E oser[3243]:    user-param=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    method=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    ttl=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    maddr=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    lr=<>

we update the $ru from avp and route through usrloc db:
Mar 13 23:52:45 LKG7BE78E oser[3243]: parsed uri:  type=1
user=<4169771414>(10)  passwd=<>(0)  host=<192.168.2.22>(12)
port=<>(0): 0  params=<>(0)  headers=<>(0)
Mar 13 23:52:45 LKG7BE78E oser[3243]:  uri params:    transport=<>,
val=<>, proto=0
Mar 13 23:52:45 LKG7BE78E oser[3243]:    user-param=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    method=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    ttl=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    maddr=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    lr=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]: lookup(): '4169771414' Not found in usrloc

the user doesn't exist:
Mar 13 23:52:45 LKG7BE78E oser[3243]: does_uri_exit(): User in request
uri does not exist

then the ruri_user_avp is manually set:
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:avpops:print_avp:
p=0x4079b710, flags=0x0002
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:                     id=<500>
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:
val_str=<4169771414 / 10>

then we load_gws() followed by the next_gw()
Mar 13 23:52:45 LKG7BE78E oser[3243]: DEBUG:lcr:load_gws: add
matched_gws[0]=[0,2]
Mar 13 23:52:45 LKG7BE78E oser[3243]: load_gws(): DEBUG: Added
gw_uri_avp <sip:|0 at 192.168.2.20:5060;transport=udp>
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:avpops:print_avp:
p=0x4079b770, flags=0x0002
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:                     id=<1400>
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:
val_str=<sip:|0 at 192.168.2.20:5060;transport=udp / 38>
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:avpops:print_avp:
p=0x4079b710, flags=0x0002
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:                     id=<500>
Mar 13 23:52:45 LKG7BE78E oser[3243]: INFO:
val_str=<4169771414 / 10>

and after that we call t_on_failure():
Mar 13 23:52:45 LKG7BE78E oser[3243]: parsed uri:  type=1
user=<4169771414>(10)  passwd=<>(0)  host=<192.168.2.20>(12)
port=<5060>(4): 5060  params=<transport=udp>(16)  headers=<>(0)
Mar 13 23:52:45 LKG7BE78E oser[3243]:  uri params:
transport=<transport=udp>, val=<udp>, proto=0
Mar 13 23:52:45 LKG7BE78E oser[3243]:    user-param=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    method=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    ttl=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    maddr=<>, val=<>
Mar 13 23:52:45 LKG7BE78E oser[3243]:    lr=<>


and the issue here is the params: params=<transport=udp>(16)
transport=udp has a length of 13, but the debug logs shows 16 and
therefore the request URI in the INVITE that is sent out has three
extra characters.



Regards,
Ovidiu Sas