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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org Subject: Re: [serusers]: trusted table(permissions module)
Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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/
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@t-systems.com Kamal.Mann@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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org Subject: Re: [serusers]: trusted table(permissions module)
Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Saturday, November 04, 2006 6:20 PM To: serusers@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@t-systems.com Kamal.Mann@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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org Subject: Re: [serusers]: trusted table(permissions module)
Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@t-systems.com Kamal.Mann@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Saturday, November 04, 2006 6:20 PM To: serusers@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):
- 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@t-systems.com Kamal.Mann@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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org Subject: Re: [serusers]: trusted table(permissions module)
Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Monday, November 06, 2006 11:04 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Saturday, November 04, 2006 6:20 PM To: serusers@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):
- 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@t-systems.com Kamal.Mann@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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org Subject: Re: [serusers]: trusted table(permissions module)
Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@t-systems.com Kamal.Mann@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
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@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
See inline
On 11/6/06, Kamal.Mann@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@gmail.com wrote:
Hi,
See inline
On 11/6/06, Kamal.Mann@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@gmail.com wrote:
Hi,
See inline
On 11/6/06, Kamal.Mann@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@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@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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@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@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@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@t-systems.com Kamal.Mann@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@gmail.com] Sent: Monday, November 06, 2006 11:52 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@t-systems.com Kamal.Mann@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Monday, November 06, 2006 11:04 AM To: serusers@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@t-systems.com Kamal.Mann@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Saturday, November 04, 2006 6:20 PM To: serusers@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):
- 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@t-systems.com Kamal.Mann@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@t-systems.com To: andrey.kouprianov@gmail.com, serusers@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@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov Sent: Thursday, November 02, 2006 1:13 PM To: serusers@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@t-systems.com Kamal.Mann@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@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@t-systems.com Kamal.Mann@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@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andrey Kuprianov
Sent: Wednesday, November 01, 2006 7:03 PM To: serusers@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@t-systems.com Kamal.Mann@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@xcv.de" which is a subscriber in SER and this is in TO header of Invite msg & FROM header contains another URI test@xcv.de but this URI (test@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@lists.iptel.org > Subject: Re: [serusers]: trusted table(permissions module) > > Kamal.Mann@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ > Serusers mailing list > Serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andrey Kuprianov -
Kamal.Mann＠t-systems.com -
Michal Matyska -
Nils Ohlmeier