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@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@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@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@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@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@1.2.3.4:5060 > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
sip:service@4.3.2.1:5060
> > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE > > sip:service@1.2.3.4:5060 > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
sip:service@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users