10 May
2007
10 May
'07
9:09 a.m.
Thank you Michal,
I have migrated to SER-2.0 and have compiled with HONOR_MADDR, but
having some problem making it work. I cannot get the digest
authentication working. I am using the following code for REGISTER,
if (method=="REGISTER") {
if(!www_authorize("","credentials")){
www_challenge("","0");
break;
};
};
For some reason, www_challenge is not recognised. And gives parse
error. Can anyone please tell me how can I get the digest
authentication working??
kumar
On 5/7/07, Michal Matyska <michal(a)iptel.org> wrote:
Hi,
commetns inline
On Po, 2007-05-07 at 10:04 +0545, KUMAR wrote:
Hi Michal,
Sorry for my late response. Here are the packets while the transport
UDP is used.
regards
kumar
On 5/4/07, Michal Matyska <michal(a)iptel.org> wrote:
> Hi Kumar,
>
> could you please attach also the capture (at the server is enough) of
> the UDP both way messages? There call flow is quite strange and not
> understandable.... (well not surprised that's M$ RTC :)
>
> Some comments for now:
> 1) it seems the CLIENT IS BROKEN and does not understand lr=on flag for
> loose routing - see how is the ACK generated !!! You can try change rr
> module parameter to put just lr into the record-route (this might
> explain your rr and rr_preset difference)
Taking back, the client code is not broken, it is obsoleted only ;-)
It uses strict router procedures (RFC2543), to create the Route header
and Request-URI in subsequent within-dialog requests, but SER's
loose_route function call should be able to escape form that (and it is,
the rewritten request uri shows that). If you want to check, you should
see "after_strict" message in your debug output.
> 2) M$ is used to misuse maddr, there is
compile time flag HONOR_MADDR
> which you should have set to route such requests taking maddr into
> account
This seems to be the main issue, the client does not put maddr into the
UDP requests. Check the Route header from the client in the TCP and UDP
captures to see the difference.
Recompile SER with the option HONOR_MADDR set and it should work. If
not, please provide SER output with debug=4 statement in you ser.cfg,
while running the TCP usecase.
Michal
> On Pá, 2007-05-04 at 09:52 +0545, KUMAR
wrote:
> > Here are the packet captures. I was not quite sure whether I have to
> > include packet captures from server or the UAs so i've included all of
> > them. ua_A is sending INVITE to ua_B.
> > thank you
> >
> > regards
> > kumar
> >
> > On 5/3/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
> > >
> > >
> > > Jiri Kuthan wrote:
> > > > actually I was suggesting SIP message dump (PCAP file) as opposed to
log files. -jiri
> > >
> > > or ngrep dump:
> > >
> > > ngrep -t -W byline -d any port 5060
> > >
> > > regards
> > > klaus
> > >
> > >
> > > >
> > > > At 13:10 03/05/2007, KUMAR wrote:
> > > >> Here is the message dump that i get when using TCP as transport.
> > > >>>
> > > >>> On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote:
> > > >>>> I think you would have to send message dumps first so
that [serusers] volunteers
> > > >>>> have material for providing an answer.
> > > >>>>
> > > >>>> -jiri
> > > >>>>
> > > >>>> At 12:07 03/05/2007, KUMAR wrote:
> > > >>>>> -
> > > >>>>> Hi all,
> > > >>>>> I already posted this message yet havent got any
replies. I really
> > > >>>>> need to find this out.
> > > >>>>> Please anyone reply to this problem.
> > > >>>>>
> > > >>>>> I am using SER-0.9.6 and the problem i'm having
is this. When using
> > > >>>>> the following ser.cfg, it works well when the
transport UDP is used.
> > > >>>>> But when transport TCP is used, then it only results
in one way IM,
> > > >>>>> only from the UA from which the INVITE is being sent.
Moreover, when
> > > >>>>> record_route is used instead of record_route_preset,
then even that
> > > >>>>> one way IM doesn't work. But it works well with
UDP.
> > > >>>>>
> > > >>>>> Can anyone please point me as to where the problem
might be??
> > > >>>>> Thank you in advance.
> > > >>>>>
> > > >>>>> kumar
> > > >>>>>
> > > >>>>>
> > > >>>>> Content-Type: application/octet-stream; name=ser.cfg
> > > >>>>> X-Attachment-Id: f_f18sg2bl
> > > >>>>> Content-Disposition: attachment;
filename="ser.cfg"
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Serusers mailing list
> > > >>>>> Serusers(a)lists.iptel.org
> > > >>>>> http://lists.iptel.org/mailman/listinfo/serusers
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Jiri Kuthan http://iptel.org/~jiri/
> > > >>>>
> > > >>>>
> > > >>
> > > >> Content-Type: audio/x-pn-realaudio-plugin;
name="msg_dump.rar"
> > > >> Content-Disposition: attachment;
filename="msg_dump.rar"
> > > >> X-Attachment-Id: f_f1949112
> > > >>
> > > >> _______________________________________________
> > > >> Serusers mailing list
> > > >> Serusers(a)lists.iptel.org
> > > >> http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > >
> > > >
> > > > --
> > > > Jiri Kuthan http://iptel.org/~jiri/
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > Serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > _______________________________________________
> > Serusers mailing list
> > Serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
>