Hello,
I've found the following issue:
When my gateway (it has a public IP address) sends an Invite to SER over a
TCP connection, the function client_nat_test(2) always returns true, even
though the VIA HF ahs the gateway public IP address. Any idea of why it is
doing so?
Does it have to do with port comparisson?
I tried to fix it using sip_asymmetrics file, but it didn't work. Any help
on this file syntax?
Thank you very much in advance
Hernán
Hi everyone,
Thanks for your comments.. i had a working openser now thanks and am
having registrations working..
Will post my problems if i had any while going through...
thanks
krishna
Hello everyone,
I must use SER as a proxy server to send every request to SipXchange (except
the MESSAGE request that will be handled by SER)
Can I get some help on this?, Is there any example I could use as a
reference?.
The user must be registered in SipXchange (in SER it would be optional)
If the request is "MESSAGE" then SER will handle the request.
This is what I have done
if (!method=="MESSAGE") {
xlog("L_INFO","Foward process\n");
forward(SipXchangeServer,SipXchangeServerPort);
break;
}
But I think something is missing,
Kat.
Hi,
I use ser 0.10.99+cvs20050428.
When I use replace("foo","bar") in ser.cfg, is it supposed to replace
all occurences
of "foo" in the headers/body of the SIP message?
It seems that it only replace the first occurence.
Moreover, when I write :
replace("foo","bar");
replace("foo","bar");
in my ser.cfg, it replace "foo" with "barbar".
B.R.
Xavier.
Hi everybody,
we are trying to collect the items to be included in the roadmap to the
next release. I have written a draft with the ideas discussed on the
mailing list, the items which were not accomplished in v1.0.0 and a few
more. There is no weight attached, and the presence in the roadmap does
not imply that the feature will be for sure implemented until the next
release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a
general rule, the features to be implemented must follow the standard,
if they are related directly to SIP, or they must have a clear and
common usage in real cases.
Cheers,
Daniel
Draft of the roadmap to OpenSERv1.1.0
-------------------------------------
OpenSER core:
- generic communication interface which must offer an abstract layer between
core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less exposed
to often changes
- better error reporting and handling
- pseudo-variables to be introduced in different modules
- security checks of destination addess (white/black lists)
- memory defragmentation
- tcp enhancements
- OpenSER command line interface (terminal)
OpenSER modules:
[acc]
- possibility to disable values from db_fmt
[avpops]
- more coherent format of the parameters (=>to be used the one
from pseudo-variables)
- ability to take the name of the AVP to be loaded from the value
of another AVP
- global avps - avps to be stored during run time, shared between processes
- local avps - avps to be stored locally, specific per script, not per
transaction
[cpl-c]
- possibility to configure table and columns' names
- import registrar paramters insted of redefine
[dbtext]
- replace support
- reload support
[dispatcher]
- serial forking when selected destination fails
- database support
[enum]
[-] - parallel/serial forking based on order and preference fields
[postgres]
- connection pool
- shift to memory manager used by openser
[tm]
- unification of t_relay_to_*() in a form of t_relay_to("proto:host:port")
[uac]
- qop authentication support
- proper CSeq value after authentication challenge
[usrloc]
- better handling of the natted contacts, to uniquely identify a contact
- cacheless usrloc
- path support for registrations
- sip instance support
- possibility to attach to a contact a set of values (similar to log_extra
in acc)
Hi folks,
I want my record route to be FQDN(domain name) instead of
ip address, so i tried using record_route_preset("mysip.test"). now
my problem is when i do this it also appends my name rkunal(a)mysip.test
to the record route field. Is there any way of configuring openser to
send FQDN in record route instead of ip address and I don't want
username there.
Regards,
Ranveer.
Hi,
When an INVITE request is incoming, I need to rewrite VIA Header Field,
Contact Header Field, (c=) field in SDP message core and (o=) field in
SDP message core too with IP public adress of UAC. Those are needed by
my SIP Server before SER Proxy forward the request to him.
I got some success with rewriting Contact Header File by using
fix_nated_contact() function and (c=) field with fix_nated_sdp("1")
function. But I don't succeed at all in rewriting (o=) field and
partially for VIA Header Field.
To do so, I tried to use the following function :
fix_nated_sdp("8"); No Result :(
forcerport(); It seems to add real IP public adress and
port in VIA header field but it's
not rewriting IP private adress
So, finally is it the good way to do this thing or is there something
wrong with my behaviour ?
Thanks,
HI Raymond,
I think was already mentioned in usrloc section as "cacheless usrloc" -
integrating this into usrloc will be a more elegant way to do it than
having another module.
regards,
bogdan
Raymond Chen wrote:
>How about usrloc-cl?
>
>Ray
>
>-----Original Message-----
>From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf
>Of Klaus Darilion
>Sent: 2005年11月7日 18:22
>To: daniel(a)voice-system.ro
>Cc: devel(a)openser.org; users(a)openser.org
>Subject: [Users] Re: [Devel] roadmap to v1.1.0
>
>Daniel-Constantin Mierla wrote:
>
>
>>- generic communication interface which must offer an abstract layer
>>
>>
>between
>
>
>> core/modules and transports (e.g., fifo, unix sockets)
>>- move the code of the implemented trasports as module
>>- NAPTR lookup
>>
>>
>
>with failover to next server/protocol? interpret ICMP error messages
>
>
>
>>- TLS multi-domain support
>>- TLS configuration values to be set via a module, to keep core less
>>
>>
>exposed
>
>I will write a separe emails for my TLS ideas :-)
>
>
>
>>- security checks of destination addess (white/black lists)
>>
>>
>
>maybe not only based on IP address, but IP address, port and protocol
>(which may be also * for all ports/protocols)
>
>
>
>>[enum]
>>[-] - parallel/serial forking based on order and preference fields
>>
>>
>
>isn't this already possible using load_gw, next_gw?
>
>
>
>>[postgres]
>>- connection pool
>>- shift to memory manager used by openser
>>
>>
>
>there was a big patch by jan for ser - maybe we can use this patch.
>
>klaus
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
Great!
Bogdan, you are genius! I'll try it.
Thank you very much!
Leonid
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
Sent: Thursday, November 10, 2005 17:05
To: Leonid Fainshtein
Cc: users(a)openser.org
Subject: Re: [Users] Routing to NATed gateways
if you want to try the next gateway if lookup() fails, you may try to
simulate loops by recursive call of the same route block.
regards,
bogdan
Leonid Fainshtein wrote:
>Hi Bogdan,
>Yes, it does. Please pay attention that the called number must be
>restored in branch_route[].
>Also, I still don't know what to do if lookup() fails (the gateway is
>temporary down and therefore is not registered...) Any idea? Is it
>planned to add loops possibility to script language?
>
>Best regards,
>Leonid
>
>-----Original Message-----
>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>Sent: Thursday, November 10, 2005 15:36
>To: Leonid Fainshtein
>Cc: users(a)openser.org
>Subject: Re: [Users] Routing to NATed gateways
>
>Hi Leonid,
>
>does the logic solved your problem? on a first view, the script look
ok.
>regarding the failure of lookup(); you can stick to sending an error
>reply or you can try the next gateway provided by LCR.
>
>regards,
>bogdan
>
>Leonid Fainshtein wrote:
>
>
>
>>In other words, the simplified configuration may be as the following:
>>
>> # Save original user name (the called phone number).
>> avp_printf("$orig_called_num", "$rU");
>> if (load_gws())
>> {
>> if (next_gw())
>> {
>> if (lookup("location"))
>> {
>> avp_pushto("$ruri/username", "$orig_called_num");
>> t_on_failure("2");
>> route(x); # NAT and other usual staff there
>> exit;
>> }
>> else
>> {
>> xlog("L_INFO", "I have to think what to do in this
>>situation.\n");
>> sl_send_reply("404", "User Not Found");
>> }
>> }
>> }
>>
>>failure_route[2]
>>{
>> if (method=="INVITE" && t_check_status("408|500|503"))
>> {
>> if (!next_gw())
>> {
>> t_reply("503", "Service not available, no more gateways");
>> }
>> else
>> {
>> if (!lookup("location"))
>> {
>> xlog("L_INFO", "I have to think what to do in this
>>situation.\n");
>> t_reply("503", "Service not available, no more
>>gateways");
>> exit;
>> };
>> t_on_failure("2");
>> t_on_branch("2");
>> t_relay();
>> }
>> }
>>}
>>
>>branch_route[2]
>>{
>> avp_pushto("$ruri/username", "$orig_called_num");
>>}
>>
>>Am I correct? Actually I don't know what to do if one of the gateways
>>is off-line (lookup() failed).
>>
>>Best regards,
>>Leonid Fainshtein
>>-----Original Message-----
>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>>Sent: Tuesday, November 08, 2005 5:30 PM
>>To: Leonid Fainshtein
>>Cc: users(a)openser.org
>>Subject: Re: [Users] Routing to NATed gateways
>>
>>Hi Leonid,
>>
>>the scenario you are probing might be already doable. Set in the LCR
>>table some IP addresses which will be used as aliases: private
>>addresses in 10.10.x.x class for example. Then register this IPs in
>>usrloc pointing to the real GWs address.
>>So you can do lcr (next_gw) and then lookup.
>>
>>for this to work, lcr must operate on RURI and not on DST_URI (not
>>sure
>>
>>
>
>
>
>>how exactly is working).
>>
>>regards,
>>bogdan
>>
>>Leonid Fainshtein wrote:
>>
>>
>>
>>
>>
>>>Hi,
>>>I'd like to use OpenSER for routing calls to NATed gateways. I also
>>>want to support the LCR feature. Unfortunately, the current LCR
>>>module
>>>
>>>
>
>
>
>>>doesn't support NAT. I mean that the gateway IP addresses must be
>>>defined explicitly in the "gtw" table. Now I'm looking for a way to
>>>force OpenSer to use information from the "location" table.
>>>I want to write a module that will have the similar functionality
>>>like
>>>
>>>
>
>
>
>>>the current LCR module has but resolving procedure will be more
>>>complicated (not based on prefix and From only). The module should
>>>build avp list where each gateway will have symbolic user name. For
>>>example, g1, g2 etc. The gateways will also be registered on the
>>>proxy
>>>
>>>
>
>
>
>>>with those names. Then I think it will be possible to call
>>>lookup("location") after successful call the next_gtw() from the
>>>
>>>
>>>
>>>
>>script.
>>
>>
>>
>>
>>>Is it feasible? Is there another way to solve my problem?
>>>
>>>Thank you in advance,
>>>Leonid Fainshtein
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users(a)openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
