Hi,
I am trying to develop some features which requires to call load_gws and next_gw in a failure route. For example, in normal routing block, it forwards the call to a subscriber's ip phone locations. If nobody answer, it tries to call a pstn number. In the failure route, i called load_gws and next_gw. However it generates an error "next_gw(): No ruri_user AVP". Looking at the code, there seems to be an assumption that first time call to next_gw always happens in the normal routing block. But in my case, it calls next_gw first time in a failure route. I even tried to manually add the new uri's username to avp i:1402. It still won't work.
Is it possible to call next_gw first time in a failure route?
Thanks, Richard
Richard Z writes:
I am trying to develop some features which requires to call load_gws and next_gw in a failure route. For example, in normal routing block, it forwards the call to a subscriber's ip phone locations. If nobody answer, it tries to call a pstn number. In the failure route, i called load_gws and next_gw. However it generates an error "next_gw(): No ruri_user AVP". Looking at the code, there seems to be an assumption that first time call to next_gw always happens in the normal routing block. But in my case, it calls next_gw first time in a failure route. I even tried to manually add the new uri's username to avp i:1402. It still won't work.
Is it possible to call next_gw first time in a failure route?
no it isn't. in your example it would not help even if that rule was relaxed because load_gws loads gws based on pstn number in request uri, which may not be the same as subscriber's sip phone number.
you can achieve what you want by first doing load_contacts/next_contacts where next contact points to pstn uri, which will route back to the proxy.
-- juha
On 10/31/05, Juha Heinanen jh@tutpro.com wrote:
Is it possible to call next_gw first time in a failure route?
no it isn't. in your example it would not help even if that rule was relaxed because load_gws loads gws based on pstn number in request uri, which may not be the same as subscriber's sip phone number.
The gateways are based on the current requiest uri. In this case, it should use the pstn number, instead of the subscriber's number. It would help in this case, right?
you can achieve what you want by first doing load_contacts/next_contacts where next contact points to pstn uri, which will route back to the proxy.
Next_contacts and next_gw would have the same issue. It also requires to be called in the normal routing block first. How do I make the locations as first contact and pstn gateway as the second contact?
-- juha
Richard Z writes:
The gateways are based on the current requiest uri. In this case, it should use the pstn number, instead of the subscriber's number. It would help in this case, right?
might.
Next_contacts and next_gw would have the same issue. It also requires to be called in the normal routing block first. How do I make the locations as first contact and pstn gateway as the second contact?
what i meant is that you install the pstn uri as a permanent location for the user with smaller q value than the sip phone uri. then request to pstn would be routed back to the proxy where you can call load_gws for it.
-- juha
-
Juha Heinanen -
Richard Z