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