[OpenSIPS-Users] fix_route_dialog problem
Guido Negro
guido.negro at gradwell.com
Mon Jan 24 17:35:50 CET 2011
Hi,
thanks for your reply.
I am using the script reported in the Opensips book ("Building telephony
systems with Opensips") at page 81, that is :
if (has_totag() ) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route() ) {
if (is_method("BYE" ) ) {
setflag(1) ; # do accounting . . .
setflag(3 ) ; # . . . even if the transaction fails
} else if ( is_method( "INVITE" ) ) {
# even if in most of the cases is useless, do RR for
# re-INVITEs alos, as some buggy clients do change route set
# during the dialog.
record_route() ;
}
# route it out to whatever destination was set by loose_route()
# in $du (destination URI) .
route( 1) ;
} else {
if ( is_method(" ACK") ) {
if ( t_check_trans( ) ) {
# non loose- route, but stateful ACK; must be an ACK after
# a 487 or e. g. 4 04 from upstream server
t_relay() ;
exit;
} else {
# ACK without matching transaction ->
# ignore and discard
exit;
}
}
sl_send_reply("4 04" , " Not here") ;
}
exit;
}
Now I've got 2 problems. When a BYE with correct to/from tag & correct
call-id, but without any route headers arrives (a message I'd like to
'fix'):
1) I get the variable $DLG_status to be <null> after loose_route() (I
checked with specific experiments) and this also causes an error in the
log: opensips[3216]: ERROR:dialog:w_validate_dialog: null dialog
2) loose_route() fails, so I always get a 404 response on the callee
side that tried to disconnect, and the caller remains connected.
I am probably using fix_route_dialog not in the correct way, but what I
wanted to do is something like this (very-pseudo code):
When loose_route fails (or more in general for every in-dialog
subsequent request):
Try to fix the request according to saved dialog infos:
- Fix succesful: forward the request.
- Couldnt fix it: reject the request (send 404 back).
Regards,
Guido.
On 24/01/11 11:34, Vlad Paiu wrote:
> Hello,
>
> The function fix_route_dialog() needs loose_route() to be called, in
> order to set the current dialog pointer that fix_route_dialog() will
> attempt to match and fix accordingly. It isn't mandatory to call
> validate_dialog() first, but it is best practice, because a call to
> validate_dialog() function is very light, while fix_route_dialog()
> makes heavy changes to the SIP msg.
>
> A very basic example of script to fix only BYEs would be
>
> if (has_totag()) {
> loose_route();
>
> if (is_method("BYE"))
> if (!validate_dialog())
> fix_route_dialog();
> }
>
> The dialog structure is not cleared from OpenSIPS memory when BYE is
> received. This happens when the respective transaction ends, so the
> above example should work just fine.
>
> Could you please post the script you are using and a high level debug
> log from OpenSIPS ?
>
>
> On 01/24/2011 12:26 PM, Guido Negro wrote:
>> Hi,
>>
>> I encountered some problems while trying to use fix_route_dialog()
>> function.
>>
>> Basically what I'd like to do is to use this function to correct
>> Route headers of the BYE messages that
>>
>> * have wrong or no Route header at all
>> * have valid to/from & call-id information ( 'valid' in respect
>> to dialog infos saved in opensips )
>>
>> I tried to use it as suggested in the documentation, that is
>>
>> if (has_totag()) {
>> loose_route();
>> if ($DLG_status!=NULL)
>> if (!validate_dialog())
>> fix_route_dialog();
>> }
>>
>>
>> The problem is that when a BYE comes in, the dialog is automatically
>> deleted in opensips, so I can never really reach fix_route_dialog()
>> call in the case I want to actually use it.
>>
>> Should I do something like
>>
>> if (is_method("BYE"))
>> fix_route_dialog();
>>
>>
>> Is fix_route_dialog() supposed to work even without the checks that
>> are in the doc's code snippet?
>>
>>
>> Thank you very much,
>>
>>
>> Guido.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
More information about the Users
mailing list