[serusers]: trusted table(permissions module)
Andrey Kuprianov
andrey.kouprianov at gmail.com
Tue Nov 7 07:27:28 CET 2006
Hi,
You can have a special processing for your service... Say, whenever
you get request from uri WakeupService, dont lookup the table.
Andrey.
On 11/6/06, Michal Matyska <michal at iptel.org> wrote:
> Well you have to find what is the path the request follows. There is
> tool on the CVS which shows all possible paths of your route blocks...
>
> Or take if from the other side, all places you have sl_reply(404,"user
> not found") (or t_reply) change the text so it will be unique and you
> can see which part returned that status.
>
> One more hint, your request is INVITE sip:10.25.119.155:5060 and this
> does NOT represent any single user, i'm sure, so you won't find it in
> user location.
>
> If you would like to use the To header, I'd suggest to switch to the
> current CVS HEAD version, which has a lot of functions and features you
> might like to use (e.g. lookup_user based on the to uri :-).
>
> Michal
>
>
> On Mon, 2006-11-06 at 15:09 +0100, Kamal.Mann at t-systems.com wrote:
> > Hi Michal
> > After changes in ser.cfg(entered ip of SER in domain table) now its
> > sending 404-user not found. One more thing WakeUpService URI is not
> > provisioned in ser database cause its application URI. Do we need to put
> > it into subscriber table??
> >
> > Regards
> > Kamal Mann
> >
> > -----Original Message-----
> > From: serusers-bounces at lists.iptel.org
> > [mailto:serusers-bounces at lists.iptel.org] On Behalf Of Michal Matyska
> > Sent: Monday, November 06, 2006 3:43 PM
> > To: Mann, Kamal
> > Cc: serusers at lists.iptel.org
> > Subject: RE: [serusers]: trusted table(permissions module)
> >
> > So if this is still current part of your ser.cfg, I might see the
> > reason....
> >
> > The is_uri_host_local uses domain table to decide what is local and what
> > not; opposed to test uri==myself which treats local IP add reverse name
> > and alias=xxx statement to decide what is local.
> >
> > So I think, the test just after lookup("aliases") fails and then
> > route[4] (NAT) and route[1] (relay to RURI) are called.....
> >
> > You can easily check adding some log("xxx") into the code.
> >
> >
> > To cure that, you should either switch the test to uri!=myself or add IP
> > address of the ser server into domain table (but still there are few
> > tests uri==myslf elsewhere in the ser.cfg).
> >
> > Michal
> >
> >
> > route[3]
> > {
> > # ----------------------------------------------------------
> > # INVITE Message Handler
> > # ----------------------------------------------------------
> >
> > if (!allow_trusted())
> > {
> > ...
> > };
> >
> > if (uri=~"^sip:1[0-9]{10}@")
> > {
> > strip(1);
> > };
> > lookup("aliases");
> > if (!is_uri_host_local()) # <<< change to uri!=myself
> > {
> > log("AS - prove of idead "); # <<< add to prove idea
> > route(4);
> > route(1);
> > break;
> > };
> >
> > ....
> >
> > }
> >
> > Michal
> >
> > On Mon, 2006-11-06 at 10:43 +0100, Kamal.Mann at t-systems.com wrote:
> > > Hi All
> > > Please find n/w packet capture enclosed. You are right Michal, SER
> > > forwarding packets to itself. Now what I need to do? Please help me
> > out
> > > guys.
> > >
> > > Thanks in anticipation
> > > Kamal Mann
> > >
> > > -----Original Message-----
> > > From: Michal Matyska [mailto:michal at iptel.org]
> > > Sent: Monday, November 06, 2006 2:39 PM
> > > To: serusers at lists.iptel.org
> > > Subject: Re: [serusers]: trusted table(permissions module)
> > >
> > > Plase do capture on the SER server on linux cooked interface called
> > > "any", I suspect that your ser is forwarding the request to itself and
> > > at the moment it won't catch using the trusted table.
> > >
> > > More comments inline.
> > >
> > > On Mon, 2006-11-06 at 14:47 +0700, Andrey Kuprianov wrote:
> > > > Hi,
> > > >
> > > > See inline
> > > >
> > > > On 11/6/06, Kamal.Mann at t-systems.com <Kamal.Mann at t-systems.com>
> > wrote:
> > > > > Hi Andrey
> > > > > On SIP AS side sip stack is running on port 5060, then this packet
> > > send
> > > > > to Application running over on top of it. Is their any issue with
> > > this
> > > > > scenario?
> > > >
> > > > I think there might be... I just think there should be some
> > > > consistency between your SIP and UDP/TCP packets. If UDP source port
> > > > is 4141, for example, then your Contact header (and From header
> > too),
> > > > should have this port. If someone else has some good ideas, plz,
> > > > comment.
> > >
> > > What Andrey describes is symetric signalling, what we see in the
> > capture
> > > is asymetric signalling.... it is not the problem. It is possible (not
> > > when you are behind NAT) to use 5060 for receiving incoming requests
> > and
> > > responses and use other ports to send requests.
> > >
> > >
> > > > > In SIP packet its 5060 only. Port is changed only in UDP/TCP
> > > packets.
> > > > > But I think their shouldn't be anything wrong with this cause SIP
> > > Stack
> > > > > utilizes only sip packets (inside of UDP). And SER is replying to
> > > it.
> > > > >
> > > >
> > > > Your ethereal traces on SER side show 100 and 407 responses are
> > marked
> > > > as black and red color (i use ethereal 0.99.x). That means something
> > > > is wrong.
> > >
> > > Due to UDP checksum not beeing correct.
> > >
> > > Michal
> > >
> > > >
> > > > > Regards
> > > > > Kamal Mann
> > > > >
> > > >
> > > > Regards,
> > > >
> > > > Andrey.
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrey Kuprianov [mailto:andrey.kouprianov at gmail.com]
> > > > > Sent: Monday, November 06, 2006 11:52 AM
> > > > > To: serusers at iptel.org
> > > > > Subject: Re: [serusers]: trusted table(permissions module)
> > > > >
> > > > > Hi Kamal,
> > > > >
> > > > > I noticed one strange thing in your traces. INVITE from SIP-AS is
> > > sent
> > > > > from port 4141 (!) to port 5060, but 100 and 407 response from SER
> > > is
> > > > > sent back to port 5060 (not port 4141)! Can you, please, explain
> > > why?
> > > > >
> > > > > Andrey.
> > > > >
> > > > > On 11/6/06, Kamal.Mann at t-systems.com <Kamal.Mann at t-systems.com>
> > > wrote:
> > > > > > Hi Andrey
> > > > > > Please find ethereal packet capture enclosed. SER n/w dump is
> > > > > 'SER_SERVER' and SIP_AS n/w dump is 'SAS_SERVER'.
> > > > > > SER IP = 10.25.119.155
> > > > > > SIP AS IP = 10.25.119.156
> > > > > > To URI is registered at SER end (dilip)
> > > > > > From URI is Application Name (example) and neither created nor
> > > > > registered (WakeUpService) with SER.
> > > > > >
> > > > > > Thanks in anticipation
> > > > > > Kamal Mann
> > > > > _______________________________________________
> > > > > Serusers mailing list
> > > > > Serusers at lists.iptel.org
> > > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > Serusers at lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > Serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
More information about the sr-users
mailing list