4 Nov
2006
4 Nov
'06
10:18 a.m.
Hi All
In current scenario when a sip invite message comes to SER from my SIP_AS; SER take this
massage trusted (as I defined in trusted table) but after this in my INVITE route(3) it
sends it to route(1) default message handler. I am enclosing my ser.cfg; please take a
glance on it.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: John Shellhouse [mailto:jwshel@hotmail.com]
Sent: Friday, November 03, 2006 9:17 PM
To: Mann, Kamal
Subject: RE: [serusers]: trusted table(permissions module)
Hi,
you've already tried something more filled in like this...
if (!proxy_authorize("somedomain.com","subscriber")) {
proxy_challenge("somedomain.com","0");
break;
} else if (method == "INVITE" & !check_from()) {
log("from!=digest\n");
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
T
From: <Kamal.Mann(a)t-systems.com>
To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
Subject: RE: [serusers]: trusted table(permissions module)
Date: Fri, 3 Nov 2006 15:40:26 +0100
Hi All
Now SER is trusting packates from trusted table IP and in the following
part of route(3) of Invite message handler allow_trusted results 'true' and
it directly bypasses this code.
if (!allow_trusted())
{
if (!proxy_authorize("","subscriber"))
{
proxy_challenge("","0");
break;
}
else if (!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
But after in route(1) its sending 407-proxy auth required to trusted ip of
sip_AS. Please help me out of this dilemma.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Thursday, November 02, 2006 1:13 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
The one you attached, didnt have a semicolon. Anyway, try using a
fresh copy of a ready made ser.cfg.
Bests,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
Yup I always do the same, Might be copy paste
error. Its having
semicolon & working fine here.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Thursday, November 02, 2006 10:34 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Whenever you modified your ser.cfg did you restart SER after? Did you
check your ser.cfg for errors using "ser -c" command? I found some
errors in your ser.cfg code. For instance, inside the main route
block, your "if", which processes INVITEs, is missing a semicolon at
the end of the block.
if (method=="INVITE")
{
# sl_send_reply("404", "INVITE ");
route(3);
break;
} <----- missing semicolon here
If you are comfortable with your current ser.cfg, that's ok, but I'd
suggest you start with a fresh one, make your trusted table work, and
then add a "REFER" processing, like in your currect ser.cfg. Just
download one fresh ser.cfg from iptel.org site and add your
allow_trusted() "if" clause there.
Regards,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi
> Please find ser.cfg enclosed.
>
> Trusted table entry:
> +---------------+-------+--------------+
> | src_ip | proto | from_pattern |
> +---------------+-------+--------------+
> | 10.25.119.156 | any | ^sip:.*$ |
> +---------------+-------+--------------+
> 1 row in set (0.00 sec)
>
> Thanks in anticipation
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Wednesday, November 01, 2006 7:03 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I understand your setup. Nevertheless, it will be difficult to figure
> out your problem, w/o your ser.cfg file at hand. Also, send a trusted
> table query result (i.e. that row which contains entry for your
> SIP-AS).
>
> Regards,
>
> Andrey.
>
> On 11/1/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In my scenario I need ser to communicate with my SIP-AS. This SIP-AS
is
having an application xyz running on it. This XYZ sends an invite to URI
"A(a)xcv.de" which is a subscriber in SER and this is in TO header of Invite
msg & FROM header contains another URI test(a)xcv.de but this URI
(test(a)xcv.de) isn't registered / subscribed to SER. I need SER trust all
packets from SIP-AS ip. BUT SER is sending 407 reply of INVITE to XYZ
application! IP in trusted table is of SIP-AS on top of which XYZ
application is running.
> >
> > Thanks in anticipation
> > Kamal Mann
> >
> > -----Original Message-----
> > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > Sent: Wednesday, November 01, 2006 3:20 PM
> > To: serusers(a)lists.iptel.org
> > Subject: Re: [serusers]: trusted table(permissions module)
> >
> > Kamal.Mann(a)t-systems.com wrote:
> >
> > > Hi All
> > >
> > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into trusted
table so
> > > that any packet sent from
10.25.119.156 would be trusted by SER
and
> > > don't ask for its credentials.
But SER is replying *407- proxy*
auth
> > > needed!! After this I tried with
permissions.allow file:
> > >
> > Hi,
> > I had the same issue while interconnecting SER and Asterisk. It
turned
> > out to be an issue on Asterisk side (I
had the same user added for
SER
> > and Asterisk, so the poor thing
couldn't authorize either :)) So you
> > could check if the 407 you're getting is from SER or from the remote
host.
> >
> > Regards,
> > Maciej Zwirski
> >
> >
----------------------------------------------------------------------
Jestes kierowca? To poczytaj! >>>
http://link.interia.pl/f199e
_______________________________________________
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
4 Nov
4 Nov
3:49 p.m.
New subject: [serusers]: trusted table(permissions module)
Hi Kamal,
Really, there are only 2 places in your ser.cfg, where proxy_authorize
is called. One is inside route[3] block, and one, which is commented
out is inside the main route block. Since, one proxy_authorize is
commented out, this leaves the only a single proxy_authorize - the one
inside route[3] block. Now... In your previous mail you said,
"allow_trusted results 'true' and it directly bypasses this code."
This means only one thing - there are *no more* proxy_authorize left
to call...
You also said "But after in route(1) its sending 407-proxy auth
required to trusted ip of sip_AS". That is impossible. Your route[1]
block cannot and does not send 407 response. There's simply no
proxy_authorize code in there and SER does not do it automatically!
I have several ideas (some of them were already presented in previous mails):
1. Something else (not SER) is sending 407 response. Catch network
traffic (i.e. traces) and send them here to the list. Do it on both
sides, SER and SIP-AS. This is critical.
2. Your SER is using some other configuration file (it's my best guess
now), not the one that you've sent. Please, check thoroughly on this
issue.
3. Do a fresh start with your configuration file. You will lose 1
(maximum 2) hours, but at least it's gonna work.
I really wish you best of luck on this one, man!
Andrey.
On 11/4/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
Hi All
In current scenario when a sip invite message comes to SER from my SIP_AS; SER take this
massage trusted (as I defined in trusted table) but after this in my INVITE route(3) it
sends it to route(1) default message handler. I am enclosing my ser.cfg; please take a
glance on it.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: John Shellhouse [mailto:jwshel@hotmail.com]
Sent: Friday, November 03, 2006 9:17 PM
To: Mann, Kamal
Subject: RE: [serusers]: trusted table(permissions module)
Hi,
you've already tried something more filled in like this...
if (!proxy_authorize("somedomain.com","subscriber")) {
proxy_challenge("somedomain.com","0");
break;
} else if (method == "INVITE" & !check_from()) {
log("from!=digest\n");
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
T
From: <Kamal.Mann(a)t-systems.com>
To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
Subject: RE: [serusers]: trusted table(permissions module)
Date: Fri, 3 Nov 2006 15:40:26 +0100
Hi All
Now SER is trusting packates from trusted table IP and in the following
part of route(3) of Invite message handler allow_trusted results 'true' and
it directly bypasses this code.
if (!allow_trusted())
{
if (!proxy_authorize("","subscriber"))
{
proxy_challenge("","0");
break;
}
else if (!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
But after in route(1) its sending 407-proxy auth required to trusted ip of
sip_AS. Please help me out of this dilemma.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Thursday, November 02, 2006 1:13 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
The one you attached, didnt have a semicolon. Anyway, try using a
fresh copy of a ready made ser.cfg.
Bests,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Yup I always do the same, Might be copy paste
error. Its having
semicolon & working fine here.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Thursday, November 02, 2006 10:34 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Whenever you modified your ser.cfg did you restart SER after? Did you
check your ser.cfg for errors using "ser -c" command? I found some
errors in your ser.cfg code. For instance, inside the main route
block, your "if", which processes INVITEs, is missing a semicolon at
the end of the block.
if (method=="INVITE")
{
# sl_send_reply("404", "INVITE ");
route(3);
break;
} <----- missing semicolon here
If you are comfortable with your current ser.cfg, that's ok, but I'd
suggest you start with a fresh one, make your trusted table work, and
then add a "REFER" processing, like in your currect ser.cfg. Just
download one fresh ser.cfg from iptel.org site and add your
allow_trusted() "if" clause there.
Regards,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi
> Please find ser.cfg enclosed.
>
> Trusted table entry:
> +---------------+-------+--------------+
> | src_ip | proto | from_pattern |
> +---------------+-------+--------------+
> | 10.25.119.156 | any | ^sip:.*$ |
> +---------------+-------+--------------+
> 1 row in set (0.00 sec)
>
> Thanks in anticipation
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Wednesday, November 01, 2006 7:03 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I understand your setup. Nevertheless, it will be difficult to figure
> out your problem, w/o your ser.cfg file at hand. Also, send a trusted
> table query result (i.e. that row which contains entry for your
> SIP-AS).
>
> Regards,
>
> Andrey.
>
> On 11/1/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In my scenario I need ser to communicate with my SIP-AS. This SIP-AS
is
having an application xyz running on it. This XYZ sends an invite to URI
"A(a)xcv.de" which is a subscriber in SER and this is in TO header of Invite
msg & FROM header contains another URI test(a)xcv.de but this URI
(test(a)xcv.de) isn't registered / subscribed to SER. I need SER trust all
packets from SIP-AS ip. BUT SER is sending 407 reply of INVITE to XYZ
application! IP in trusted table is of SIP-AS on top of which XYZ
application is running.
> >
> > Thanks in anticipation
> > Kamal Mann
> >
> > -----Original Message-----
> > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > Sent: Wednesday, November 01, 2006 3:20 PM
> > To: serusers(a)lists.iptel.org
> > Subject: Re: [serusers]: trusted table(permissions module)
> >
> > Kamal.Mann(a)t-systems.com wrote:
> >
> > > Hi All
> > >
> > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into trusted
table so
> > > that any packet sent from
10.25.119.156 would be trusted by SER
and
> > > don't ask for its credentials.
But SER is replying *407- proxy*
auth
> > > needed!! After this I tried with
permissions.allow file:
> > >
> > Hi,
> > I had the same issue while interconnecting SER and Asterisk. It
turned
> > out to be an issue on Asterisk side (I
had the same user added for
SER
> > and Asterisk, so the poor thing
couldn't authorize either :)) So you
> > could check if the 407 you're getting is from SER or from the remote
host.
> >
> > Regards,
> > Maciej Zwirski
> >
> >
----------------------------------------------------------------------
>
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
>
> _______________________________________________
> 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
>
6 Nov
6 Nov
8:30 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi Andrey,
Yes you are right it not bypassing that part of code (route [3]).But why it is so? Its not
trusting SIP AS IP! I had recompiled permissions module but still the same response!!
Regards
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf
Of Andrey Kuprianov
Sent: Saturday, November 04, 2006 6:20 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Really, there are only 2 places in your ser.cfg, where proxy_authorize
is called. One is inside route[3] block, and one, which is commented
out is inside the main route block. Since, one proxy_authorize is
commented out, this leaves the only a single proxy_authorize - the one
inside route[3] block. Now... In your previous mail you said,
"allow_trusted results 'true' and it directly bypasses this code."
This means only one thing - there are *no more* proxy_authorize left
to call...
You also said "But after in route(1) its sending 407-proxy auth
required to trusted ip of sip_AS". That is impossible. Your route[1]
block cannot and does not send 407 response. There's simply no
proxy_authorize code in there and SER does not do it automatically!
I have several ideas (some of them were already presented in previous mails):
1. Something else (not SER) is sending 407 response. Catch network
traffic (i.e. traces) and send them here to the list. Do it on both
sides, SER and SIP-AS. This is critical.
2. Your SER is using some other configuration file (it's my best guess
now), not the one that you've sent. Please, check thoroughly on this
issue.
3. Do a fresh start with your configuration file. You will lose 1
(maximum 2) hours, but at least it's gonna work.
I really wish you best of luck on this one, man!
Andrey.
On 11/4/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
Hi All
In current scenario when a sip invite message comes to SER from my SIP_AS; SER take this
massage trusted (as I defined in trusted table) but after this in my INVITE route(3) it
sends it to route(1) default message handler. I am enclosing my ser.cfg; please take a
glance on it.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: John Shellhouse [mailto:jwshel@hotmail.com]
Sent: Friday, November 03, 2006 9:17 PM
To: Mann, Kamal
Subject: RE: [serusers]: trusted table(permissions module)
Hi,
you've already tried something more filled in like this...
if (!proxy_authorize("somedomain.com","subscriber")) {
proxy_challenge("somedomain.com","0");
break;
} else if (method == "INVITE" & !check_from()) {
log("from!=digest\n");
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
T
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
From: <Kamal.Mann(a)t-systems.com>
To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
Subject: RE: [serusers]: trusted table(permissions module)
Date: Fri, 3 Nov 2006 15:40:26 +0100
Hi All
Now SER is trusting packates from trusted table IP and in the following
part of route(3) of Invite message handler allow_trusted results 'true' and
it directly bypasses this code.
if (!allow_trusted())
{
if (!proxy_authorize("","subscriber"))
{
proxy_challenge("","0");
break;
}
else if (!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
But after in route(1) its sending 407-proxy auth required to trusted ip of
sip_AS. Please help me out of this dilemma.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Thursday, November 02, 2006 1:13 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
The one you attached, didnt have a semicolon. Anyway, try using a
fresh copy of a ready made ser.cfg.
Bests,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Yup I always do the same, Might be copy paste
error. Its having
semicolon & working fine here.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Thursday, November 02, 2006 10:34 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Whenever you modified your ser.cfg did you restart SER after? Did you
check your ser.cfg for errors using "ser -c" command? I found some
errors in your ser.cfg code. For instance, inside the main route
block, your "if", which processes INVITEs, is missing a semicolon at
the end of the block.
if (method=="INVITE")
{
# sl_send_reply("404", "INVITE ");
route(3);
break;
} <----- missing semicolon here
If you are comfortable with your current ser.cfg, that's ok, but I'd
suggest you start with a fresh one, make your trusted table work, and
then add a "REFER" processing, like in your currect ser.cfg. Just
download one fresh ser.cfg from iptel.org site and add your
allow_trusted() "if" clause there.
Regards,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi
> Please find ser.cfg enclosed.
>
> Trusted table entry:
> +---------------+-------+--------------+
> | src_ip | proto | from_pattern |
> +---------------+-------+--------------+
> | 10.25.119.156 | any | ^sip:.*$ |
> +---------------+-------+--------------+
> 1 row in set (0.00 sec)
>
> Thanks in anticipation
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Wednesday, November 01, 2006 7:03 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I understand your setup. Nevertheless, it will be difficult to figure
> out your problem, w/o your ser.cfg file at hand. Also, send a trusted
> table query result (i.e. that row which contains entry for your
> SIP-AS).
>
> Regards,
>
> Andrey.
>
> On 11/1/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In my scenario I need ser to communicate with my SIP-AS. This SIP-AS
is
having an application xyz running on it. This XYZ sends an invite to URI
"A(a)xcv.de" which is a subscriber in SER and this is in TO header of Invite
msg & FROM header contains another URI test(a)xcv.de but this URI
(test(a)xcv.de) isn't registered / subscribed to SER. I need SER trust all
packets from SIP-AS ip. BUT SER is sending 407 reply of INVITE to XYZ
application! IP in trusted table is of SIP-AS on top of which XYZ
application is running.
> >
> > Thanks in anticipation
> > Kamal Mann
> >
> > -----Original Message-----
> > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > Sent: Wednesday, November 01, 2006 3:20 PM
> > To: serusers(a)lists.iptel.org
> > Subject: Re: [serusers]: trusted table(permissions module)
> >
> > Kamal.Mann(a)t-systems.com wrote:
> >
> > > Hi All
> > >
> > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into trusted
table so
> > > that any packet sent from
10.25.119.156 would be trusted by SER
and
> > > don't ask for its credentials.
But SER is replying *407- proxy*
auth
> > > needed!! After this I tried with
permissions.allow file:
> > >
> > Hi,
> > I had the same issue while interconnecting SER and Asterisk. It
turned
> > out to be an issue on Asterisk side (I
had the same user added for
SER
> > and Asterisk, so the poor thing
couldn't authorize either :)) So you
> > could check if the 407 you're getting is from SER or from the remote
host.
> >
> > Regards,
> > Maciej Zwirski
> >
> >
----------------------------------------------------------------------
>
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
>
> _______________________________________________
> 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
>
8:33 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi Kamal,
Please (!), do network dump and send it here. Use tcpdump, ngrep,
Ethereal, anything to catch your network traffic on port 5060.
Waiting for your traces,
Andrey.
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
Hi Andrey,
Yes you are right it not bypassing that part of code (route [3]).But why it is so? Its
not trusting SIP AS IP! I had recompiled permissions module but still the same response!!
Regards
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Andrey Kuprianov
Sent: Saturday, November 04, 2006 6:20 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Really, there are only 2 places in your ser.cfg, where proxy_authorize
is called. One is inside route[3] block, and one, which is commented
out is inside the main route block. Since, one proxy_authorize is
commented out, this leaves the only a single proxy_authorize - the one
inside route[3] block. Now... In your previous mail you said,
"allow_trusted results 'true' and it directly bypasses this code."
This means only one thing - there are *no more* proxy_authorize left
to call...
You also said "But after in route(1) its sending 407-proxy auth
required to trusted ip of sip_AS". That is impossible. Your route[1]
block cannot and does not send 407 response. There's simply no
proxy_authorize code in there and SER does not do it automatically!
I have several ideas (some of them were already presented in previous mails):
1. Something else (not SER) is sending 407 response. Catch network
traffic (i.e. traces) and send them here to the list. Do it on both
sides, SER and SIP-AS. This is critical.
2. Your SER is using some other configuration file (it's my best guess
now), not the one that you've sent. Please, check thoroughly on this
issue.
3. Do a fresh start with your configuration file. You will lose 1
(maximum 2) hours, but at least it's gonna work.
I really wish you best of luck on this one, man!
Andrey.
On 11/4/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
Hi All
In current scenario when a sip invite message comes to SER from my SIP_AS; SER take this
massage trusted (as I defined in trusted table) but after this in my INVITE route(3) it
sends it to route(1) default message handler. I am enclosing my ser.cfg; please take a
glance on it.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: John Shellhouse [mailto:jwshel@hotmail.com]
Sent: Friday, November 03, 2006 9:17 PM
To: Mann, Kamal
Subject: RE: [serusers]: trusted table(permissions module)
Hi,
you've already tried something more filled in like this...
if (!proxy_authorize("somedomain.com","subscriber")) {
proxy_challenge("somedomain.com","0");
break;
} else if (method == "INVITE" & !check_from()) {
log("from!=digest\n");
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
T
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
From: <Kamal.Mann(a)t-systems.com>
To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
Subject: RE: [serusers]: trusted table(permissions module)
Date: Fri, 3 Nov 2006 15:40:26 +0100
Hi All
Now SER is trusting packates from trusted table IP and in the following
part of route(3) of Invite message handler allow_trusted results 'true' and
it directly bypasses this code.
if (!allow_trusted())
{
if (!proxy_authorize("","subscriber"))
{
proxy_challenge("","0");
break;
}
else if (!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
But after in route(1) its sending 407-proxy auth required to trusted ip of
sip_AS. Please help me out of this dilemma.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Thursday, November 02, 2006 1:13 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
The one you attached, didnt have a semicolon. Anyway, try using a
fresh copy of a ready made ser.cfg.
Bests,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Yup I always do the same, Might be copy paste
error. Its having
semicolon & working fine here.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Thursday, November 02, 2006 10:34 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Whenever you modified your ser.cfg did you restart SER after? Did you
check your ser.cfg for errors using "ser -c" command? I found some
errors in your ser.cfg code. For instance, inside the main route
block, your "if", which processes INVITEs, is missing a semicolon at
the end of the block.
if (method=="INVITE")
{
# sl_send_reply("404", "INVITE ");
route(3);
break;
} <----- missing semicolon here
If you are comfortable with your current ser.cfg, that's ok, but I'd
suggest you start with a fresh one, make your trusted table work, and
then add a "REFER" processing, like in your currect ser.cfg. Just
download one fresh ser.cfg from iptel.org site and add your
allow_trusted() "if" clause there.
Regards,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi
> Please find ser.cfg enclosed.
>
> Trusted table entry:
> +---------------+-------+--------------+
> | src_ip | proto | from_pattern |
> +---------------+-------+--------------+
> | 10.25.119.156 | any | ^sip:.*$ |
> +---------------+-------+--------------+
> 1 row in set (0.00 sec)
>
> Thanks in anticipation
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Wednesday, November 01, 2006 7:03 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I understand your setup. Nevertheless, it will be difficult to figure
> out your problem, w/o your ser.cfg file at hand. Also, send a trusted
> table query result (i.e. that row which contains entry for your
> SIP-AS).
>
> Regards,
>
> Andrey.
>
> On 11/1/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In my scenario I need ser to communicate with my SIP-AS. This SIP-AS
is
having an application xyz running on it. This XYZ sends an invite to URI
"A(a)xcv.de" which is a subscriber in SER and this is in TO header of Invite
msg & FROM header contains another URI test(a)xcv.de but this URI
(test(a)xcv.de) isn't registered / subscribed to SER. I need SER trust all
packets from SIP-AS ip. BUT SER is sending 407 reply of INVITE to XYZ
application! IP in trusted table is of SIP-AS on top of which XYZ
application is running.
> >
> > Thanks in anticipation
> > Kamal Mann
> >
> > -----Original Message-----
> > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > Sent: Wednesday, November 01, 2006 3:20 PM
> > To: serusers(a)lists.iptel.org
> > Subject: Re: [serusers]: trusted table(permissions module)
> >
> > Kamal.Mann(a)t-systems.com wrote:
> >
> > > Hi All
> > >
> > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into trusted
table so
> > > that any packet sent from
10.25.119.156 would be trusted by SER
and
> > > don't ask for its credentials.
But SER is replying *407- proxy*
auth
> > > needed!! After this I tried with
permissions.allow file:
> > >
> > Hi,
> > I had the same issue while interconnecting SER and Asterisk. It
turned
> > out to be an issue on Asterisk side (I
had the same user added for
SER
> > and Asterisk, so the poor thing
couldn't authorize either :)) So you
> > could check if the 407 you're getting is from SER or from the remote
host.
> >
> > Regards,
> > Maciej Zwirski
> >
> >
----------------------------------------------------------------------
> > Jestes kierowca? To poczytaj!
>>> http://link.interia.pl/f199e
> >
> > _______________________________________________
> > 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
> >
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:46 a.m.
New subject: [serusers]: trusted table(permissions module)
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
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf
Of Andrey Kuprianov
Sent: Monday, November 06, 2006 11:04 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Please (!), do network dump and send it here. Use tcpdump, ngrep,
Ethereal, anything to catch your network traffic on port 5060.
Waiting for your traces,
Andrey.
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
Hi Andrey,
Yes you are right it not bypassing that part of code (route [3]).But why it is so? Its
not trusting SIP AS IP! I had recompiled permissions module but still the same response!!
Regards
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Andrey Kuprianov
Sent: Saturday, November 04, 2006 6:20 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Really, there are only 2 places in your ser.cfg, where proxy_authorize
is called. One is inside route[3] block, and one, which is commented
out is inside the main route block. Since, one proxy_authorize is
commented out, this leaves the only a single proxy_authorize - the one
inside route[3] block. Now... In your previous mail you said,
"allow_trusted results 'true' and it directly bypasses this code."
This means only one thing - there are *no more* proxy_authorize left
to call...
You also said "But after in route(1) its sending 407-proxy auth
required to trusted ip of sip_AS". That is impossible. Your route[1]
block cannot and does not send 407 response. There's simply no
proxy_authorize code in there and SER does not do it automatically!
I have several ideas (some of them were already presented in previous mails):
1. Something else (not SER) is sending 407 response. Catch network
traffic (i.e. traces) and send them here to the list. Do it on both
sides, SER and SIP-AS. This is critical.
2. Your SER is using some other configuration file (it's my best guess
now), not the one that you've sent. Please, check thoroughly on this
issue.
3. Do a fresh start with your configuration file. You will lose 1
(maximum 2) hours, but at least it's gonna work.
I really wish you best of luck on this one, man!
Andrey.
On 11/4/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Hi All
In current scenario when a sip invite message comes to SER from my SIP_AS; SER take this
massage trusted (as I defined in trusted table) but after this in my INVITE route(3) it
sends it to route(1) default message handler. I am enclosing my ser.cfg; please take a
glance on it.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: John Shellhouse [mailto:jwshel@hotmail.com]
Sent: Friday, November 03, 2006 9:17 PM
To: Mann, Kamal
Subject: RE: [serusers]: trusted table(permissions module)
Hi,
you've already tried something more filled in like this...
if (!proxy_authorize("somedomain.com","subscriber")) {
proxy_challenge("somedomain.com","0");
break;
} else if (method == "INVITE" & !check_from()) {
log("from!=digest\n");
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
T
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
From: <Kamal.Mann(a)t-systems.com>
To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
Subject: RE: [serusers]: trusted table(permissions module)
Date: Fri, 3 Nov 2006 15:40:26 +0100
Hi All
Now SER is trusting packates from trusted table IP and in the following
part of route(3) of Invite message handler allow_trusted results 'true' and
it directly bypasses this code.
if (!allow_trusted())
{
if (!proxy_authorize("","subscriber"))
{
proxy_challenge("","0");
break;
}
else if (!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
But after in route(1) its sending 407-proxy auth required to trusted ip of
sip_AS. Please help me out of this dilemma.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Thursday, November 02, 2006 1:13 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
The one you attached, didnt have a semicolon. Anyway, try using a
fresh copy of a ready made ser.cfg.
Bests,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Yup I always do the same, Might be copy paste
error. Its having
semicolon & working fine here.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Thursday, November 02, 2006 10:34 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Whenever you modified your ser.cfg did you restart SER after? Did you
check your ser.cfg for errors using "ser -c" command? I found some
errors in your ser.cfg code. For instance, inside the main route
block, your "if", which processes INVITEs, is missing a semicolon at
the end of the block.
if (method=="INVITE")
{
# sl_send_reply("404", "INVITE ");
route(3);
break;
} <----- missing semicolon here
If you are comfortable with your current ser.cfg, that's ok, but I'd
suggest you start with a fresh one, make your trusted table work, and
then add a "REFER" processing, like in your currect ser.cfg. Just
download one fresh ser.cfg from iptel.org site and add your
allow_trusted() "if" clause there.
Regards,
Andrey.
On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi
> Please find ser.cfg enclosed.
>
> Trusted table entry:
> +---------------+-------+--------------+
> | src_ip | proto | from_pattern |
> +---------------+-------+--------------+
> | 10.25.119.156 | any | ^sip:.*$ |
> +---------------+-------+--------------+
> 1 row in set (0.00 sec)
>
> Thanks in anticipation
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Wednesday, November 01, 2006 7:03 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I understand your setup. Nevertheless, it will be difficult to figure
> out your problem, w/o your ser.cfg file at hand. Also, send a trusted
> table query result (i.e. that row which contains entry for your
> SIP-AS).
>
> Regards,
>
> Andrey.
>
> On 11/1/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In my scenario I need ser to communicate with my SIP-AS. This SIP-AS
is
having an application xyz running on it. This XYZ sends an invite to URI
"A(a)xcv.de" which is a subscriber in SER and this is in TO header of Invite
msg & FROM header contains another URI test(a)xcv.de but this URI
(test(a)xcv.de) isn't registered / subscribed to SER. I need SER trust all
packets from SIP-AS ip. BUT SER is sending 407 reply of INVITE to XYZ
application! IP in trusted table is of SIP-AS on top of which XYZ
application is running.
> >
> > Thanks in anticipation
> > Kamal Mann
> >
> > -----Original Message-----
> > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > Sent: Wednesday, November 01, 2006 3:20 PM
> > To: serusers(a)lists.iptel.org
> > Subject: Re: [serusers]: trusted table(permissions module)
> >
> > Kamal.Mann(a)t-systems.com wrote:
> >
> > > Hi All
> > >
> > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into trusted
table so
> > > that any packet sent from
10.25.119.156 would be trusted by SER
and
> > > don't ask for its credentials.
But SER is replying *407- proxy*
auth
> > > needed!! After this I tried with
permissions.allow file:
> > >
> > Hi,
> > I had the same issue while interconnecting SER and Asterisk. It
turned
> > out to be an issue on Asterisk side (I
had the same user added for
SER
> > and Asterisk, so the poor thing
couldn't authorize either :)) So you
> > could check if the 407 you're getting is from SER or from the remote
host.
> >
> > Regards,
> > Maciej Zwirski
> >
> >
----------------------------------------------------------------------
> > Jestes kierowca? To poczytaj!
>>> http://link.interia.pl/f199e
> >
> > _______________________________________________
> > 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
> >
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:22 a.m.
New subject: [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(a)t-systems.com <Kamal.Mann(a)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
10:25 a.m.
New subject: [serusers]: trusted table(permissions module)
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?
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.
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 11:52 AM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:47 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)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.
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.
Regards
Kamal Mann
Regards,
Andrey.
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 11:52 AM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:55 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi again,
Yups.. Nils is right..It says:
"... req_src_ip=10.25.119.155 req_src_port=5060 in_uri=10.25.119.155
out_uri=10.25.119.155 ..."
out_uri should be 10.25.119.156 (not 155)
Andrey.
On 11/6/06, Andrey Kuprianov <andrey.kouprianov(a)gmail.com> wrote:
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)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.
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.
Regards
Kamal Mann
Regards,
Andrey.
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 11:52 AM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:03 p.m.
New subject: [serusers]: trusted table(permissions module)
Hi All,
So what you guys expect; I need to do in this case? Please give your
helpful suggestions;
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 1:26 PM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi again,
Yups.. Nils is right..It says:
"... req_src_ip=10.25.119.155 req_src_port=5060 in_uri=10.25.119.155
out_uri=10.25.119.155 ..."
out_uri should be 10.25.119.156 (not 155)
Andrey.
On 11/6/06, Andrey Kuprianov <andrey.kouprianov(a)gmail.com> wrote:
packets.
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.
> Regards
> Kamal Mann
Regards,
Andrey.
> -----Original Message-----
> From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)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.
> In SIP packet its 5060 only. Port is changed only in UDP/TCP > 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.
> 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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:08 p.m.
New subject: [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:
Due to UDP checksum not beeing correct.
Michal
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
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.
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. 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. Regards
Kamal Mann
Regards,
Andrey.
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 11:52 AM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:43 p.m.
New subject: [serusers]: trusted table(permissions module)
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@iptel.org]
Sent: Monday, November 06, 2006 2:39 PM
To: serusers(a)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:
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.
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
sent
_______________________________________________
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
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)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. > 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.
Regards
Kamal Mann
Regards,
Andrey.
> -----Original Message-----
> From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I noticed one strange thing in your traces. INVITE from SIP-AS is > 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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1:12 p.m.
New subject: [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(a)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@iptel.org]
Sent: Monday, November 06, 2006 2:39 PM
To: serusers(a)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:
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.
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
sent
_______________________________________________
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
Hi,
See inline
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)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. > 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.
Regards
Kamal Mann
Regards,
Andrey.
> -----Original Message-----
> From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I noticed one strange thing in your traces. INVITE from SIP-AS is > 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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:09 p.m.
New subject: [serusers]: trusted table(permissions module)
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(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michal Matyska
Sent: Monday, November 06, 2006 3:43 PM
To: Mann, Kamal
Cc: serusers(a)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(a)t-systems.com wrote:
too),
capture
sent
_______________________________________________
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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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@iptel.org]
Sent: Monday, November 06, 2006 2:39 PM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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 should have
this port. If someone else has some good ideas, plz,
comment.
What Andrey describes is symetric signalling, what we see in the 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.
marked
> 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 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@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I noticed one strange thing in your traces. INVITE from SIP-AS is > 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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:41 p.m.
New subject: [serusers]: trusted table(permissions module)
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(a)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(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michal Matyska
Sent: Monday, November 06, 2006 3:43 PM
To: Mann, Kamal
Cc: serusers(a)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(a)t-systems.com wrote:
too),
capture
sent
_______________________________________________
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
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@iptel.org]
Sent: Monday, November 06, 2006 2:39 PM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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 should
have this port. If someone else has some good ideas, plz,
comment.
What Andrey describes is symetric signalling, what we see in the 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.
marked
> 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 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@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> I noticed one strange thing in your traces. INVITE from SIP-AS is > 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(a)t-systems.com <Kamal.Mann(a)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(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
7 Nov
7 Nov
9:27 a.m.
New subject: [serusers]: trusted table(permissions module)
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(a)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(a)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(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michal Matyska
Sent: Monday, November 06, 2006 3:43 PM
To: Mann, Kamal
Cc: serusers(a)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(a)t-systems.com wrote:
too),
capture
_______________________________________________
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
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@iptel.org]
Sent: Monday, November 06, 2006 2:39 PM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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 should
have this port. If someone else has some good ideas, plz,
comment.
What Andrey describes is symetric signalling, what we see in the 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.
marked
> 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 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@gmail.com]
> Sent: Monday, November 06, 2006 11:52 AM
> To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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(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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6 Nov
6 Nov
10:29 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi All
I tried with omitting that proxy-auth part then its replying with 'too
many hops'!
Regards
Kamal Mann
-----Original Message-----
From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
Sent: Monday, November 06, 2006 11:52 AM
To: serusers(a)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(a)t-systems.com <Kamal.Mann(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:22 a.m.
New subject: [serusers]: trusted table(permissions module)
Hi Kamal,
take a look at the Warning header in the 407: it tells you that the INVITE was
relayed to your server again (in a loop) and in the second round your script
replies with 407 (because this time it is not comming from the GW any more).
Nils
On Monday 06 November 2006 06:46, Kamal.Mann(a)t-systems.com wrote:
_______________________________________________
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
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)
wrote:
From URI is Application Name (example) and neither
created nor registered
(WakeUpService) with SER.
Thanks in anticipation
Kamal Mann
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Monday, November 06, 2006 11:04 AM
To: serusers(a)iptel.org
Subject: Re: [serusers]: trusted table(permissions module)
Hi Kamal,
Please (!), do network dump and send it here. Use tcpdump, ngrep,
Ethereal, anything to catch your network traffic on port 5060.
Waiting for your traces,
Andrey.
On 11/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> Hi Andrey,
> Yes you are right it not bypassing that part of code (route [3]).But why
> it is so? Its not trusting SIP AS IP! I had recompiled permissions module
> but still the same response!!
>
> Regards
> Kamal Mann
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
> Sent: Saturday, November 04, 2006 6:20 PM
> To: serusers(a)iptel.org
> Subject: Re: [serusers]: trusted table(permissions module)
>
> Hi Kamal,
>
> Really, there are only 2 places in your ser.cfg, where proxy_authorize
> is called. One is inside route[3] block, and one, which is commented
> out is inside the main route block. Since, one proxy_authorize is
> commented out, this leaves the only a single proxy_authorize - the one
> inside route[3] block. Now... In your previous mail you said,
> "allow_trusted results 'true' and it directly bypasses this
code."
> This means only one thing - there are *no more* proxy_authorize left
> to call...
>
> You also said "But after in route(1) its sending 407-proxy auth
> required to trusted ip of sip_AS". That is impossible. Your route[1]
> block cannot and does not send 407 response. There's simply no
> proxy_authorize code in there and SER does not do it automatically!
>
> I have several ideas (some of them were already presented in previous
> mails):
>
> 1. Something else (not SER) is sending 407 response. Catch network
> traffic (i.e. traces) and send them here to the list. Do it on both
> sides, SER and SIP-AS. This is critical.
> 2. Your SER is using some other configuration file (it's my best guess
> now), not the one that you've sent. Please, check thoroughly on this
> issue.
> 3. Do a fresh start with your configuration file. You will lose 1
> (maximum 2) hours, but at least it's gonna work.
>
> I really wish you best of luck on this one, man!
>
> Andrey.
>
> On 11/4/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote:
> > Hi All
> > In current scenario when a sip invite message comes to SER from my
> > SIP_AS; SER take this massage trusted (as I defined in trusted table)
> > but after this in my INVITE route(3) it sends it to route(1) default
> > message handler. I am enclosing my ser.cfg; please take a glance on it.
> >
> > Thanks in anticipation
> > Kamal Mann
> > -----Original Message-----
> > From: John Shellhouse [mailto:jwshel@hotmail.com]
> > Sent: Friday, November 03, 2006 9:17 PM
> > To: Mann, Kamal
> > Subject: RE: [serusers]: trusted table(permissions module)
> >
> > Hi,
> >
> > you've already tried something more filled in like this...
> >
> >
> > if (!proxy_authorize("somedomain.com","subscriber")) {
> > proxy_challenge("somedomain.com","0");
> > break;
> > } else if (method == "INVITE" & !check_from()) {
> > log("from!=digest\n");
> > sl_send_reply("403", "Use From=ID");
> >
> > break;
> > };
> > consume_credentials();
> >
> > T
> >
> > >From: <Kamal.Mann(a)t-systems.com>
> > >To: <andrey.kouprianov(a)gmail.com>om>, <serusers(a)iptel.org>
> > >Subject: RE: [serusers]: trusted table(permissions module)
> > >Date: Fri, 3 Nov 2006 15:40:26 +0100
> > >
> > >Hi All
> > >Now SER is trusting packates from trusted table IP and in the
> > > following part of route(3) of Invite message handler allow_trusted
> > > results 'true' and it directly bypasses this code.
> > >if (!allow_trusted())
> > >{
> > > if (!proxy_authorize("","subscriber"))
> > > {
> > > proxy_challenge("","0");
> > > break;
> > > }
> > > else if (!check_from())
> > > {
> > > sl_send_reply("403", "Use From=ID");
> > > break;
> > > };
> > > consume_credentials();
> > >};
> > >But after in route(1) its sending 407-proxy auth required to trusted
> > > ip of sip_AS. Please help me out of this dilemma.
> > >
> > >Thanks in anticipation
> > >Kamal Mann
> > >
> > >-----Original Message-----
> > >From: serusers-bounces(a)lists.iptel.org
> > >[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey
> > > Kuprianov Sent: Thursday, November 02, 2006 1:13 PM
> > >To: serusers(a)iptel.org
> > >Subject: Re: [serusers]: trusted table(permissions module)
> > >
> > >The one you attached, didnt have a semicolon. Anyway, try using a
> > >fresh copy of a ready made ser.cfg.
> > >
> > > Bests,
> > >
> > > Andrey.
> > >
> > >On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com>
wrote:
> > > > Yup I always do the same, Might be copy paste error. Its having
> > >
> > >semicolon & working fine here.
> > >
> > > > Regards
> > > > Kamal Mann
> > > >
> > > > -----Original Message-----
> > > > From: Andrey Kuprianov [mailto:andrey.kouprianov@gmail.com]
> > > > Sent: Thursday, November 02, 2006 10:34 AM
> > > > To: serusers(a)iptel.org
> > > > Subject: Re: [serusers]: trusted table(permissions module)
> > > >
> > > > Hi Kamal,
> > > >
> > > > Whenever you modified your ser.cfg did you restart SER after? Did
> > > > you check your ser.cfg for errors using "ser -c" command? I
found
> > > > some errors in your ser.cfg code. For instance, inside the main
> > > > route block, your "if", which processes INVITEs, is missing
a
> > > > semicolon at the end of the block.
> > > >
> > > > if (method=="INVITE")
> > > > {
> > > > # sl_send_reply("404", "INVITE ");
> > > > route(3);
> > > > break;
> > > > } <----- missing semicolon here
> > > >
> > > >
> > > > If you are comfortable with your current ser.cfg, that's ok, but
> > > > I'd suggest you start with a fresh one, make your trusted table
> > > > work, and then add a "REFER" processing, like in your
currect
> > > > ser.cfg. Just download one fresh ser.cfg from iptel.org site and
> > > > add your allow_trusted() "if" clause there.
> > > >
> > > > Regards,
> > > >
> > > > Andrey.
> > > >
> > > > On 11/2/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com>
> > > > > Hi
> > > > > Please find ser.cfg enclosed.
> > > > >
> > > > > Trusted table entry:
> > > > > +---------------+-------+--------------+
> > > > >
> > > > > | src_ip | proto | from_pattern |
> > > > >
> > > > > +---------------+-------+--------------+
> > > > >
> > > > > | 10.25.119.156 | any | ^sip:.*$ |
> > > > >
> > > > > +---------------+-------+--------------+
> > > > > 1 row in set (0.00 sec)
> > > > >
> > > > > Thanks in anticipation
> > > > > Kamal Mann
> > > > > -----Original Message-----
> > > > > From: serusers-bounces(a)lists.iptel.org
> > >
> > >[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey
> > > Kuprianov
> > >
> > > > > Sent: Wednesday, November 01, 2006 7:03 PM
> > > > > To: serusers(a)iptel.org
> > > > > Subject: Re: [serusers]: trusted table(permissions module)
> > > > >
> > > > > Hi Kamal,
> > > > >
> > > > > I understand your setup. Nevertheless, it will be difficult to
> > > > > figure out your problem, w/o your ser.cfg file at hand. Also,
> > > > > send a trusted table query result (i.e. that row which contains
> > > > > entry for your SIP-AS).
> > > > >
> > > > > Regards,
> > > > >
> > > > > Andrey.
> > > > >
> > > > > On 11/1/06, Kamal.Mann(a)t-systems.com
<Kamal.Mann(a)t-systems.com>
wrote:
> > >
Hi All
> > > In my scenario I need ser to communicate with my SIP-AS. This
> > > SIP-AS
is having an application xyz running on it. This XYZ sends an invite
to URI "A(a)xcv.de" which is a subscriber in SER and this is in TO
header of Invite msg & FROM header contains another URI test(a)xcv.de
but this URI (test(a)xcv.de) isn't registered / subscribed to SER. I
need SER trust all packets from SIP-AS ip. BUT SER is sending 407
reply of INVITE to XYZ application! IP in trusted table is of SIP-AS
on top of which XYZ application is running.
> > > Thanks in anticipation
> > > Kamal Mann
> > >
> > > -----Original Message-----
> > > From: Maciej ¯wirski [mailto:mzwirek@poczta.fm]
> > > Sent: Wednesday, November 01, 2006 3:20 PM
> > > To: serusers(a)lists.iptel.org
> > > Subject: Re: [serusers]: trusted table(permissions module)
> > >
> > > Kamal.Mann(a)t-systems.com wrote:
> > > > Hi All
> > > >
> > > > I made an entry /"10.25.119.156, any, ^sip:.*$"/ into
trusted
table so
> > > > that any packet sent from 10.25.119.156 would be trusted by
> > > > SER
and
> > > > don't ask for its credentials. But SER is replying *407-
> > > > proxy*
auth
> > > > needed!! After this I tried with permissions.allow file:
> > >
> > > Hi,
> > > I had the same issue while interconnecting SER and Asterisk. It
turned
> > > out to be an issue on Asterisk side (I had the same user added
> > > for
SER
> > > and Asterisk, so the poor thing couldn't authorize either :))
> > > So you could check if the 407 you're getting is from SER or
> > > from the remote
host.
> > > Regards,
> > > Maciej Zwirski
----------------------------------------------------------------------
> > > Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e
> > >
> > > _______________________________________________
> > > 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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6534
days inactive
6537
days old
17 comments
4 participants
participants (4)
-
Andrey Kuprianov -
Kamal.Mann＠t-systems.com -
Michal Matyska -
Nils Ohlmeier