Well, you need to use the enum feature in your script, not just to load the module. For example at iptel, we resolve all numbers beginning with + by ENUM:
# is this an ENUM destination (leading +?) if (method=="INVITE" && uri=~"sip:+[0-9]+@iptel.org") { if (!enum_query("voice")) # if parameter empty, it defaults to "e2u+sip" enum_query(""); # E2U+sip };
-jiri
At 04:30 PM 8/19/2003, radan wrote:
Hello all ! This time I have problem with enum (ver 0.8.11pre29) I've loaded a module enum.so and did ENUM NAPTR Records like this (according with draft-ietf-sipping-e164-02)
$TTL 259200 @ IN SOA dns.gda.pl. dns.gda.pl. ( 3 1D 2H 4W 4D ) IN NS dns.gda.pl.
$ORIGIN 7.7.0.1.7.4.3.8.5.8.4.e164.arpa.
IN NAPTR 100 10 "u" "sip+e2u" "!^.*$!sip:anji@mydomian.pl!" . IN NAPTR 100 20 "u" "mailto+e2u" "!^.*$mailto:radan@.mydomian.pl!" .
The zone is loaded correctly. When i dial to +48583471077 or 48583471077 I have 404 (User nod found) Do I need some special parameters or commands in ser.cfg ? I saw all archive and did't find information.
Any help will be appreciate.
Greetings Andrzej
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
On Tue, 19 Aug 2003, Jiri Kuthan wrote:
Well, you need to use the enum feature in your script, not just to load the module. For example at iptel, we resolve all numbers beginning with + by ENUM:
# is this an ENUM destination (leading +?) if (method=="INVITE" && uri=~"sip:\+[0-9]+@iptel\.org") { if (!enum_query("voice")) # if parameter empty, it defaults to "e2u+sip" enum_query(""); # E2U+sip };
Thanks Jiri but it still doesn't works. Ser does't send query about NAPTR record to my DNS :(
Is still have 404 :(
The zone is correct (received from dns query for my DNS enum) 7.7.0.1.7.4.3.8.5.8.4.e164.arpa. 259200 IN NAPTR 100 10 "u" "sip+e2u" "!^.*$!sip:radan@gda.pl!"
For all Enum testers
I' ve tested Jiri's code and I think, there shoudl be an * behind numbers && uri=~"sip:+[0-9]*@iptel.org (if I use the domain [not only uri=~"sip:+[0-9]*@] it doesn't work. It's my fault,I think, but I can't figure it out) Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK"). I'm not sure, but in my script it depends whether I cover all other redirections and lookup("location") with (method=="INVITE") or not
Don't forget to put the code BEFORE lookup("location");
Jan
On Wed, 2003-08-20 at 12:03, radan wrote:
On Tue, 19 Aug 2003, Jiri Kuthan wrote:
Well, you need to use the enum feature in your script, not just to load the module. For example at iptel, we resolve all numbers beginning with + by ENUM:
# is this an ENUM destination (leading +?) if (method=="INVITE" && uri=~"sip:\+[0-9]+@iptel\.org") { if (!enum_query("voice")) # if parameter empty, it defaults to "e2u+sip" enum_query(""); # E2U+sip };
Thanks Jiri but it still doesn't works. Ser does't send query about NAPTR record to my DNS :(
Is still have 404 :(
The zone is correct (received from dns query for my DNS enum) 7.7.0.1.7.4.3.8.5.8.4.e164.arpa. 259200 IN NAPTR 100 10 "u" "sip+e2u" "!^.*$!sip:radan@gda.pl!"
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 07:14 PM 8/21/2003, Jan Ruzicka wrote:
For all Enum testers
I' ve tested Jiri's code and I think, there shoudl be an * behind numbers && uri=~"sip:+[0-9]*@iptel.org
What is the problem with +? That tells that I would like to have at least one digit....
(if I use the domain [not only uri=~"sip:+[0-9]*@] it doesn't work. It's my fault,I think, but I can't figure it out)
Show us your regexp and requests -- we will see :)
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
-jiri
On Thu, 2003-08-21 at 21:40, Jiri Kuthan wrote:
At 07:14 PM 8/21/2003, Jan Ruzicka wrote:
For all Enum testers
I' ve tested Jiri's code and I think, there shoudl be an * behind numbers && uri=~"sip:+[0-9]*@iptel.org
What is the problem with +? That tells that I would like to have at least one digit....
(if I use the domain [not only uri=~"sip:+[0-9]*@] it doesn't work. It's my fault,I think, but I can't figure it out)
Show us your regexp and requests -- we will see :)
Its weird, I wrote the line once more, tested it part by part and it works :-)
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
-jiri
On 21-08 21:40, Jiri Kuthan wrote:
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
Does it really make sense to do ENUM lookup for CANCEL and ACK ? ACK is an in-dialog request and thus Request-URI will contain Contact of the callee -- which will be not an ENUM number.
In case of CANCEL, it makes sense only if the Request-URI of the CANCEL is used to match ENUM-rewritten Request-URI of the original INVITE.
Jan.
At 02:12 PM 8/22/2003, Jan Janak wrote:
On 21-08 21:40, Jiri Kuthan wrote:
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
Does it really make sense to do ENUM lookup for CANCEL and ACK ? ACK is an in-dialog request and thus Request-URI will contain Contact of the callee -- which will be not an ENUM number.
indeed, ACK does not matter.
In case of CANCEL, it makes sense only if the Request-URI of the CANCEL is used to match ENUM-rewritten Request-URI of the original INVITE.
Which is only always.
-jiri
At 02:15 PM 8/22/2003, Jiri Kuthan wrote:
At 02:12 PM 8/22/2003, Jan Janak wrote:
On 21-08 21:40, Jiri Kuthan wrote:
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
Does it really make sense to do ENUM lookup for CANCEL and ACK ? ACK is an in-dialog request and thus Request-URI will contain Contact of the callee -- which will be not an ENUM number.
indeed, ACK does not matter.
Errata: it matters too, think of stateless forwarding. -jiri
-- Jiri Kuthan http://iptel.org/~jiri/
On 22-08 14:19, Jiri Kuthan wrote:
At 02:15 PM 8/22/2003, Jiri Kuthan wrote:
At 02:12 PM 8/22/2003, Jan Janak wrote:
On 21-08 21:40, Jiri Kuthan wrote:
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
Does it really make sense to do ENUM lookup for CANCEL and ACK ? ACK is an in-dialog request and thus Request-URI will contain Contact of the callee -- which will be not an ENUM number.
indeed, ACK does not matter.
Errata: it matters too, think of stateless forwarding. -jiri
No, it doesn't matter. In-dialog requests are routed according to the Route headers--it doesn't matter if you forward them statefully or statelessly.
Jan.
At 02:33 PM 8/22/2003, Jan Janak wrote:
On 22-08 14:19, Jiri Kuthan wrote:
At 02:15 PM 8/22/2003, Jiri Kuthan wrote:
At 02:12 PM 8/22/2003, Jan Janak wrote:
On 21-08 21:40, Jiri Kuthan wrote:
Depends on script, but sometimes could be usefull to test CANCEL and ACK too (method=="INVITE" || method=="CANCEL" || method=="ACK").
Agreed, thanks.
Does it really make sense to do ENUM lookup for CANCEL and ACK ? ACK is an in-dialog request and thus Request-URI will contain Contact of the callee -- which will be not an ENUM number.
indeed, ACK does not matter.
Errata: it matters too, think of stateless forwarding. -jiri
No, it doesn't matter. In-dialog requests are routed according to the Route headers--it doesn't matter if you forward them statefully or statelessly.
We are speaking about CANCEL (and also negative ACK), which are not in-dialog requeests. That's it.
-jiri