[cisco-voip] CUCM 7.x Local Route Group

[Joel Perez]

Good morning list,

I was curious if anyone out there has ran into this issue with Local Route
Groups.
We just started deploying this for customers recently. Im pretty sure I have
the process down packed except for one thing.
Call Forwarding to Offnet destinations. If the originating calls are onnet
within the clusters everything works fine. However If the originating call
is an offnet # then the call fails.

On my SIP GW im getting a “SIP/2.0 404 Not Found Reason: Q.850;cause=1”.
Invite is sent to the CUCM cluster , GW gets a “100 Trying” and then the
404. Ran some traces on CUCM and get the same thing. Read up a little more
on “Local Route Groups” and noticed a small section in the Features and
Services guide about forwarding. It states that supplementary services when
used skip the Local Route group. If there isn’t anything else in the RL
other than the Local Route Group then the call basically dies and you get
the 404. According to that same section the reason it works when the call
originates onnet is because the originating device uses its LRG assigned by
the Device Pool to send the call.
We tested by adding a RG with a GW in it and the Forwarding completed. We
also testing by creating a separate Partition and Route Pattern pointing to
the correct RG and the forwarding also completed.

We would prefer not to have to create additional RP’s or add RG to the RL
containing the Local Route Group because it kind of defeats the purpose.
Granted, it will still shrink the required amount of RP’s considerably in a
multisite environment with multiple GW’s but still.
The Local Route Group has spoiled us and we want it all now.

Are the above 2 solutions we found the only ones out there? We never ran
into it so far because our customers have been blocking offnet to offnet
forwarding. But there is always one that changes the way you do things.

Thanks,
Joel P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100226/8c26ad50/attachment.html>