[Users] dialog module configuration question
Michel Bensoussan
michel at extricom.com
Tue Feb 27 09:56:36 CET 2007
Hi
If I understand your solution, you don't allow the session. And what if
($dlg_count != 0) ?
I tried this. It seems to work but I just quick check it.
The key in "Callid" but I'm not sure it is a good choice. Maybe "To" is
better.
Add the following function in dlg_hash.c:
(based on release 1.1.1)
struct dlg_cell* lookup_dlg_callid(str* callid)
{
struct dlg_cell *dlg;
struct dlg_entry *d_entry;
int i;
if (d_table==0)
goto not_found;
for( i=0 ; i<d_table->size; i++ ) {
d_entry = &(d_table->entries[i]);
dlg_lock( d_table, d_entry);
for( dlg=d_entry->first ; dlg ; dlg=dlg->next ) {
if (!memcmp(dlg->callid.s, callid->s, dlg->callid.len)) {
if (dlg->state==DLG_STATE_DELETED) {
dlg_unlock( d_table, d_entry);
goto not_found;
}
dlg->ref++;
dlg_unlock( d_table, d_entry);
DBG("DEBUG:dialog:lookup_dlg_callid: dialog callid='%.*s' found
on entry %u.%u\n",
callid->len, ZSW(callid->s), dlg->h_id, dlg->h_entry);
return dlg;
}
}
dlg_unlock( d_table, d_entry);
}
not_found:
DBG("DEBUG:dialog:lookup_dlg: no dialog callid='%.*s' found\n",
callid->len, ZSW(callid->s));
return 0;
}
In dlg_handlers.c, modify dlg_onroute() as following:
void dlg_onroute(struct sip_msg* req, str *route_params, void *param)
{
struct dlg_cell *dlg = 0;
str val;
str callid;
int h_entry;
int h_id;
/* If find rm_param do as previously */
if (d_rrb.get_route_param( req, &rr_param, &val) == 0) {
DBG("DEBUG:dialog:dlg_onroute: route param is '%.*s' (len=%d)\n",
val.len, val.s, val.len);
if ( parse_dlg_rr_param( val.s, val.s+val.len, &h_entry, &h_id)<0 )
return;
dlg = lookup_dlg( h_entry, h_id);
if (dlg==0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: unable to find dialog\n");
return;
}
}else if (req->callid){
/* If rm_param not found, look for callid */
dlg = lookup_dlg_callid(&req->callid->body);
if (!dlg){
DBG("DEBUG:dialog:dlg_onroute: Callid '%.*s' not found\n",
req->callid->body.len, req->callid->body.s);
return;
}
}
if (use_tight_match) {
if ((!req->callid && parse_headers(req,HDR_CALLID_F,0)<0) ||
!req->callid) {
LOG(L_ERR, "ERROR:dialog:dlg_onroute: bad request or "
"missing CALLID hdr :-/\n");
return;
}
callid = req->callid->body;
trim(&callid);
if (dlg->callid.len!=callid.len ||
strncmp(dlg->callid.s,callid.s,callid.len)!=0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: tight matching
failed\n");
return;
}
}
if (req->first_line.u.request.method_value==METHOD_BYE) {
if (remove_dlg_timer(&dlg->tl)!=0) {
unref_dlg( dlg , 1, 0);
return;
}
if (dlg->state!=DLG_STATE_CONFIRMED)
LOG(L_WARN, "WARNING:dialog:dlg_onroute: BYE for "
"unconfirmed dialog ?!\n");
/* dialog terminated (BYE) */
run_dlg_callbacks( DLGCB_TERMINATED, dlg, req);
unref_dlg(dlg, 2, 1);
if_update_stat( dlg_enable_stats, active_dlgs, -1);
return;
} else {
/* within dialog request */
run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req);
}
if (req->first_line.u.request.method_value!=METHOD_ACK) {
dlg->lifetime = get_dlg_timeout(req);
update_dlg_timer( &dlg->tl, dlg->lifetime );
}
unref_dlg( dlg , 1, 0);
return;
}
Andy Pyles wrote:
> HI Michel,
>
> Well here's what I'm doing:
>
> if ( loose_route() {
> if($DLG_status == 0 && method!="BYE" ){ *** assuming latest patch
> accepted
> xlog("L_INFO", "broken ua, dropping packet\n");
> exit();
> }
> }
>
> This isn't the most elegant solution, but in my case works ok.
> Basically Lets say the UAC is broken. The first opportunity to tell it
> is "broken" is when it sends an ACK to the 200 OK.
> At this point, it would be very nice to have an option to send "BYE",
> but as this functionality isn't there yet, we just reject the ACK, and
> eventually the broken UAC will send a bye.
>
> There may be other corner cases as well, but you get the general idea.
>
> Andy
>
>
> On 2/26/07, Michel Bensoussan <michel at extricom.com> wrote:
>> Hi
>>
>> "I think the best approach is to force the UAC vendors to align to the
>> SIP specifications."
>>
>> Well..... Good luck.
>> I don't know why but I think if I call and tell them "get back all you
>> products and upgrade them to align to the SIP specification" they won't
>> listen to me. But may be I'm wrong.
>>
>> Any way. I have to deal with it. Do you have some suggestions? What is
>> the best dialog module version to start with?
>>
>> I'm not familiar with SIP but I understand that the "To" header won't
>> change during a session. Is that right? I'm not sure the "CallID" will
>> be them same in case of re-INVITE.
>> So I can save the "To" header in the dialog table and check it if the
>> rm_param is not found.
>> I'm not sure how to do this.
>>
>> Andy, If you have some suggestions too...
>>
>> Regards,
>> Michel.
>>
>> Bogdan-Andrei Iancu wrote:
>> > Hi Michael,
>> >
>> > as you give you the same answer as to Andy :) :
>> >
>> > "To be honest I'm not fan of complicating my life just to support
>> > broken stuff :)....doing dialog matching in traditional way (without
>> > using RR stuff) is very costly and since complete, un-altered RR
>> > mirroring is mandatory by RFC3261, I see no point of doing it
>> > different. "
>> >
>> > I think the best approach is to force the UAC vendors to align to the
>> > SIP specifications.
>> > regards,
>> > bogdan
>> >
>> >
>> > Michel Bensoussan wrote:
>> >> Hi Bogdan
>> >> I'm agree with you, but we cannot control the UAS devices so we have
>> >> to handle the case it doesn't correctly mirror the RR header. Can we
>> >> base the dialog states on From and To headers? or Callid? I
>> >> understand the the rr_param is used for fast dialog matching (dialog
>> >> README). Checking dialog matching with headers (From, To, ...),
>> >> will consequently slowing the transaction?
>> >>
>> >> Regards,
>> >> Michel.
>> >>
>> >> Bogdan-Andrei Iancu wrote:
>> >>> Hi Michel,
>> >>>
>> >>> looking at the net capture, it seams that the UAS device
>> >>> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
>> >>> header - it is removing the hdr parameters, mirroring only the URI,
>> >>> which is bogus.
>> >>>
>> >>> regards,
>> >>> bogdan
>> >
>> >
>> >
>>
>
>
More information about the sr-users
mailing list