Hello,
you can implement this with avpops module
(http://www.voice-system.ro/docs/avpops/). Functions of interest for you
are avp_write() and avp_pushto().
...
avp_write("1234", "s:client_n");
alias_db_lookup("dbaliases");
lookup("location);
avp_pushto("$ruri/username", "s:client_n");
t_relay();
...
For optimization reasons, you may consider replacing the name of avp
"s:client_n" to an integer id, e.g., "i:500" (faster operations).
Cheers,
Daniel
On 09/26/05 14:14, Nelson Silva wrote:
> Have been using openser for a couple of months and i run into a problem.
>
> Currently i'm using alias_db_lookup, location and t_relay to do the
> routing.
>
> Since many clients have many numbers, i need to to rewrite the contact
> to the right client. It's doing it but only for a client with one
> number. Need for clients with more numbers.
>
> This is what i want:
>
>
> $client_n = 1234
>
> alias_db_lookup("db_aliases"); -> client_number(a)provider.com
>
> location("location"); -> client_number@client_ip
>
> rewriteuser($client_n);
>
> t_relay();
>
> This is what i have:
>
> alias_db_lookup("dbaliases");
>
> lookup("location);
>
> t_relay();
>
>
>
> Anyone have this implemented?
>
>
> Nelson Silva
> -----------------
> email: nelson.silva(a)neuvex.com
> website: http://www.neuvex.com
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
hello,
in SDP body sent out by the proxy the original media IP address is still
present, the rtpproxy ip is added as a another line.
is this the correct behavior ? should I add some flags to remove the
original media IP ?
for the invite this does not happen, the c= field is REWRITTEN with the
ip received from the rtpproxy.
message received by openser:
============================================
v=0.
o=CiscoSystemsSIP-GW-UserAgent 4176 788 IN IP4 GW-IP-ADDRESS.
s=SIP Call.
c=IN IP4 GW-IP-ADDRESS.
t=0 0.
m=audio 17644 RTP/AVP 18.
c=IN IP4 GW-IP-ADDRESS.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=direction:passive.
============================================
message sent out by openser:
============================================
v=0.
o=CiscoSystemsSIP-GW-UserAgent 4176 788 IN IP4 GW-IP-ADDRESS.
s=SIP Call.
c=IN IP4 GW-IP-ADDRESS.
t=0 0.
m=audio 35784 RTP/AVP 18.
c=IN IP4 RTPPROXY-IP-ADDRESS.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=direction:passive.
a=nortpproxy:yes.
============================================
onreply_route block
============================================
if(status =~ "(183)|2[0-9][0-9]") {
if(!force_rtp_proxy()) {
log(3, "force_rtp_proxy FAILED");
};
};
============================================
thanks
Razvan Radu
Hi everybody, I have a "one way audio" problem. My enviroment is:
xx.xx.63.75/27 = SER
xx.xx.63.68/27 = Natbox (linux iptables masquerade)
xx.xx.70.2/25 = STUN server
xx.xx.63.78/27 = PAP1 linksys AOR 2000
10.1.1.233/24 = PAP2 linksys AOR 2001 (behind NATbox with stun enable)
I have no audio from PAP1 to PAP2 when the call is made from PAP1 to PAP2, but when the call is made from PAP2 to PAP1 it works correctly.
I see on the natbox that the RTP packet is droped with unreachable cause (icmp messages).
This is the trace (ngrep) for the call from PAP1 to PAP2 on external interface of the natbox, where I can see STUN packets and the number udp port that the PAP willl be use (16444 to 16447).
The problem is natbox use other port (1173). I don't know if this problem is on natbox or stun server or PAP.
Can you helpme?
Thanks!!
U xx.xx.63.75:5060 -> xx.xx.63.68:5060
INVITE sip:2001@xx.xx.63.68:5060 SIP/2.0..Record-Route: <sip:xx.xx.63.75;ftag=d1ccd3db9e31eb1fo0;lr=on>..Via: SIP/2.0/UDP
xx.xx.63.75;branch=z9hG4bK52fb.41985863.0..Via: SIP/2.0/UDP xx.xx.63.78:5060;branch=z9hG4bK-57b1577f..From: 2000 <sip:5
890000(a)xx.xx.63.75>;tag=d1ccd3db9e31eb1fo0..To: <sip:2001@xx.xx.63.75>..Call-ID: d6e2df8b-5193d32f@xx.xx.63.78..CSeq: 101
INVITE..Max-Forwards: 16..Contact: 2000 <sip:2000@xx.xx.63.78:5060>..Expires: 240..User-Agent: Linksys/PAP2-2.0.10(L
Sc)..Content-Length: 420..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: app
lication/sdp....v=0..o=- 29375 29375 IN IP4 xx.xx.63.78..s=-..c=IN IP4 xx.xx.63.78..t=0 0..m=audio 16472 RTP/AVP 18 0 2 4 8 9
6 97 98 100 101..a=rtpmap:18 G729a/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:2 G726-32/8000..a=rtpmap:4 G723/8000..a=rtpmap:8 PCMA/8
000..a=rtpmap:96 G726-40/8000..a=rtpmap:97 G726-24/8000..a=rtpmap:98 G726-16/8000..a=rtpmap:100 NSE/8000..a=rtpmap:101 telephon
e-event/8000..a=fmtp:101 0-15..a=ptime:30..a=sendrecv..
#
U xx.xx.63.68:5060 -> xx.xx.63.75:5060
SIP/2.0 100 Trying..To: <sip:2001@xx.xx.63.75>..From: 2000 <sip:2000@xx.xx.63.75>;tag=d1ccd3db9e31eb1fo0..Call-ID
: d6e2df8b-5193d32f@xx.xx.63.78..CSeq: 101 INVITE..Via: SIP/2.0/UDP xx.xx.63.75;branch=z9hG4bK52fb.41985863.0..Via: SIP/2.0/U
DP xx.xx.63.78:5060;branch=z9hG4bK-57b1577f..Record-Route: <sip:xx.xx.63.75;ftag=d1ccd3db9e31eb1fo0;lr=on>..Server: Linksys/P
AP2-2.0.10(LSc)..Content-Length: 0....
#
U xx.xx.63.68:5060 -> xx.xx.70.2:3478
.....*f..*f..*f..*f.
#
U xx.xx.63.68:16444 -> xx.xx.70.2:3478
.....OB..OB..OB..OB.
#
U xx.xx.63.68:16445 -> xx.xx.70.2:3478
....................
#
U xx.xx.63.68:16446 -> xx.xx.70.2:3478
.......&...&...&...&
#
U xx.xx.63.68:16447 -> xx.xx.70.2:3478
....#...#...#...#...
#
U xx.xx.70.2:3478 -> xx.xx.63.68:16447
...$#...#...#...#.........@?.+?D.........+F..........+F.
#
U xx.xx.63.68:5060 -> xx.xx.70.2:3478
.....*f..*f..*f..*f.
#
U xx.xx.63.68:16444 -> xx.xx.70.2:3478
.....OB..OB..OB..OB.
#
U xx.xx.70.2:3478 -> xx.xx.63.68:5060
...$.*f..*f..*f..*f..........+?D.........+F..........+F.
#
U xx.xx.63.68:16445 -> xx.xx.70.2:3478
....................
#
U xx.xx.63.68:16446 -> xx.xx.70.2:3478
.......&...&...&...&
#
U xx.xx.70.2:3478 -> xx.xx.63.68:16444
...$.OB..OB..OB..OB.......@<.+?D.........+F..........+F.
#
U xx.xx.70.2:3478 -> xx.xx.63.68:16446
...$...&...&...&...&......@>.+?D.........+F..........+F.
#
U xx.xx.63.68:5060 -> xx.xx.63.75:5060
SIP/2.0 180 Ringing..To: <sip:2001@xx.xx.63.75>;tag=156298945b7d27i0..From: 2000 <sip:2000@xx.xx.63.75>;tag=d1ccd
3db9e31eb1fo0..Call-ID: d6e2df8b-5193d32f@xx.xx.63.78..CSeq: 101 INVITE..Via: SIP/2.0/UDP xx.xx.63.75;branch=z9hG4bK52fb.4198
5863.0..Via: SIP/2.0/UDP xx.xx.63.78:5060;branch=z9hG4bK-57b1577f..Record-Route: <sip:xx.xx.63.75;ftag=d1ccd3db9e31eb1fo0;lr=
on>..Server: Linksys/PAP2-2.0.10(LSc)..Content-Length: 0....
#
U xx.xx.70.2:3478 -> xx.xx.63.68:16444
...$.OB..OB..OB..OB.......@<.+?D.........+F..........+F.
#
U xx.xx.63.68:5060 -> xx.xx.63.75:5060
SIP/2.0 200 OK..To: <sip:2001@xx.xx.63.75>;tag=156298945b7d27i0..From: 2000 <sip:2000@xx.xx.63.75>;tag=d1ccd3db9e
31eb1fo0..Call-ID: d6e2df8b-5193d32f@xx.xx.63.78..CSeq: 101 INVITE..Via: SIP/2.0/UDP xx.xx.63.75;branch=z9hG4bK52fb.41985863.
0..Via: SIP/2.0/UDP xx.xx.63.78:5060;branch=z9hG4bK-57b1577f..Record-Route: <sip:xx.xx.63.75;ftag=d1ccd3db9e31eb1fo0;lr=on>..
Contact: 2001 <sip:2001@xx.xx.63.68:5060>..Server: Linksys/PAP2-2.0.10(LSc)..Content-Length: 236..Allow: ACK, BYE, CANCE
L, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura..Content-Type: application/sdp....v=0..o=- 659101 659101 IN IP4 20
0.43.63.68..s=-..c=IN IP4 xx.xx.63.68..t=0 0..m=audio 16444 RTP/AVP 18 100 101..a=rtpmap:18 G729a/8000..a=rtpmap:100 NSE/8000.
.a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..a=ptime:30..a=sendrecv..
#
U xx.xx.63.75:5060 -> xx.xx.63.68:5060
ACK sip:2001@xx.xx.63.68:5060 SIP/2.0..Record-Route: <sip:xx.xx.63.75;ftag=d1ccd3db9e31eb1fo0;lr=on>..Via: SIP/2.0/UDP 200
.43.63.75;branch=0..Via: SIP/2.0/UDP xx.xx.63.78:5060;branch=z9hG4bK-5a4c9c84..From: 2000 <sip:2000@xx.xx.63.75>;tag
=d1ccd3db9e31eb1fo0..To: <sip:2001@xx.xx.63.75>;tag=156298945b7d27i0..Call-ID: d6e2df8b-5193d32f@xx.xx.63.78..CSeq: 101 AC
K..Max-Forwards: 16..Contact: 2000 <sip:2000@xx.xx.63.78:5060>..User-Agent: Linksys/PAP2-2.0.10(LSc)..Content-Length:
0....
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8...-..L....@.....tF.34..V.|B..n..a.k(.R
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2....8...-..L....@.....tF.34..V.|B..n..a.k(.R
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!o..vy.F.!...|...&.T.BP..Z..n...:.3..d..
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8......L... .s..._exR..Kc.....+.O<.RZ.O{
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2....8......L... .s..._exR..Kc.....+.O<.RZ.O{
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!p..wi.F.!.'D.F...K....@C..e.Z.[~P...Et,
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8.../..L......@H..._...,[.P...rU.A..P...
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2....8.../..L......@H..._...,[.P...rU.A..P...
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!q..xY.F.!....Mf.....Fu.Q.....~.}....v..
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8...0..L..\.~..h..+..|S.C.M..~6W}....6sR
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2....8...0..L..\.~..h..+..|S.C.M..~6W}....6sR
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!r..yI.F.!x|..Eo..._.1...;..GRz....*.x.Z
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8...1..L..x.....n."..6.v....S.D.......S.
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2.!..8...1..L..x.....n."..6.v....S.D.......S.
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!s..z9.F.!0...ooPE..F. .5...E....v......
#
U xx.xx.63.78:16472 -> xx.xx.63.68:16444
..8...2..L..z....+.b..r?...r....|..$.x...^
#
I xx.xx.63.68 -> xx.xx.63.78 3:3
....E..F.........+?N.+?D@X@<.2....8...2..L..z....+.b..r?...r....|..$.x...^
#
U xx.xx.63.68:1173 -> xx.xx.63.78:16472
..!t..{).F.!.o...{..r..3....F.$.r.. V..by.
#
Hello,
I'm using Ser in combination with Mediaproxy. The situation is as
follow: My SER has a private ip address (10.254.254.1), and my UAs also
have private IP addresses, they can all see SER, and SER can see the
UAs. Next, our company has a Voice Interconnect with a telco. (it's
using Cirpack as softswitch). SER can see Cirpack and vice versa.
However, the UAs cannot see the Cirpack. So I want to use Mediaproxy to
overcome this. I can make outbound calls, but when calling inbound, I
sometimes have one-way-voice of no voice at all. I think the problem is
related to Cirpack, but I have a question thouh:
- When calling mediaproxy, how does mediaproxy decide which one is the
caller and which one is the called? Is this based on the From and To
header? Because, if i call from PSTN -> SIP, i get serveral thousands
(!) of messages saying that the called person signed in (no caller signs
in in mediaproxy). This could be due to the fact that the from and to
headers are incorrect.
My ser.cfg is the one from onsip.org (pstn with nat). I can post
configs/traces if someone needs them!
Regards,
Ronald
It looks like "allow_trusted" was removed from the permission module in
CVS HEAD.
Can someone confirm this? Or was it moved to a different module?
Bjorn
Hi all,
I've been working with SER + Mysql for over a month without any problems, yet
all these (including the DB) are installed on the same server (LocalHost). I'm
currently trying to centralize and securing all Data, thus would like to move
all data to a centralized DB offsite.
Now, I have SER DB migrated to this new DB server, and have changed the SER.cfg
so that all mysql related loadmodule would be pointing to the proper server (ip
address) instead of localhost. This is where the nightmare begins.
The SER server can not seem to be connecting to the Mysql Server properly. Thus
it took me over 3 days to debug and see if there were any auth problems from a
remote site to the Mysql server. Apparently, remote auth & connect to the DB
is working perfectly since I've installed other application which can connect
to this DB server.
So I've checked with the SER log + ngrep, of which to my amazement that the SER
never sent any signals to the DB server. As soon as I moved the DB back to
localhost, everything worked! My question is, is there something I need to
configure in the mysql module so that it can work with a remote server????
Any insight is greatly appreciated!!!
Best Regards,
Samuel Yeung
The best solution is to use two different tables for start and stop
accounting.
Have a look in the sql.conf file in FreeRADIUS
Problem is that SER replaces the Username in the stop-message, with
whoever hung up...
Therefore the default queries in FreeRADIUS won't find the corresponding
record.
To get the CDR just join the two tables on AcctSessionId.
I have experienced problems joining on the AcctSessionId in MySQL
versions prior to 4.1, for some reason.
Bjorn