[Users] dialog module configuration question

[Bogdan-Andrei Iancu]

Hi Andy,

the patch was accepted, but if no dialog is matched, NULL value is 
returned by related pseudo vars. So try:
       f($DLG_status == NULL && method!="BYE" ){}

regards,
bogdan

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
>> >
>> >
>> >
>>
>