[serusers]: trusted table(permissions module)

Michal Matyska michal at iptel.org
Mon Nov 6 16:41:39 CET 2006 

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

More information about the sr-users mailing list