[Users] dialog module configuration question

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Feb 23 14:54:59 CET 2007


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




More information about the Users mailing list