On Tue, 29 Nov 2005 14:46:55 +0100 (CET), harry gaillac wrote
>
> REGISTER:
>
> if (!is_from_local()) {
> sl_send_reply("401", "Unauthorized");
> break;
> };
> rewritehostport("nxs.yi.org:5050");
> t_relay_to_udp("nxs.yi.org","5050");
So... you want your users to register both with Asterisk AND with SER? What
for? Why not use some form of SER authorisation to control access to the
Asterisk server? I'm not sure what you're trying to do here...
>
> INVITE:
> rewritehostport("nxs.yi.org:5050");
What's the context around this? You want ALL calls to go straight to Asterisk?
It just seems... I don't know... weird. I assume you're doing this because SER
handles presence and Asterisk doesn't... but everything else you want to be
controlled by Asterisk, including user registration, etc, etc.
For your invite, btw, you would need to also have a t_relay_to_udp, or
alternatively, you can do it as:
rewritehostport("nxs.yi.org:5050");
forward(uri:host,uri:port);
break;
>
> sip.conf:
> [general]
> context=local ; Default context for
> incoming calls
> ; if asterisk was
> compiled with OSP support.
> realm=nxs.yi.org ; Realm for digest
> authentication
> ; defaults to
> "asterisk"
> ; Realms MUST be
> globally unique according to RFC 3261
> ; Set this to your
> host name or domain name
> bindport=5050 ; UDP Port to bind to
> (SIP standard port is 5060)
> bindaddr=nxs.yi.org ; IP address to bind
> to (0.0.0.0 binds to all)
> srvlookup=yes ; Enable DNS SRV
> lookups on outbound calls
> tos=lowdelay ;
> lowdelay,throughput,reliability,mincost,none
> maxexpirey=3600 ; Max length of
> incoming registration we allow
> defaultexpirey=1000 ; Default length of
> incoming/outoing registration
> allow=all ; First disallow all
> codecs
> musicclass=default ; Sets the default
> music on hold class for all SIP calls
> language=fr ; Default language
> setting for all users/peers
> rtptimeout=60 ; Terminate call if 60
> seconds of no RTP activity
> tpholdtimeout=300 ; Terminate call if
> 300 seconds of no RTP activity
> useragent=Asterisk PBX ; Allows you to change
> the user agent string
> dtmfmode = rfc2833 ; Set default dtmfmode
> for sending DTMF. Default: rfc2833
> promiscredir = no ; If yes, allows 302
> or REDIR to non-local SIP address
>
> [84]
> type=friend
> secret=84
> username=84
> context=local
> host=dynamic
> mailbox=84
> allow=all
>
> [85]
> type=friend
> secret=85
> username=85
> context=local
> host=dynamic
> mailbox=85
> allow=all
>
In your blocks there, you might want to add
insecure=very
to allow registered hosts to call without reauthenticating -- just to speed
things up a little (optional)
one IMPORTANT thing you want to add to each block just to make sure it's there is:
canreinvite=yes
This allows the RTP traffic to bypass asterisk and just go from UA to UA
without taking up bandwidth. It will NOT, however, work well for NATted users
without playing around with rewriting the SDP (using something like a
nathelper fix_nated_sdp("3") call)
Rereading your original emails, I now think I understand that this is what you
were asking about before (correct me if I'm wrong)... was the fix_nated_sdp
not working correctly in some way?
N.
hello,
what is the usual method to use the cpl module when a pstn gateway needs
to know which user is responsible a call?
e.g. i have a pstn gateway pstn.example. numbers are dialed by
specifying them as user part of a sip uri => 00321234(a)pstn.example. as
the gateway is an asterisk box i'm rather flexible in choosing a method
which specifies how the name of the remote-user is transfered to the
gateway.
if a user does a forward to the pstn (e.g. in the case of no-answer) he
should also be accounted for the call - so i either need to set the
'From' header to the owner of the cpl script or i need to add another
header like 'X-account' which specifies the owner.
a solution for this seems to be to store the name of the callee in an
AVP before executing the script and to set the From field in proxy_route
after the script has started.
are there better or more-standard solutions for this problem?
bye,
/gst
Hi,
Can anyone help clarify the following:
According to LCR module docs for version 1.0.0, "gateway selection is
based on caller's RPID URI (if available in caller's RPID AVP after
authentication) or From URI and user part of Request-URI (telephone
number)."
What is the RPID AVP and how is it set?
The docs also say "a gateway matches a request if user part of
Request-URI and "From" URI match the prefix and From pattern of the
gateway".
But in gw table, there is no From pattern column, just prefix:
gw_name | grp_id | ip_addr | port | uri_scheme | transport | prefix
Also, it would be nice if gw matching could be based also on request
method, request headers, or even arbitrary AVPs which would be set
somewhere else. What do folks think about this?
Thanks,
JF
Hello,
Does nathelper module would support rfc3264 to provide
MOH ?
Harry
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
Hi,
currently i have a configuration that works when UA use ip adresseses for
contacting the server. Also ip is used for the domain.
What i would like users to do is use a domain ie sip1.otenet-telecom.net to
register. Domain is setup A record and points to the ip of the server.
Users register ok but when they try to make a call, if(uri!=myself) returns
true and the call does not go through.
uri is number(a)sip1.otenet-telecom.net
sip1.otenet-telecom.net is in the domain mysql table.
What do i do to get the server recognize the calls from users using the
domain?
thanks
--
Kyriakos Mavromichalis
Otenet Telecom
Hi,
In my lab we have SER (0.9.4) running, collocated in the same box with
SEMS, communicating via the fifo.
An abstraction of the config:
//identify traffic for SEMS
//send to route[x]
route[x] {
if( !t_newtran() ) { ..... }
if( method == "ACK" ) { break;} //drop local acks ...
t_reply("100", "msg");
send via fifo to sems ...
}
I have stumbled against some problems:
P1) Local ACKs from the phone are not being dropped.
P2) to-tag in replies from SER from sl_send_reply and OK message change
P3) the t_newtran does not stop sending OKs, even it receives ACKs to them
They all seem to be related ...
the ACK from the phone back to SER, which are local(right?), are not
dropped for two reasons: the sl_timeout is not updated, as i don't
have an sl_send_reply in the route[x] block.
I can fix the above by adding an sl_send_reply("183", "sems session in
progress") ... but then, the second problem appears.
Adding the sl_send_reply(183, ) adds a to-tag to the 183-reply, but
then the following OK has a completely different to-tag ... which is
the one used by my UA to create the ACK. As the to-tag in the ACK is
different to that from the 183-reply ... the sl_filter_ack does not
recognize the ACK as local, and does not filter it.
In any case, this would not solve the problem of the t_newtran sending
OK replies to the phone, even it receives ACKs to them.
What can i do? should i use t_release somewhere? are these ACKs
"local"? if not, where should these ACKs be routed to, to the route[x]
block?
Tks in advance,
Cesc
serusers list moderators look like the ministere of
the propaganda of Reinhard Goebel well known in
germany!
I'm tired of moderators
Harry Gaillac from France
--- serusers-bounces(a)iptel.org a écrit :
> Your request to the Serusers mailing list
>
> Posting of your message titled "Re: [Users]
> rfc3264 and nathelper
> module"
>
> has been rejected by the list moderator. The
> moderator gave the
> following reason for rejecting your request:
>
> "Your message was deemed inappropriate by the
> moderator."
>
> Any questions or comments should be directed to the
> list administrator
> at:
>
> serusers-owner(a)iptel.org
>
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
Hi Enky!
Please always Cc: to the list!
Setting up a dedicated outboundproxy (e.g. like Jasomi peerpoint or SNOM
NAT filter) is not trivial. Typical this applications do all the NAT
traversal and are transparent to SIP proxy. That means the SIP proxy
does not have knowledge of the existence of such an outboundproxy.
This is done by replacing the Contact: URI from the client with a URI
pointing to the outboundproxy, and a random username (which will be
mapped to the real client URI inside the outboundproxy). Some of them
are real B2BUAs, some of them are some kind of proxy. All of them have
in common, that they need to have a local "location table" to store the
mapping from the real SIP clients to the SIP clients presented to the
main SIP proxy.
Another approach is the Path extension in RFC 3327
(http://ietf.org/rfc/rfc3327). This requires support by the main proxy,
which has to store the location of the client plus the path to the
client (i.e. the outbound proxy). Support for this extension is
currently under development in the experimental tree (search the mailing
list archive for more info).
Back to the former approach: for REGISTER: ser as outboundproxy has to
store the contact of the NATed client, and then replaces it with an
unique identifier and send the message upstream to the main proxy. If
the registration was sucessfull, the mapping will be valid. In the
response, ser has to change the "virtual user" in the Contact: header
back to the original Contact: header, as otherwise some clients get
confused and reject the 200 Ok response.
AFAIK there is no way to achieve this with ser without modifying code.
Maybe AVPs can help, but i'm not sure.
regards
klaus
asterisk(a)bgopentel.com wrote:
> Dear Klaus,
> thank you for your attention.
> Unfortunately I do not know how to handle this issue. I use a mysql module in the main proxy to store the user data. The main proxy is running on a preconfigured FC1 Linux with a specialized software, installed on it. This software is not related to the SER and VoIP at all, but I can not change the installed software versions and that's why the SER version is rather old, but I can not upgrade it. So, I decided to run a separate proxy to only handle the NAT issues.
> Please tell me what I have to configure in the main and in the outbound proxy to have it working? Thank you very much. I appreciate your help and attention.
>
>
>
> Klaus Darilion wrote ..
>
>>How do you make sure that the main proxy sends the INVITE to the
>>outbound proxy, and the outbound proxy sends the request to the client?
>>
>>where do you store the contact information? in the main proxy or in the
>>outbound proxy?
>>
>>regards
>>klaus
>>
>>Enky wrote:
>>
>>>Hi,
>>>I am trying to run the SER as an outbound proxy. Unfortunately I have
>>>some problems. I have used the nathelper/rtpproxy with a customized
>>>ser.conf and the result is that the clients behind NAT are making
>>>outbound calls with no problems. The audio is two-way and all seems
>>>best, but when I try to react a client behind NAT I can not. It is
>>>registered in the SIP Proxy, but I can not dial it.
>>>My scenario is: SER with MySQL authorization on the first PC and SER
>>>with nathelper/rtpproxy for outbound proxy on second PC.
>>>Could someone give me some hint as I can not solve this problem. The
>>>Outbound Proxy SER version is:
>>>version: ser 0.9.3 (i386/linux)
>>>flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
>>>DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>>ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>MAX_URI_SIZE 1024, BUF_SIZE 65535
>>>@(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $
>>>main.c compiled on 20:51:59 Jun 28 2005 with gcc 3.3
>>>
>>>The ser.cfg of the Outbound Proxy SER is:
>>>#
>>># $Id: nathelper.cfg,v 1.1 2003/11/10 14:15:36 janakj Exp $
>>>#
>>># simple quick-start config script including nathelper support
>>>
>>># This default script includes nathelper support. To make it work
>>># you will also have to install Maxim's RTP proxy. The proxy is enforced
>>># if one of the parties is behind a NAT.
>>>#
>>># If you have an endpoing in the public internet which is known to
>>># support symmetric RTP (Cisco PSTN gateway or voicemail, for example),
>>># then you don't have to force RTP proxy. If you don't want to enforce
>>># RTP proxy for some destinations than simply use t_relay() instead of
>>># route(1)
>>>#
>>># Sections marked with !! Nathelper contain modifications for nathelper
>>>#
>>># NOTE !! This config is EXPERIMENTAL !
>>>#
>>># ----------- global configuration parameters ------------------------
>>>
>>>debug=3 # debug level (cmd line: -dddddddddd)
>>>fork=yes
>>>log_stderror=no # (cmd line: -E)
>>>
>>>/* Uncomment these lines to enter debugging mode
>>>fork=no
>>>log_stderror=yes
>>>*/
>>>
>>>check_via=no # (cmd. line: -v)
>>>dns=no # (cmd. line: -r)
>>>rev_dns=no # (cmd. line: -R)
>>>port=5082
>>>children=4
>>>fifo="/tmp/ser_fifo"
>>>
>>># ------------------ module loading ----------------------------------
>>>
>>># Uncomment this if you want to use SQL database
>>>#loadmodule "/usr/local/lib/ser/modules/mysql.so"
>>>
>>>loadmodule "/usr/local/lib/ser/modules/sl.so"
>>>loadmodule "/usr/local/lib/ser/modules/tm.so"
>>>loadmodule "/usr/local/lib/ser/modules/rr.so"
>>>loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
>>>loadmodule "/usr/local/lib/ser/modules/usrloc.so"
>>>loadmodule "/usr/local/lib/ser/modules/registrar.so"
>>>loadmodule "/usr/local/lib/ser/modules/textops.so"
>>>
>>># Uncomment this if you want digest authentication
>>># mysql.so must be loaded !
>>>#loadmodule "/usr/local/lib/ser/modules/auth.so"
>>>#loadmodule "/usr/local/lib/ser/modules/auth_db.so"
>>>
>>># !! Nathelper
>>>loadmodule "/usr/local/lib/ser/modules/nathelper.so"
>>>
>>># ----------------- setting module-specific parameters ---------------
>>>
>>># -- usrloc params --
>>>
>>>modparam("usrloc", "db_mode", 0)
>>>
>>># Uncomment this if you want to use SQL database
>>># for persistent storage and comment the previous line
>>>#modparam("usrloc", "db_mode", 2)
>>>
>>># -- auth params --
>>># Uncomment if you are using auth module
>>>#
>>>#modparam("auth_db", "calculate_ha1", yes)
>>>#
>>># If you set "calculate_ha1" parameter to yes (which true in this config),
>>># uncomment also the following parameter)
>>>#
>>>#modparam("auth_db", "password_column", "password")
>>>
>>># -- rr params --
>>># add value to ;lr param to make some broken UAs happy
>>>modparam("rr", "enable_full_lr", 1)
>>>
>>># !! Nathelper
>>>modparam("registrar", "nat_flag", 6)
>>>modparam("nathelper", "natping_interval", 60) # Ping interval 60 s
>>>modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind
>>
>>NAT
>>
>>>
>>># ------------------------- request routing logic -------------------
>>>
>>># main routing logic
>>>
>>>route{
>>>
>>> # initial sanity checks -- messages with
>>> # max_forwards==0, or excessively long requests
>>> if (!mf_process_maxfwd_header("10")) {
>>> sl_send_reply("483","Too Many Hops");
>>> break;
>>> };
>>> if (msg:len >= max_len ) {
>>> sl_send_reply("513", "Message too big");
>>> break;
>>> };
>>>
>>> # !! Nathelper
>>> # Special handling for NATed clients; first, NAT test is
>>> # executed: it looks for via!=received and RFC1918 addresses
>>> # in Contact (may fail if line-folding is used); also,
>>> # the received test should, if completed, should check all
>>> # vias for rpesence of received
>>> if (nat_uac_test("3")) {
>>> # Allow RR-ed requests, as these may indicate that
>>> # a NAT-enabled proxy takes care of it; unless it is
>>> # a REGISTER
>>>
>>> if (method == "REGISTER" || ! search("^Record-Route:")) {
>>> log("LOG: Someone trying to register from private IP, rewriting\n");
>>>
>>> # This will work only for user agents that support symmetric
>>> # communication. We tested quite many of them and majority is
>>> # smart enough to be symmetric. In some phones it takes a
>>>configuration
>>> # option. With Cisco 7960, it is called NAT_Enable=Yes, with
>>>kphone it is
>>> # called "symmetric media" and "symmetric signalling".
>>>
>>> fix_nated_contact(); # Rewrite contact with source IP of signalling
>>> if (method == "INVITE") {
>>> fix_nated_sdp("1"); # Add direction=active to SDP
>>> };
>>> force_rport(); # Add rport parameter to topmost Via
>>> setflag(6); # Mark as NATed
>>> };
>>> };
>>>
>>> # we record-route all messages -- to make sure that
>>> # subsequent messages will go through our proxy; that's
>>> # particularly good if upstream and downstream entities
>>> # use different transport protocol
>>> if (!method=="REGISTER") record_route();
>>>
>>> # subsequent messages withing a dialog should take the
>>> # path determined by record-routing
>>> if (loose_route()) {
>>> # mark routing logic in request
>>> append_hf("P-hint: rr-enforced\r\n");
>>> route(1);
>>> break;
>>> };
>>>
>>> if (!uri==myself) {
>>> # mark routing logic in request
>>> append_hf("P-hint: outbound\r\n");
>>> route(1);
>>> break;
>>> };
>>>
>>> # if the request is for other domain use UsrLoc
>>> # (in case, it does not work, use the following command
>>> # with proper names and addresses in it)
>>> if (uri==myself) {
>>>
>>> if (method=="REGISTER") {
>>>
>>> save("location");
>>> break;
>>> };
>>>
>>> lookup("aliases");
>>> if (!uri==myself) {
>>> append_hf("P-hint: outbound alias\r\n");
>>> route(1);
>>> break;
>>> };
>>>
>>> # native SIP destinations are handled using our USRLOC DB
>>> if (!lookup("location")) {
>>> sl_send_reply("404", "Not Found");
>>> break;
>>> };
>>> };
>>> append_hf("P-hint: usrloc applied\r\n");
>>> route(1);
>>>}
>>>
>>>route[1]
>>>{
>>> # !! Nathelper
>>> if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" &&
>>>!search("^Route:")){
>>> sl_send_reply("479", "We don't forward to private IP addresses");
>>> break;
>>> };
>>>
>>> # if client or server know to be behind a NAT, enable relay
>>> if (isflagset(6)) {
>>> force_rtp_proxy();
>>> };
>>>
>>> # NAT processing of replies; apply to all transactions (for example,
>>> # re-INVITEs from public to private UA are hard to identify as
>>> # NATed at the moment of request processing); look at replies
>>> t_on_reply("1");
>>>
>>> # send it out now; use stateful forwarding as it works reliably
>>> # even for UDP2TCP
>>> if (!t_relay()) {
>>> sl_reply_error();
>>> };
>>>}
>>>
>>># !! Nathelper
>>>onreply_route[1] {
>>> # NATed transaction ?
>>> if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
>>> fix_nated_contact();
>>> if (!search("^Content-Length:\ 0")) {
>>> force_rtp_proxy();
>>> };
>>> # otherwise, is it a transaction behind a NAT and we did not
>>> # know at time of request processing ? (RFC1918 contacts)
>>> } else if (nat_uac_test("1")) {
>>> fix_nated_contact();
>>> };
>>>}
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Serusers mailing list
>>>serusers(a)lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
Hi all:
Actually, I already posted this kind of question, but once again: can
I configure SER to leave custom headers in responses, because SER
seems to strip them off. The problem is that my custom headers are not
the same all the time. For instance,
X-Header: blah <random value>
This <random value> is always changing, that's why I cannot use
append_hf() function. Can I somehow make SER leave custom headers
untouched?
