[Users] dialog module configuration question
Michel Bensoussan
michel at extricom.com
Mon Feb 26 10:49:39 CET 2007
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
>
> Michel Bensoussan wrote:
>> Hello
>> I also have a similar problem. The dialog module doesn't detect the
>> BYE message.
>> I'm using ver 1.1.1.
>> My configuration is as follow: 2 Wifi SIP phones (BCM) connected to
>> the same Access Point and the OpenSER runs on a PC.
>> Attached the debug log, ethereal sniffing on the *Wire* LAN and my
>> config file.
>> For both ACK and BYE message, the dialog module prints the error
>> DEBUG:dialog:dlg_onroute: Route param 'did' not found
>> Did you find a solution?
>>
>> If you want to check the attached files:
>> Caller: 192.168.13.166
>> Callee: 192.168.13.101
>> SIP Proxy: 192.168.13.86
>>
>> Regards,
>> Michel.
>>
>>
>> Bogdan-Andrei Iancu wrote:
>>> Hi Andy,
>>>
>>> in client config, you need to add "[routes]" for ACK and BYE
>>> messages (take a look at the cfg I sent you)
>>>
>>> regards,
>>> bogdan
>>>
>>> Andy Pyles wrote:
>>>> I Just re-read the docs on loose_route(). So please disregard this
>>>> question. ( only processed if Route: header is present. Which isn't
>>>> present because Record-route: header isn't being sent to caller )
>>>>
>>>> So, I'm still trying to figure out why record-route: header is not
>>>> being sent to caller.
>>>>
>>>>
>>>> On 2/22/07, Andy Pyles <andy.pyles at gmail.com> wrote:
>>>>> Hi Bogdan,
>>>>>
>>>>> After running additional debugs, for some reason the call to
>>>>> loose_route() is failing.
>>>>>
>>>>> if (loose_route()) {
>>>>> # mark routing logic in request
>>>>> xlog("L_INFO", "loose_route() succeeded\n ");
>>>>> route(1);
>>>>> } else{
>>>>> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu
>>>>> T=$tu IP=$si ID=$ci\n");
>>>>> };
>>>>>
>>>>>
>>>>> Any ideas why this could be occuring?
>>>>>
>>>>>
>>>>> On 2/22/07, Andy Pyles <andy.pyles at gmail.com> wrote:
>>>>> > HI Bogdan,
>>>>> >
>>>>> > I'm already using an almsot identical version of uas.xml and
>>>>> uac.xml (
>>>>> > yes rrs=true) is being used. However in your version the uas.xml
>>>>> > doesn't have rrs="true" after initial invite which I think is
>>>>> needed.
>>>>> > See as you can see below, setting rrs="true" for uac will only
>>>>> work if
>>>>> > it receives a Record-Route header in the 200OK which it's not.
>>>>> >
>>>>> > In this case, ALL messages from openser to sipp uac do not
>>>>> contain the
>>>>> > Record-route header. So I don't think it's a sipp problem, but an
>>>>> > openser configuration problem. I've tried using other devices
>>>>> for a
>>>>> > uac, such as x-lite but the same problem.
>>>>> >
>>>>> > Andy
>>>>> >
>>>>> > On 2/22/07, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>>>>> > > Hi Andy,
>>>>> > >
>>>>> > > so it's about sipp :D - I remember I had some hard times to
>>>>> make it work
>>>>> > > with record Route.
>>>>> > >
>>>>> > > take a look at the attached files, they might help you.
>>>>> > >
>>>>> > > regards,
>>>>> > > bogdan
>>>>> > >
>>>>> > > Andy Pyles wrote:
>>>>> > > > HI Bogdan,
>>>>> > > >
>>>>> > > > thanks for your reply.
>>>>> > > > yes you are correct. The Bye doesn't have the Route header.
>>>>> > > > It appears the the 200 OK sent to the caller doesn't contain a
>>>>> > > > Record-route header.
>>>>> > > > Messages between openser and callee contain record-route
>>>>> information,
>>>>> > > > but messages between caller and openser do not.
>>>>> > > > Is there a way to enable that?
>>>>> > > >
>>>>> > > > Here's more detail:
>>>>> > > > 192.168.0.101 = Caller (sipp)
>>>>> > > > 1.2.3.4 = openser
>>>>> > > > 4.3.2.1 = callee ( sipp)
>>>>> > > >
>>>>> > > >
>>>>> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
>>>>> > > > sip:service at 1.2.3.4:5060, with session description
>>>>> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
>>>>> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
>>>>> > > > sip:service at 4.3.2.1:5060, with session description
>>>>> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
>>>>> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK,
>>>>> with session
>>>>> > > > description
>>>>> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
>>>>> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK,
>>>>> with session
>>>>> > > > description
>>>>> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
>>>>> > > > sip:service at 1.2.3.4:5060
>>>>> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
>>>>> sip:service at 4.3.2.1:5060
>>>>> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
>>>>> > > > sip:service at 1.2.3.4:5060
>>>>> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
>>>>> sip:service at 4.3.2.1:5060
>>>>> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
>>>>> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
>>>>> > > >
>>>>> > > > ---
>>>>> > > > Packets 6,7 and following contain no Record-route information.
>>>>> > > > The other weird thing is that openser is passing on the
>>>>> Route: header
>>>>> > > > it recevied from callee to the caller.
>>>>> > > >
>>>>> > > >
>>>>> > > > Please see attached for complete ngrep output.
>>>>> > > >
>>>>> > > >
>>>>> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>>>>> > > >> Hi Andy,
>>>>> > > >>
>>>>> > > >> could you check on the net if the BYE contain the Route hdr
>>>>> added to
>>>>> > > >> INVITE as Record-Route? I have some doubts on this as I see:
>>>>> > > >> 0(966) find_first_route: No Route headers found
>>>>> > > >> 0(966) loose_route: There is no Route HF
>>>>> > > >>
>>>>> > > >> and if the BYE is not identified, the dialog is not closed.
>>>>> > > >>
>>>>> > > >> regards,
>>>>> > > >> bogdan
>>>>> > > >>
>>>>> > > >> Andy Pyles wrote:
>>>>> > > >> > Hello,
>>>>> > > >> >
>>>>> > > >> > I have a question on how to configure the dialog module
>>>>> ( 1.2.x from
>>>>> > > >> > cvs yesterday ).
>>>>> > > >> >
>>>>> > > >> > With my config, ( attached) I can make calls and have
>>>>> verified that
>>>>> > > >> > the acc module is working correctly.
>>>>> > > >> >
>>>>> > > >> > My question is, when I enable the dialog module, I can
>>>>> see that it is
>>>>> > > >> > incrementing call count correctly, but when a bye is
>>>>> received, the
>>>>> > > >> > dialog:active_dialogs statistic is never decremented.
>>>>> > > >> >
>>>>> > > >> > In the debug level 9 logs, ( also attached) I see this
>>>>> error after the
>>>>> > > >> > 200OK is sent to the bye:
>>>>> > > >> >
>>>>> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
>>>>> > > >> (delete=0)-> 1
>>>>> > > >> >
>>>>> > > >> > Is this a case of one of the timers being set too short?
>>>>> by the way
>>>>> > > >> > using a variable call length from well under a second (
>>>>> using sipp )
>>>>> > > >> > to 20 second call doesnt' seem to make a difference .
>>>>> > > >> >
>>>>> > > >> >
>>>>> > > >> > Thanks,
>>>>> > > >> > Andy
>>>>> > > >> >
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>
>
>
More information about the Users
mailing list