[Users] dialog module configuration question

[Bogdan-Andrei Iancu]

Hi Michel,

my opinion is based on the following thinking. To solve your problem, 
there are 2 ways:
    1) approach openser developers to fix dialog module to cope with 
bugy clients. The result will be something outside the RFC specs and 
with a lot of penalties (note that the RR param is not only used for the 
dialog matching but also for identifying what dialogs are monitored - 
you can have dialog state only for calls going to PSTN for example and 
you should not try process/match requests for the rest the calls)
    2) approach the UAC vendors to fix the bug in their firmware. The 
result is something full RFC compliant and with no penalties.

As I see, in both cases it is about approaching somebody for doing a 
fix, but the outcome is different :)....

regards,
bogdan

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