[Users] dialog module configuration question

Andy Pyles andy.pyles at gmail.com
Mon Feb 26 02:04:56 CET 2007


Hi Bogdan,

One more question,

any thoughts how the dialog module could be enhanced to handle broken
UA's that don't send the correct Route, Record-Route headers in a bye?

Andy

On 2/25/07, Andy Pyles <andy.pyles at gmail.com> wrote:
> HI Bogdan,
>
> thanks. Thats what did it. Turns out it was a  sipp config problem after all.
> Incidentally the UA's that worked for me was a sipura and x-lite.
>
> Thanks,
> Andy
>
> On 2/25/07, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> > Hi Andy,
> >
> > yes, you are correct - the package 7 (the 200 OK) must mirror the
> > Record-Route set from the request. For this you need to enable the rrs
> > param :
> >
> >   <recv request="INVITE" crlf="true" rrs="true">
> >   </recv>
> >
> > regards,
> > bogdan
> >
> > Andy Pyles wrote:
> > > Hi Bogdan,
> > >
> > > ok let me go back to my example:
> > >
> > > Here's more detail:
> > > 192.168.0.101 = Caller (sipp uas)
> > > 1.2.3.4 = openser
> > > 4.3.2.1 = callee ( sipp uac)
> > >
> > >
> > > 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
> > >
> > > So, you are saying for Packets 8, 10 I should add the '[routes]' logic
> > > to sipp. How this works is: from the sipp documentation: "rrs: Record
> > > Route Set. if this attribute is set to "true", then the
> > > "Record-Route:" header of the message received is stored and can be
> > > recalled using the [routes] keyword.".
> > >
> > > This I completey agree with. sipp Must be sending the Route: header
> > > in Packets 8 and 10. However, packet  7 MUST have the Record-route
> > > header, otherwise, How can sipp can put the correct value into the
> > > Route: header. See my point?
> > >
> > > Reference: rfc 3665 ( secion 3.2 Packet f11, f14)
> > >
> > > regards,
> > > Andy
> > >
> > >
> > > On 2/23/07, Andy Pyles <andy.pyles at gmail.com> wrote:
> > >> 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 <bogdan at voice-system.ro> 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
> > >> > >> > > >> >
> > >> >
> > >>
> > >
> >
> >
>




More information about the sr-users mailing list