Re: [OpenSIPS-Users] load balancer
Thanks for the reply Bogdan-Andrei, I will give that a go and see if it helps :) thanks Matt On 19 January 2015 at 18:28, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Matt, In OpenSIPS you need to use the onreply route to get access to those 200 OK replies (from FreeSwitch). In there use fix_nated_sdp(2,FS_public_ip) to rewrite the IP in the SDP: http://www.opensips.org/html/docs/modules/1.11.x/nathelper.html#id293864 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com On 19.01.2015 17:54, Matt Broad wrote: Hi, I was looking for some guidance on using the load balancer in a NAT environment. I have the following setup (the IP addresses are made up but should give an indication): 1 x opensips server with load balancer module - IP 192.168.0.1 2 x freeswitch servers - IP 192.168.0.2 192.168.0.3 All 3 servers have seperate external IP address routing to their internal IP via our firewall: 217.0.0.1 routed to 192.168.0.1 (Opensips) 217.0.0.2 routed to 192.168.0.2 (FS1) 217.0.0.3 routed to 192.168.0.3 (FS2) I have the load_balancer table with the following details: id, | group_id, | dst_uri,| resources, | probe_mode, | description '1', | '1', | 'sip:192.168.0.2:5080', | 'pstn=10', | '2', | 'FS1' '2', | '1', | 'sip:192.168.0.3:5080', | 'vm=1', | '2', | 'FS2' The call flow is: SIP Provider -- 217.0.0.1 Opensips -- 192.168.0.2/3 The issue is, that when the 200 ok response is sent to the SIP provider, the Freeswitch server's internal IP is being sent in the SDP connection information (c). This causes the ACK response from the SIP Provider to fail to be sent correctly. With the calls routed directly to the FS servers (removing opensips from the flow), the calls work fine. Any help would be much appreciated :) thanks ___ Users mailing listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] TLS handshake failing
Hi, Diego! According to your logs, OpenSIPS was unable to receive any data because the client close the connection before sending any data. You should try to investigate this on the client's side. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 01/21/2015 06:07 PM, Diego Carvalho Domingos wrote: Hi all, I’m trying to set up opensips with TLS enabled. I followed the webnair to install opensips and the advanced tutorial about TLS. Everything seems to be configured correctly but when I try to register using TLS it fails. I tried both latest LTS version and the master version of opensips, Bria and Linphone softphones and the default and customized TLS certificates. For all tests I got this log: Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 262142 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: INFO:core:probe_max_sock_buff: using snd buffer of 255 kb Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:print_ip: tcpconn_new: new tcp connection to: 192.168.14.26 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tcpconn_new: on port 50853, type 3 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tls_tcpconn_init: entered: Creating a whole new ssl connection Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tls_tcpconn_init: looking up socket based TLS server domain [192.168.14.23:5061] Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tls_find_server_domain: virtual TLS server domain not found, Using default TLS server domain settings Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tls_tcpconn_init: found socket based TLS server domain [0.0.0.0:0] Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tls_tcpconn_init: Setting in ACCEPT mode (server) Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:tcpconn_add: hashes: 613, 3 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:handle_new_connect: new connection: 0x7f3aeafa9eb8 25 flags: 0002 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3318]: DBG:core:send2child: to tcp child 0 0(3314), 0x7f3aeafa9eb8 rw 1 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:handle_io: We have received conn 0x7f3aeafa9eb8 with rw 1 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:io_watch_add: io_watch_add op on 20 (0x84d120, 20, 2, 0x7f3aeafa9eb8,1), fd_no=1 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: Using the global ( per process ) buff Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tls_update_fd: New fd is 20 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: Using the global ( per process ) buff Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tls_update_fd: New fd is 20 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: INFO:core:tls_accept: New TLS connection from 192.168.14.26:50853 accepted Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tls_accept: new TLS connection from 192.168.14.26:50853 using TLSv1/SSLv3 AES256-SHA 256 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tls_accept: local socket: 192.168.14.23:5061 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: INFO:core:tls_accept: Client did not present a TLS certificate Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: INFO:core:tls_dump_cert_info: tls_accept: local TLS server certificate subject: /C=XY/ST=Some State/O=My Large Organization Name/OU=My Subunit of Large Organization/CN=somename.somewhere.com/emailAddress=r...@somename.somewhere.com, issuer: /CN=Your_NAME/ST=Your_STATE/C=CO/emailAddress=YOUR_EMAIL/O=YOUR_ORG_NAME Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tls_update_fd: New fd is 20 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: read= 0 bytes, parsed=0, state=0, error=1 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: last char=0x00, parsed msg=#012 Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: We didn't manage to read a full request. Back to child poll Jan 20 15:41:27 devmachine /usr/local/opensips/sbin/opensips[3314]: DBG:core:tcp_read_req: tcp_read_req end Jan 20 15:41:27 devmachine
Re: [OpenSIPS-Users] rtpproxy sends rtp from caller to callee before 200OK
Hi, Marco! From RTPProxy point of view, you can't differentiate between SIP replies, because for all of them you call the same function - rtpproxy_answer(). Now, if the client decides to send RTP for 183 (and indeed, I've seen this several times), there's not that much that you can do. Although it's kind of a hack, all I can think of is to not call rtpproxy_answer() for 180/183 and strip the body to prevent the client from sending RTP directly to the callee. I hope this works for you. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 01/21/2015 04:07 PM, Marco Hierl wrote: Dear all, first of all I need to apologize that I was not able to find information about this issue although I’m sure that I’m not the first one complaining! The caller is sending an INVITE via OpenSIPS and rtpproxy_offer() is executed, callee answers with REPLY 180 or REPLY 183 (with SDP) and rtpproxy_answer() is made. In this status it should be ok that the rtp stream from callee to caller is transferred via the rtpproxy (e.g. for announcements), but I can see that rtp stream from caller to callee is transferred too!!! This means that there can be a conversation without receiving the 200OK and what is the real problem: that means (at least for me) they can talk to each other without any charging !! A timer will stop the conversion after the a while, but this can take time. How can I overcome this problem? How can prevent RTP to be send to the callee before REPLY 200 is received? I can’t find any help in the RTPproxy protocol http://www.b2bua.org/wiki/RTPproxy/Protocol, nor in the rtpproxy module description in OpenSIPS. Thanks for your ideas, and best regards Marco ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Rtpproxy issue with serial forking
Hi, John! I guess you are only using rtpproxy when the caller is behind NAT. In this case, you don;t have to detele at all the rtpproxy session, simply call rtpproxy_answer() on all replies. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 01/21/2015 01:05 PM, John Nash wrote: I have used opensips+rtpproxy for years for simple scenarios but now I am trying to use it with serial forking. My flow is UA---Invite ---Opensips 1 Branch ---Media Server Session Progress- 2 Branch (0n failure message)-Some Gateway --Second session progress-- My issue is SIP UA receives two session progress messages with different ports from rtpproxy. UA should receive same port in both session progress ?? isnt it?.Where should I call rtpproxy_offer and rtpproxy_answer and delete for this to achieve? John ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpproxy sends rtp from caller to callee before 200OK
Hi Răzvan, Ok, thanks for your answer! Unfortunately we are offering „early media“ to our customers (call center, radio station, and other companies) and lots of them like to play a free-of-charge announcement in the beginning. But if we started to get cheated, maybe we need to go for this workaround. But apart from that: Mostly the SDP is NOT repeated in the 200OK. Can I call rtpproxy_answer() when receiving the 200OK anyway? Thanks and best regards Marco Von: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] Im Auftrag von Razvan Crainea Gesendet: Donnerstag, 22. Januar 2015 09:36 An: users@lists.opensips.org Betreff: Re: [OpenSIPS-Users] rtpproxy sends rtp from caller to callee before 200OK Hi, Marco! From RTPProxy point of view, you can't differentiate between SIP replies, because for all of them you call the same function - rtpproxy_answer(). Now, if the client decides to send RTP for 183 (and indeed, I've seen this several times), there's not that much that you can do. Although it's kind of a hack, all I can think of is to not call rtpproxy_answer() for 180/183 and strip the body to prevent the client from sending RTP directly to the callee. I hope this works for you. Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.comhttp://www.opensips-solutions.com On 01/21/2015 04:07 PM, Marco Hierl wrote: Dear all, first of all I need to apologize that I was not able to find information about this issue although I’m sure that I’m not the first one complaining! The caller is sending an INVITE via OpenSIPS and rtpproxy_offer() is executed, callee answers with REPLY 180 or REPLY 183 (with SDP) and rtpproxy_answer() is made. In this status it should be ok that the rtp stream from callee to caller is transferred via the rtpproxy (e.g. for announcements), but I can see that rtp stream from caller to callee is transferred too!!! This means that there can be a conversation without receiving the 200OK and what is the real problem: that means (at least for me) they can talk to each other without any charging !! A timer will stop the conversion after the a while, but this can take time. How can I overcome this problem? How can prevent RTP to be send to the callee before REPLY 200 is received? I can’t find any help in the RTPproxy protocol http://www.b2bua.org/wiki/RTPproxy/Protocol, nor in the rtpproxy module description in OpenSIPS. Thanks for your ideas, and best regards Marco ___ Users mailing list Users@lists.opensips.orgmailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rtpproxy sends rtp from caller to callee before 200OK
Hi Nick,
I reduced my config file to a minimum and made the easiest call flow:
A --- INVITE --- B
A --- REPLY 183 with SDP --- B
A bothway speech B
I’m using rtpproxy_offer in the main route, rtpproxy_answer in the
onreply_route. Below you can see the config file plus logs.
I need to mention, that the RTP stream from B to A is welcome for
announcements… it’s only the stream from A to B that is not ok in my eyes.
Thanks and best regards
Marco
route{
t_on_reply(standart);
xlog(L_INFO,REQUEST $rm tt=$tt ci=$ci);
if ($rm==INVITE) {
$ru=sip:+4940835097791@**toIP**;user=phone;
set_rtp_proxy_set(0);
rtpproxy_offer(frocii);
}
if ($rm==BYE)
unforce_rtp_proxy();
t_relay();
}
onreply_route[standart] {
xlog(L_INFO,REPLY $rs $rr $T_ruri (for $rm) tt=$tt ci=$ci);
if(has_body(application/sdp)) {
set_rtp_proxy_set(0);
rtpproxy_answer(frocii);
}
}
Jan 22 10:44:46 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29946]: REQUEST
INVITE tt=null ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Jan 22 10:44:46 sbc-dtag-hh rtpproxy[1793]: DBUG:handle_command: received
command 29946_10 UIIc8,101 NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
**fromIP** 20582 c447a326;1
Jan 22 10:44:46 sbc-dtag-hh rtpproxy[1793]: INFO:handle_command: new session
NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ, tag c447a326;1 requested, type
strong
Jan 22 10:44:46 sbc-dtag-hh rtpproxy[1793]: INFO:handle_command: new session on
a port 20354 created, tag c447a326;1
Jan 22 10:44:46 sbc-dtag-hh rtpproxy[1793]: INFO:handle_command: pre-filling
caller's address with **fromIP**:20582
Jan 22 10:44:46 sbc-dtag-hh rtpproxy[1793]: DBUG:doreply: sending reply
29946_10 20354 **myIP**#012
Jan 22 10:44:46 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29947]: REPLY 100
Giving a try sip:+4940835097791@**toIP**;user=phone (for INVITE) tt=null
ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Jan 22 10:44:47 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29948]: REPLY 183
Ringing sip:+4940835097791@**toIP**;user=phone (for INVITE)
tt=3630908687-402466 ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Jan 22 10:44:47 sbc-dtag-hh rtpproxy[1793]: DBUG:handle_command: received
command 29948_10 LIIc8,101 NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
**toIP** 20926 c447a326;1 3630908687-402466;1
Jan 22 10:44:47 sbc-dtag-hh rtpproxy[1793]: INFO:handle_command: lookup on
ports 20354/20182, session timer restarted
Jan 22 10:44:47 sbc-dtag-hh rtpproxy[1793]: INFO:handle_command: pre-filling
callee's address with **toIP**:20926
Jan 22 10:44:47 sbc-dtag-hh rtpproxy[1793]: DBUG:doreply: sending reply
29948_10 20182 **myIP**#012
Jan 22 10:44:54 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29950]: REQUEST
CANCEL tt=null ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Jan 22 10:44:54 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29951]: REPLY 487
Request Terminated sip:+4940835097791@**toIP**;user=phone (for INVITE)
tt=3630908687-402466 ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Jan 22 10:44:54 sbc-dtag-hh /usr/opensips/akt/sbin/opensips[29953]: REQUEST ACK
tt=3630908687-402466 ci=NDdhYjlhY2Y2NDM5NzJkNjM4NjgzZDIwZTljYTc4YTQ
Von: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org]
Im Auftrag von symack
Gesendet: Mittwoch, 21. Januar 2015 17:11
An: OpenSIPS users mailling list
Betreff: Re: [OpenSIPS-Users] rtpproxy sends rtp from caller to callee before
200OK
Can you please post where you are using rtpproxy_offer/_answer?
Nick from Toronto.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips with Private IP
Take a look at the listen parameter: http://www.opensips.org/Documentation/Script-CoreParameters#toc56 Regards, Ovidiu Sas On Thu, Jan 22, 2015 at 3:05 PM, bluerain frank21...@yahoo.com wrote: I am currently running Opensips using public IP (on NIC and also in config file). So is there a quick way I can convert that to private IP? e.g. maybe some parameter in the global section of the config file that I can do so that Opensip will use a public IP in all is SIP messages? This way, I can simply do port forwarding on my firwall to MAP a public IP on to the opensip's private IP. You probably ask me why, the reason is that we maybe moving to a firewall that no longer have a transparent DMZ capability and that all device behind it have to be NAT from private to public... sux... Thanks in advance! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-with-Private-IP-tp7595038.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] ACK never leaves opensips
I have a strange issue with an ACK that never leaves Opensips. It disappears. This is the ACK message incoming dumped with ngrep U publicIP1:32769 - publicIPOpenSIPS:5172 ACK sip:s@publicIP2:6050 SIP/2.0. Via: SIP/2.0/UDP 192.168.4.53:32769;branch=z9hG4bK-nt6kbhw2yq7b;rport. Route: sip:publicIPOpenSIPS:5172;lr;ftag=dwlhrdursy;vsf=. From: 103 sip:103@publicIPOpenSIPS:5172;tag=dwlhrdursy. To: sip:5002362@publicIPOpenSIPS:5172;user=phone;tag=as24f5fc71. Call-ID: 313432313936303531313339303433-apx44rudybcq. CSeq: 1 ACK. Max-Forwards: 70. User-Agent: snom710/8.7.5.13. Contact: sip:103@192.168.4.53:32769;line=a7hcmd7s;reg-id=1. Content-Length: 0. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] DIGEST AUTH with no uac_auth function(CSeq trouble workaround)
If someone interesting this is set of routes to make Digest authorization
manually(with no uac_auth)
I would be grateful if somebody optimizes this workaround or find security
troubles.
route[dispatch_out] {
#For testing, I used the dispatcher module
#You can create your own search method register data for proxy in this cfg
is «hardcoded» val $avp(registrant)=6
#Now I use gateway attributes in dr_gateways table
#Username and password and aor I get from registrant table
$avp(registrant)=6;
#dispatcher set 1001 is set contain proxy which need to auth
#lets go!
if(!ds_select_domain(1001,8)){
send_reply(404, No destination);
exit;
}
#clearing auth flag
resetflag(7);
#get auth data from registrant table
avp_db_query(select username, password, aor from registrant where
id=$avp(registrant),$avp(stored_username);$avp(stored_password);$avp(stored_aor));
#build new From-hdr with registrant data
uac_replace_from($avp(stored_username), $avp(stored_aor));
#build new To-hdr with registrant data
$avp(stored_to)=sip: + $(ru{uri.user}) + @ +
$(avp(stored_to){uri.host}) + : + $(ru{uri.port});
uac_replace_to($avp(stored_to));
t_on_failure(rtf_dispatch_out);
t_on_reply(auth_reply);
t_relay();
exit;
}
onreply_route[auth_reply] {
if ( t_check_status(401|407) ) {
#if is not first unauthorized - do nothing (see below)
if (isflagset(7)) {
return;
}
#special route to parce WWW-Atuh hdr
route(parse_digest);
} else if ( t_check_status(200) ) {
#special route to decrease cseq(see below)
route(dec_cseq);
}
}
route[parse_digest]{
#saving Auth HDR of 401/407 reply
$avp(stored_digest)=$hdr(WWW-Authenticate);
xlog(L_INFO, Route PARSE_DIGEST orig WWW-Authenticate header is
$hdr(WWW-Authenticate););
#some transformations for parse
avp_subst($avp(stored_digest), /, /;/g);
avp_subst($avp(stored_digest), /Digest //g);
avp_subst($avp(stored_digest), /\//g);
xlog(L_INFO, Route PARSE_DIGEST digest params is $avp(stored_digest));
#use script transformations to get values of HDR and save it in AVPs
$avp(stored_realm)=$(avp(stored_digest){param.value,realm});
$avp(stored_nonce)=$(avp(stored_digest){param.value,nonce});
if $(avp(stored_digest){param.exist,algorithm}) {
$avp(stored_algorithm)=$(avp(stored_digest){param.value,algorithm});
} else {
$avp(stored_algorithm)=MD5;
}
if $(avp(stored_digest){param.exist,qop}) {
$avp(stored_qop)=$(avp(stored_digest){param.value,qop});
} else {
$avp(stored_qop)=none;
}
xlog(L_INFO, Route PARSE_DIGEST digest algorithm is
$avp(stored_algorithm));
xlog(L_INFO, Route PARSE_DIGEST digest realm is $avp(stored_realm));
xlog(L_INFO, Route PARSE_DIGEST digest nonce is $avp(stored_nonce));
xlog(L_INFO, Route PARSE_DIGEST digest qop is $avp(stored_qop));
return;
}
#failure route - processing 401/407 error and send new invite with
Authorization HDR
failure_route[rtf_dispatch_out]{
xlog(L_INFO, DISPATCHER OUTBOUND FILED);
if ( t_check_status(401|407) ) {
if (isflagset(7)) {
#If its not first «unauthorized» - registration data is wrong
t_reply(503,Authentication failed);
exit;
}
#go to route wich append auth HDR
route(append_authorize);
#route which increase cseq
route(inc_cseq);
t_on_failure(rtf_dispatch_out);
t_relay();
exit;
}
if (t_was_cancelled()) {
exit;
}
#this is standard part of dispatcher failure route
xlog(L_INFO, IAM IN FAILURE ROUTE DISPATCH\n);
ds_mark_dst(p);
xlog(L_INFO, IAM SELECT NEW DESTINATION\n);
if (ds_next_domain()) {
$avp(final_reply_timeout) = 2;
t_on_failure(rtf_dispatch_out);
t_relay();
exit;
}
}
#this route to append Authorization HDR to second invite
route[append_authorize] {
xlog(L_INFO, Route APPEND_AUTHORIZE orig ruri is $ru);
#saving ruri for use it for build response
$avp(stored_ruri)=sip: + $(ru{uri.user}) + @ + $(ru{uri.host});
xlog(L_INFO, Route APPEND_AUTHORIZE parsed ruri is $avp(stored_ruri));
#calculate ha1
$avp(ha1)=$avp(stored_username) + : + $avp(stored_realm) + : +
$avp(stored_password);
xlog(L_INFO, Route APPEND_AUTHORIZE ha1 is $avp(ha1));
$avp(ha1)=$(avp(ha1){s.md5});
xlog(L_INFO, Route APPEND_AUTHORIZE ha1 is $avp(ha1));
#switch for different types of qop
switch($avp(stored_qop))
{
case none:
$avp(ha2)=$rm + : + $avp(stored_ruri);
xlog(L_INFO, Route APPEND_AUTHORIZE $rm ha2 is $avp(ha2));
$avp(ha2)=$(avp(ha2){s.md5});
xlog(L_INFO, Route APPEND_AUTHORIZE $rm ha2 is $avp(ha2));
$avp(auth_response)=$avp(ha1) + : +
Re: [OpenSIPS-Users] Opensips with Private IP
Ok! Thank you very much, so currently I have: listen=udp:99.99.99.1:5060 where my NIC card is actually 99.99.99.1 So now I can change my NIC card to 192.168.1.100 and then put in opensip config file as: listen=udp:192.168.1.100:5060 as 99.99.99.1:5060 And that I simply do 1 to 1 nat on the firewall to map 99.99.99.1 to 192.168.1.100 And that the SIP message it generate on the opensip (e.g. the record_route/Via header/blah) will all be 99.99.99.1 instead of 192.168.1.100? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-with-Private-IP-tp7595038p7595041.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opensips with Private IP
I am currently running Opensips using public IP (on NIC and also in config file). So is there a quick way I can convert that to private IP? e.g. maybe some parameter in the global section of the config file that I can do so that Opensip will use a public IP in all is SIP messages? This way, I can simply do port forwarding on my firwall to MAP a public IP on to the opensip's private IP. You probably ask me why, the reason is that we maybe moving to a firewall that no longer have a transparent DMZ capability and that all device behind it have to be NAT from private to public... sux... Thanks in advance! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-with-Private-IP-tp7595038.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
