Hi Bogdan,
correct. but on client config "[routes]" ( for sipp) will only work
IF the client receives a Record-route. Since I'm not, it doesn't help
me. Am I missing something?
Andy
On 2/23/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060
> >> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
> >> sip:[EMAIL PROTECTED]:5060
> >> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
> >> > > > sip:[EMAIL PROTECTED]:5060
> >> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
> >> sip:[EMAIL PROTECTED]: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 <[EMAIL PROTECTED]>
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
> >> > > >> >
>
