date:20130509

Re: [OpenSIPS-Users] Registrar not saving received from Path header

2013-05-09 Thread Bogdan-Andrei Iancu

Hi Nathaniel,

Could you please apply the attached patch to the registrar opensips - it
contains some more debugs in regards to saving the path array.

Check if during the save("location","p1") you get ant logs with "xXx"
and post them here.

What db_mode are you using for usrloc ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/05/2013 07:49 PM, Nathaniel L Keeling III wrote:
> Hello,
>
> On P1, I am using the add_path_received() function which is adding the
> Path header. Actually, it adds 2 Path headers since the request comes
> in using TCP but is forwarded using UDP. On the REGISTER, I use the
> save("location","p0") function but the path header is not saved in the
> PATH column of the location table. I have attached a snippet from the
> REGISTER's log and it looks like the insert into the table in placing
> NULL even though the PATH headers were successfully parsed earlier.
> Also, will the lookup() function use this column to locate the
> subscriber for an INVITE request?
>
> Thanks
>
> Nathaniel
>
>
> On 5/5/13 5:55 AM, Bogdan-Andrei Iancu wrote:
>> The registrar server will store the PATH hdr in the PATH column of
>> the "location" table.
>>
>> If P1 adds a PATH hdr to a REGISTER that is saved on REGISTRAR via
>> save(location, p0) .
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/04/2013 08:11 PM, Nathaniel L Keeling III wrote:
>>> I am currently using version 1.8.2 of opensips. I am using this code
>>> on the registrar server, save("location","p0v"), when the user is
>>> authenticated. The user is behind a firewall. The register request
>>> is first sent to the sip proxy which forwards it to the registrar
>>> server. The sip proxy adds the Path header with the source IP/Port
>>> of the Register request. From the documentation it sounds like the
>>> save() function should take the "received" parameter from the Path
>>> header and store it in the "received" column of the location table.
>>> When I look at the location table it contains the IP address and
>>> port of the SIP proxy so when I try to locate the user, they are
>>> being sent to the SIP proxy and the call fails. Is my understanding
>>> correct? What is the best approach for this, UAC --> firewall -->
>>> P1  --> REG.
>>>
>>> Thanks
>>>
>>> Nathaniel
>>>
>>> On 5/4/13 4:26 AM, Bogdan-Andrei Iancu wrote:
 Hello Nathaniel,

 See
 http://www.opensips.org/html/docs/modules/1.9.x/registrar.html#id248705
 - this controls the PATH support in REGISTRAR module.

 Regards,

 Bogdan-Andrei Iancu
 OpenSIPS Founder and Developer
 http://www.opensips-solutions.com


 On 05/04/2013 01:31 AM, Nathaniel L Keeling III wrote:
> Hello,
>
> I sent an earlier post concerning NATed registrations not being
> able to locate from the lookup() function when the registration
> request is sent from a opensips proxy server to an opensips
> registration server and from my research it looks like I should be
> using the Path header with the received parameter set. Doing this,
> the Register request is sent to the registrar proxy server with a
> Path header, the user is successfully authorized and saved in the
> location table but when I look at the location table entry, the
> received column either does not contain a value or it contains the
> wrong value. Here is the Register request sent from the proxy to
> the registrar server and the output from the location table.
>
> REGISTER sip:my-sip-domain.com;transport=tcp SIP/2.0.
> Call-ID: 541d070a84f74ca6f61f68732d063d35@0:0:0:0:0:0:0:0.
> CSeq: 2 REGISTER.
> From: "Nathaniel L Keeling III"
> ;tag=cbe17bd3.
> To: "Nathaniel L Keeling III" .
> Max-Forwards: 68.
> User-Agent: Jitsi2.0.4506.10553Mac OS X.
> Expires: 600.
> Contact: "Nathaniel L Keeling III"
> ;expires=600.
> Via: SIP/2.0/UDP
> xxx.xxx.110.38:5060;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1;i=04.
> Via: SIP/2.0/TCP
> 192.168.43.237:65457;received=208.54.44.148;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1.
> Authorization: Digest
> username="nkeeling3",realm="mydomain2.com",nonce="5184345b003b08c40d29a091fb53e6cb83c3961c1dbb",uri="sip:my-sip-domain.com;transport=tcp",response="987edb51f504ff56c7ba840d594c4bb1".
> Content-Length: 0.
> Path:
> .
> Path: .
>
>
>   id  | username  |domain |
> contact | received |
> path |   expires   | q | callid  |
> cseq | last_modified| flags | cflags | user_agent |
> socket  | methods | sip_instance
> --+---+---++-+--+

Re: [OpenSIPS-Users] Tuning for maximum number of TCP connections

2013-05-09 Thread Bogdan-Andrei Iancu



  
  
Hi Gavin,
  
  I see, no registrationAs an exercise, increase the
  tcp_connection_lifetime to 7200 (2 h), just to rule out the
  possibility of connections timing out.

  Are you saying that running a constant load of 50K TCP conns (for
  long time), does not result in any TCP error ?
  
  Now, regarding the processes, yes, it looks like the TCP main is
  the one with extra load - this process is responsible for managing
  the TCP connection - it is not accepting, reading, writing
  anything, but is detecting events on the TCP sockets and dispatch
  them to the TCP worker processes.
  
  Do you have a test suite or so to help in generating the traffic
  corresponding to 50K clients ?
  
  Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 04/30/2013 10:35 PM, Gavin Murphy wrote:

  
  The tcp_persistent_flag isn't set as
that appears to be for the registrar module, which we aren't
using. We're passing REGISTERs through to our own registrar.

Here is a snapshot of a test currently being run with 50K
concurrent TCP "clients" (doesn't show all of the opensips
processes). This level of traffic is not generating any
TCP-related errors in opensips.

 3411 rcsuser   20   0 6516m 3.1g 3.1g R   54 39.5  73:14.06
opensips
 3376 rcsuser   20   0 6516m 221m 219m S   11  2.8  14:07.50
opensips
 3375 rcsuser   20   0 6516m 221m 219m S   10  2.8  13:57.23
opensips
 3373 rcsuser   20   0 6516m 221m 219m S    9  2.8  14:10.93
opensips
 3374 rcsuser   20   0 6516m 221m 219m S    9  2.8  14:04.26
opensips
 3377 rcsuser   20   0 6516m 1608  200 S    0  0.0   0:01.44
opensips
 3379 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.52
opensips
 3380 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.65
opensips
 3381 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.38
opensips
 3382 rcsuser   20   0 6516m  47m  39m S    0  0.6   0:14.56
opensips
 3385 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.52
opensips
 3386 rcsuser   20   0 6516m  49m  41m S    0  0.6   0:14.67
opensips
 3390 rcsuser   20   0 6516m  49m  41m S    0  0.6   0:14.50
opensips
 3394 rcsuser   20   0 6516m  47m  39m S    0  0.6   0:14.42
opensips
 3395 rcsuser   20   0 6516m  47m  39m S    0  0.6   0:14.44
opensips
 3396 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.72
opensips
 3401 rcsuser   20   0 6516m  50m  42m S    0  0.6   0:14.72
opensips
 3402 rcsuser   20   0 6516m  50m  42m S    0  0.6   0:14.75
opensips
 3403 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.78
opensips
 3404 rcsuser   20   0 6516m  48m  40m S    0  0.6   0:14.60
opensips
 3408 rcsuser   20   0 6516m  50m  42m S    0  0.6   0:14.49
opensips
 3409 rcsuser   20   0 6516m  50m  42m S    0  0.6   0:14.75
opensips
 3410 rcsuser   20   0 6516m  50m  42m S    0  0.6   0:14.61
opensips

And the results from the fifo command:

Process::  ID=0 PID=3367 Type=attendant
Process::  ID=1 PID=3368 Type=MI FIFO
Process::  ID=2 PID=3369 Type=SIP receiver udp:127.0.0.1:9050
Process::  ID=3 PID=3370 Type=SIP receiver udp:127.0.0.1:9050
Process::  ID=4 PID=3371 Type=SIP receiver udp:127.0.0.1:9050
Process::  ID=5 PID=3372 Type=SIP receiver udp:127.0.0.1:9050
Process::  ID=6 PID=3373 Type=SIP receiver
udp:192.168.38.175:9050
Process::  ID=7 PID=3374 Type=SIP receiver
udp:192.168.38.175:9050
Process::  ID=8 PID=3375 Type=SIP receiver
udp:192.168.38.175:9050
Process::  ID=9 PID=3376 Type=SIP receiver
udp:192.168.38.175:9050
Process::  ID=10 PID=3377 Type=time_keeper
Process::  ID=11 PID=3378 Type=timer
Process::  ID=12 PID=3379 Type=TCP receiver
Process::  ID=13 PID=3380 Type=TCP receiver
Process::  ID=14 PID=3381 Type=TCP receiver
Process::  ID=15 PID=3382 Type=TCP receiver
Process::  ID=16 PID=3383 Type=TCP receiver
Process::  ID=17 PID=3384 Type=TCP receiver
Process::  ID=18 PID=3385 Type=TCP receiver
Process::  ID=19 PID=3386 Type=TCP receiver
Process::  ID=20 PID=3387 Type=TCP receiver
Process::  ID=21 PID=3388 Type=TCP receiver
Process::  ID=22 PID=3389 Type=TCP receiver
Process::  ID=23 PID=3390 Type=TCP receiver
Process::  ID=24 PID=3391 Type=TCP receiver
Process::  ID=25 PID=3392 Type=TCP receiver
Process::  ID=26 PID=3393 T

[OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

2013-05-09 Thread Michele Pinassi

Hi all,

i have an OpenSIPS server with two interface, PUBLIC (xxx) and PRIVATE
(172.20.1.2). The PRIVATE interface works inside a LAN dedicated to
VoIP, with a MediaServer (172.20.1.5) and a Patton Gateway for PSTN
(172.20.1.4).

Users phone's can register on both interface and i use RTPProxy (in
bridging mode) to ensure that both side can talk togheter.

But something don't work as expected

Here's my OpenSIPS routing logic:

===
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}

if (msg:len >=  2048 ) {
sl_send_reply("513", "Message too big");
exit;
};

if(is_method("INVITE") && has_totag()) {
engage_rtp_proxy();
}

if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction fails
} else if (is_method("INVITE")) {
# even if in most of the cases is useless, do 
RR for
# re-INVITEs alos, as some buggy clients do 
change route set
# during the dialog.
record_route();
}
# route it out to whatever destination was set by 
loose_route()
# in $du (destination URI).
route(1);
} else {
/* uncomment the following lines if you want to enable 
presence */
if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") {
# in-dialog subscribe requests
route(2);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK; 
must be an ACK after
# a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ->
# ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}

#initial requests

# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}

t_check_trans();

# authenticate if from local subscriber (uncomment to enable auth)
# authenticate all initial non-REGISTER request that pretend to be
# generated by local subscriber (domain from FROM URI is local)
# if (!(method=="REGISTER") && from_uri==myself) /*no multidomain 
version*/
if (!(method=="REGISTER") && is_from_local())  /*multidomain version*/
{
if(!check_source_address("0")){
if (!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
exit;
}
if (!db_check_from()) {
sl_send_reply("403","Forbidden auth ID");
exit;
}

consume_credentials();
# caller authenticated
}
}

# preloaded route checking
if (loose_route()) {
xlog("L_ERR", "Attempt to route with preloaded Route's
[$fu/$tu/$ru/$ci]");
if (!is_method("ACK"))
sl_send_reply("403","Preload Route denied");
exit;
}

# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();

# account only INVITEs
if (is_method("INVITE")) {
setflag(1); # do accounting
}
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
}

if( is_method("PUBLISH|SUBSCRIBE")) {
route(2);
}

if (is_method("REGISTER"))
{
# authenticate the REGISTER requests (uncomment to enable auth)
if (!www_authorize("", "subscriber"))
{
www_challenge("", "0");

Re: [OpenSIPS-Users] one way audio in voip clients

2013-05-09 Thread Bogdan-Andrei Iancu

Hi,

So you are saying that all involved entities (caller, callee, opensips)
are sitting in same network where direct IP communication between all
parties is possible ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/06/2013 08:05 AM, sermj 2012 wrote:
> Sir,
> I am not using any firewall in our network but i am using NAT. But by
> disabling NAT also i didn't observe any change in connection.
>
> please advice
>
>
> On Sun, May 5, 2013 at 4:27 PM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hello,
>
> Are any of your end points registering from behind a NAT (in
> relation to OpenSIPS) ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/04/2013 02:18 PM, sermj 2012 wrote:
>> Iam new to opensips.i have installed successfully opensips on my pc.
>> i have registered two voip clients.
>> but only one way audio is working.
>>
>> please help me from this issue.
>>
>>
>>
>>
>>
>> ___
>> 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

[OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread qasimak...@gmail.com

Hi,

I am facing a problem when a client connects to opensips from NATed
network. I am using rtpproxy in bridging mode i.e. from publicnetwork to
private network. When i use fix_nated_sdp function from nathelper the local
IP address of the caller is replaced by its public IP but the problem
starts when i use engage_rtp_proxy instead of replacing server's public ip
to private it embeds private ip after the caller's publicIP like
X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and engage_rtp_proxy
with flag rie.

The question is am i using something wrong here or should it be counted as
a bug.

If you want some more clarification can draw a flow diagram also.

Regards,
Qasim
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] refer scenario - record-route header

2013-05-09 Thread Bogdan-Andrei Iancu

Hi Lazlo,

Good the problem was sorted out. May I ask what kind of misconfiguration
lead to a missing IP in RR hdr ? were you doing manual RR via
record_route_preset() ? or ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/07/2013 12:08 PM, Laszlo wrote:
> Hi Bogdan,
>
> There was no record_route before firing up b2b, just a logical mistake
> in the config.
>
> It is now sorted out, thanks!
>
>
> -Laszlo
>
>
> 2013/4/30 Bogdan-Andrei Iancu  >
>
> The bogus RR belongs to .170 which is the B2B - are you by mistake
> doing record_route before pushing the call into the b2b ? if so,
> this is wrong and take it out..
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 04/30/2013 01:09 PM, Laszlo wrote:
>> Hi Bogdan,
>>
>> Sorry for not explaining it well :)
>>
>>
>> this is my problem:
>>
>> U 2013/04/30 02:13:50.130487 xx.xx.xx.xx:5060
>>  -> yy.yy.yy.yy:5060
>> 
>> SIP/2.0 183 Session Progress.
>> Record-Route:
>> .
>> Record-Route: > 
>> ;r2=on;lr;ftag=as439eda7d;did=35.b69971a2>.
>>
>> it is the packet relayed to the calling party, see the first
>> record-route header, it's missing the host part.
>>
>> It is missing when I use the b2b refer scenario. The refer-to is
>> not processed in the trace, I'm just saying that the host part is
>> missing :)
>>
>>
>> when using the b2b top hiding scenario, the problem isn't present!
>>
>>
>> -Laszlo
>>
>>
>>
>>
>>
>> 2013/4/30 Bogdan-Andrei Iancu > >
>>
>> Hi Lazlo,
>>
>> I do not understand - the LB + b2b refer capture shows a call
>> going through the B2B and receiving a 503.there is no
>> REFER stuff there at all...
>>
>> Is there something I mis ?
>>
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 04/29/2013 04:09 PM, Laszlo wrote:
>>> Hi Bogdan,
>>>
>>> with the stock LB config:
>>> http://pastebin.com/xxx 
>>>
>>>
>>> with LB + b2b refer
>>> http://pastebin.com/xxx 
>>>
>>>
>>>
>>>
>>> 2013/4/29 Bogdan-Andrei Iancu >> >
>>>
>>> Hi Lazlo,
>>>
>>> Could you post somewhere the SIP capture of the call ?
>>> Just to be sure I correctly understand your scenario.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> On 04/29/2013 02:38 PM, Laszlo wrote:
 Hello,


 Just tried to play with the b2b refer scenario with
 opensips.
 The config is pretty much the default LB config from
 opensips.org , so nothing sexy in
 the conf, it works fine without the b2b stuff. LB
 destinations are reachable through the private ip of
 the server.

 if I use the b2b topology hiding scenario, it also work
 fine.
 when I use the refer scenario, things goes mad :)

 Sending this to the caller party (default LB config):

 U 2013/04/30 02:19:05.920262 opensips_public_ip:5060 ->
 caller_ip:5060

 SIP/2.0 183 Session Progress.

 Via: SIP/2.0/UDP
 
 caller_ip:5060;received=caller_ip;branch=z9hG4bK25704719;rport=5060.

 Record-Route:
 
 .

 
 Record-Route:.




 New call  with the refer settings applied:

 U 2013/04/30 02:13:50.130487 opensips_public_ip:5060 ->
 caller_ip:5060
 SIP/2.0 183 Session Progress.
 Record-Route:
 .
 Record-Route:
 
 .


 In the first record-route header, the host part is missing.

 The relevant lines from the syslog in this case:
 Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
 CRITICAL:core:lumps_len: lumps_len called with null
 send_sock
 Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
 CRITICAL:core:lump_check_opt: null send socket
 Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
 CRITICAL:core:lump_check_op

Re: [OpenSIPS-Users] one way audio in voip clients

2013-05-09 Thread Nick Khamis

Can you please describe your network. What are the ip addresses of the
OpenSIPS server, client A and client B. Further, can you provide a sip
capture using ngrep (http://wiki.freeswitch.org/wiki/Packet_Capture)
for a given call.

I too am new to OpenSIPS, however this book (Goncalves F.E. - Building
Telephony Systems with OpenSIPS 1.6) available free online brought me
up to par within a week. It's based on 1.6 and a lot has changed with
the latest stable, but the core concept still remains.

Kind Regards,

Nick.

On 5/9/13, Bogdan-Andrei Iancu  wrote:
> Hi,
>
> So you are saying that all involved entities (caller, callee, opensips)
> are sitting in same network where direct IP communication between all
> parties is possible ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/06/2013 08:05 AM, sermj 2012 wrote:
>> Sir,
>> I am not using any firewall in our network but i am using NAT. But by
>> disabling NAT also i didn't observe any change in connection.
>>
>> please advice
>>
>>
>> On Sun, May 5, 2013 at 4:27 PM, Bogdan-Andrei Iancu
>> mailto:bog...@opensips.org>> wrote:
>>
>> Hello,
>>
>> Are any of your end points registering from behind a NAT (in
>> relation to OpenSIPS) ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/04/2013 02:18 PM, sermj 2012 wrote:
>>> Iam new to opensips.i have installed successfully opensips on my pc.
>>> i have registered two voip clients.
>>> but only one way audio is working.
>>>
>>> please help me from this issue.
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] one way audio in voip clients

2013-05-09 Thread Nick Khamis

Sorry for the top post. Google client from hell...

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

2013-05-09 Thread Răzvan Crainea


Hi, Michele!

I noticed that you are using the engage_rtp_proxy() function, but it's 
behavior is undefined when using RTPProxy in bridge mode[1]. Therefore 
you should use manualy engage RTPProxy, using the rtpproxy_offer() 
rtpproxy_answer() functions and the 'I' and 'E' flags to determine the 
direction of the flow.


[1] http://www.opensips.org/html/docs/modules/1.9.x/rtpproxy.html#id292454

Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 05/09/2013 01:09 PM, Michele Pinassi wrote:

Hi all,

i have an OpenSIPS server with two interface, PUBLIC (xxx) and PRIVATE
(172.20.1.2). The PRIVATE interface works inside a LAN dedicated to
VoIP, with a MediaServer (172.20.1.5) and a Patton Gateway for PSTN
(172.20.1.4).

Users phone's can register on both interface and i use RTPProxy (in
bridging mode) to ensure that both side can talk togheter.

But something don't work as expected

Here's my OpenSIPS routing logic:

===
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}

if (msg:len >=  2048 ) {
sl_send_reply("513", "Message too big");
exit;
};

if(is_method("INVITE") && has_totag()) {
engage_rtp_proxy();
}

if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction fails
} else if (is_method("INVITE")) {
# even if in most of the cases is useless, do 
RR for
# re-INVITEs alos, as some buggy clients do 
change route set
# during the dialog.
record_route();
}
# route it out to whatever destination was set by 
loose_route()
# in $du (destination URI).
route(1);
} else {
/* uncomment the following lines if you want to enable 
presence */
if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") {
# in-dialog subscribe requests
route(2);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK; 
must be an ACK after
# a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ->
# ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}

#initial requests

# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}

t_check_trans();

# authenticate if from local subscriber (uncomment to enable auth)
# authenticate all initial non-REGISTER request that pretend to be
# generated by local subscriber (domain from FROM URI is local)
# if (!(method=="REGISTER") && from_uri==myself) /*no multidomain 
version*/
if (!(method=="REGISTER") && is_from_local())  /*multidomain version*/
{
if(!check_source_address("0")){
if (!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
exit;
}
if (!db_check_from()) {
sl_send_reply("403","Forbidden auth ID");
exit;
}

consume_credentials();
# caller authenticated
}
}

# preloaded route checking
if (loose_route()) {
xlog("L_ERR", "Attempt to route with preloaded Route's
[$fu/$tu/$ru/$ci]");
if (!is_method("ACK"))
sl_send_reply("403","Preload Route denied");
exit;
}

# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();

# account only INVITEs
if

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread Nick Khamis

It's not a bug, many of us here use RTP proxy in the same scenario.
Can you please provide a sip trace using ngrep
(http://wiki.freeswitch.org/wiki/Packet_Capture). Secondly, post the
relevant far end nat related scripting please.


Nick.

On 5/9/13, qasimak...@gmail.com  wrote:
> Hi,
>
> I am facing a problem when a client connects to opensips from NATed
> network. I am using rtpproxy in bridging mode i.e. from publicnetwork to
> private network. When i use fix_nated_sdp function from nathelper the local
> IP address of the caller is replaced by its public IP but the problem
> starts when i use engage_rtp_proxy instead of replacing server's public ip
> to private it embeds private ip after the caller's publicIP like
> X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and engage_rtp_proxy
> with flag rie.
>
> The question is am i using something wrong here or should it be counted as
> a bug.
>
> If you want some more clarification can draw a flow diagram also.
>
> Regards,
> Qasim
>

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

2013-05-09 Thread qasimak...@gmail.com

For engage_rtpproxy there are two flags that are used i.e. i for LAN
interface and E for WAN interface. you can use these two flags to specify
your direction of bridging. e.g. ie for LAN to WAN bridging and ei for WAN
to LAN bridging. Meanwhile look at this documentation for detailed flag
usage.

http://www.opensips.org/html/docs/modules/1.8.x/rtpproxy.html#id292744


Regards,
Qasim


On Thu, May 9, 2013 at 4:09 PM, Michele Pinassi wrote:

> Hi all,
>
> i have an OpenSIPS server with two interface, PUBLIC (xxx) and PRIVATE
> (172.20.1.2). The PRIVATE interface works inside a LAN dedicated to
> VoIP, with a MediaServer (172.20.1.5) and a Patton Gateway for PSTN
> (172.20.1.4).
>
> Users phone's can register on both interface and i use RTPProxy (in
> bridging mode) to ensure that both side can talk togheter.
>
> But something don't work as expected
>
> Here's my OpenSIPS routing logic:
>
> ===
> route{
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> exit;
> }
>
> if (msg:len >=  2048 ) {
> sl_send_reply("513", "Message too big");
> exit;
> };
>
> if(is_method("INVITE") && has_totag()) {
> engage_rtp_proxy();
> }
>
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> if (is_method("BYE")) {
> setflag(1); # do accounting ...
> setflag(3); # ... even if the transaction
> fails
> } else if (is_method("INVITE")) {
> # even if in most of the cases is useless,
> do RR for
> # re-INVITEs alos, as some buggy clients
> do change route set
> # during the dialog.
> record_route();
> }
> # route it out to whatever destination was set by
> loose_route()
> # in $du (destination URI).
> route(1);
> } else {
> /* uncomment the following lines if you want to
> enable presence */
> if (is_method("SUBSCRIBE") && $rd == "
> voip.unisi.it") {
> # in-dialog subscribe requests
> route(2);
> exit;
> }
> if ( is_method("ACK") ) {
> if ( t_check_trans() ) {
> # non loose-route, but stateful
> ACK; must be an ACK after
> # a 487 or e.g. 404 from upstream
> server
> t_relay();
> exit;
> } else {
> # ACK without matching transaction
> ->
> # ignore and discard
> exit;
> }
> }
> sl_send_reply("404","Not here");
> }
> exit;
> }
>
> #initial requests
>
> # CANCEL processing
> if (is_method("CANCEL"))
> {
> if (t_check_trans())
> t_relay();
> exit;
> }
>
> t_check_trans();
>
> # authenticate if from local subscriber (uncomment to enable auth)
> # authenticate all initial non-REGISTER request that pretend to be
> # generated by local subscriber (domain from FROM URI is local)
> # if (!(method=="REGISTER") && from_uri==myself) /*no multidomain
> version*/
> if (!(method=="REGISTER") && is_from_local())  /*multidomain
> version*/
> {
> if(!check_source_address("0")){
> if (!proxy_authorize("", "subscriber")) {
> proxy_challenge("", "0");
> exit;
> }
> if (!db_check_from()) {
> sl_send_reply("403","Forbidden auth ID");
> exit;
> }
>
> consume_credentials();
> # caller authenticated
> }
> }
>
> # preloaded route checking
> if (loose_route()) {
> xlog("L_ERR", "Attempt to route with preloaded Route's
> [$fu/$tu/$ru/$ci]");
> if (!is_method("ACK"))
> sl_send_reply("403","Preload Route denied");
> exit;
> }
>
> # record routing
>

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread Răzvan Crainea


Hi, Qasim!

There are two problems with your approach: the first one is that you are 
using the engage_rtp_proxy() function in a bridging mode scenario. The 
behavior of this is undefined, because the rtpproxy module cannot fully 
determine your scenario (for example what's the direction of the media 
flow in the reply). That's why you should use the rtpproxy_offer() and 
rtpproxy_answer() functions to explicitly indicate the direction in 
INVITE and replies.
The second problem is that you try to change the SDP twice: first by the 
fix_nated_sdp() and then by engage_rtp_proxy(). These changes confuse 
OpenSIPS, who tries to apply both of them. Try to use only one. My 
suggestion is to rtpproxy_offer/answer() to fix the SDP, without calling 
fix_nated_sdp().


Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 05/09/2013 02:33 PM, Nick Khamis wrote:

It's not a bug, many of us here use RTP proxy in the same scenario.
Can you please provide a sip trace using ngrep
(http://wiki.freeswitch.org/wiki/Packet_Capture). Secondly, post the
relevant far end nat related scripting please.


Nick.

On 5/9/13, qasimak...@gmail.com  wrote:

Hi,

I am facing a problem when a client connects to opensips from NATed
network. I am using rtpproxy in bridging mode i.e. from publicnetwork to
private network. When i use fix_nated_sdp function from nathelper the local
IP address of the caller is replaced by its public IP but the problem
starts when i use engage_rtp_proxy instead of replacing server's public ip
to private it embeds private ip after the caller's publicIP like
X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and engage_rtp_proxy
with flag rie.

The question is am i using something wrong here or should it be counted as
a bug.

If you want some more clarification can draw a flow diagram also.

Regards,
Qasim



___
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] OpenSIPS with public/private interface and RTPProxy

2013-05-09 Thread Răzvan Crainea

As also detailed in the other ticket, as well as in the documentation, 
the engage_rtp_proxy() function has an undefined behavior when using in 
a bridged scenario. Therefore I recommend you to use the 
rtpproxy_offer/answer() functions.


Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 05/09/2013 02:34 PM, qasimak...@gmail.com wrote:

For engage_rtpproxy there are two flags that are used i.e. i for LAN
interface and E for WAN interface. you can use these two flags to
specify your direction of bridging. e.g. ie for LAN to WAN bridging and
ei for WAN to LAN bridging. Meanwhile look at this documentation for
detailed flag usage.

http://www.opensips.org/html/docs/modules/1.8.x/rtpproxy.html#id292744


Regards,
Qasim


On Thu, May 9, 2013 at 4:09 PM, Michele Pinassi
mailto:michele.pina...@unisi.it>> wrote:

Hi all,

i have an OpenSIPS server with two interface, PUBLIC (xxx) and PRIVATE
(172.20.1.2). The PRIVATE interface works inside a LAN dedicated to
VoIP, with a MediaServer (172.20.1.5) and a Patton Gateway for PSTN
(172.20.1.4).

Users phone's can register on both interface and i use RTPProxy (in
bridging mode) to ensure that both side can talk togheter.

But something don't work as expected

Here's my OpenSIPS routing logic:

===
route{
 if (!mf_process_maxfwd_header("10")) {
 sl_send_reply("483","Too Many Hops");
 exit;
 }

 if (msg:len >=  2048 ) {
 sl_send_reply("513", "Message too big");
 exit;
 };

 if(is_method("INVITE") && has_totag()) {
 engage_rtp_proxy();
 }

 if (has_totag()) {
 # sequential request withing a dialog should
 # take the path determined by record-routing
 if (loose_route()) {
 if (is_method("BYE")) {
 setflag(1); # do accounting ...
 setflag(3); # ... even if the
transaction fails
 } else if (is_method("INVITE")) {
 # even if in most of the cases is
useless, do RR for
 # re-INVITEs alos, as some buggy
clients do change route set
 # during the dialog.
 record_route();
 }
 # route it out to whatever destination was
set by loose_route()
 # in $du (destination URI).
 route(1);
 } else {
 /* uncomment the following lines if you
want to enable presence */
 if (is_method("SUBSCRIBE") && $rd ==
"voip.unisi.it ") {
 # in-dialog subscribe requests
 route(2);
 exit;
 }
 if ( is_method("ACK") ) {
 if ( t_check_trans() ) {
 # non loose-route, but
stateful ACK; must be an ACK after
 # a 487 or e.g. 404 from
upstream server
 t_relay();
 exit;
 } else {
 # ACK without matching
transaction ->
 # ignore and discard
 exit;
 }
 }
 sl_send_reply("404","Not here");
 }
 exit;
 }

 #initial requests

 # CANCEL processing
 if (is_method("CANCEL"))
 {
 if (t_check_trans())
 t_relay();
 exit;
 }

 t_check_trans();

 # authenticate if from local subscriber (uncomment to
enable auth)
 # authenticate all initial non-REGISTER request that
pretend to be
 # generated by local subscriber (domain from FROM URI is local)
 # if (!(method=="REGISTER") && from_uri==myself) /*no
multidomain version*/
 if (!(method=="REGISTER") && is_from_local())
  /*multidomain version*/
 {
 if(!check_source_address("0")){
 if (!proxy_authorize("", "subscriber")) {
 proxy_challenge("", "0");

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread qasimak...@gmail.com

Hi Razvan,

My scenerio is like this

Client <---> NAT <---> OpenSIPs/RTPProxy <---> Client


in this scenerio left side of OpenSIPs is public side and the right side is
on private network. Secondly i have tried using rtpproxy_offer/answer() but
the same problem. I will try using rtpproxy_offer/answer() again in a bit
more detail now specially after hearing about problems in engage_rtpproxy
in brigding mode. Now can you point me how i can achieve nat handling in
rtpproxy module?

Regards,
Qasim


On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea  wrote:

> Hi, Qasim!
>
> There are two problems with your approach: the first one is that you are
> using the engage_rtp_proxy() function in a bridging mode scenario. The
> behavior of this is undefined, because the rtpproxy module cannot fully
> determine your scenario (for example what's the direction of the media flow
> in the reply). That's why you should use the rtpproxy_offer() and
> rtpproxy_answer() functions to explicitly indicate the direction in INVITE
> and replies.
> The second problem is that you try to change the SDP twice: first by the
> fix_nated_sdp() and then by engage_rtp_proxy(). These changes confuse
> OpenSIPS, who tries to apply both of them. Try to use only one. My
> suggestion is to rtpproxy_offer/answer() to fix the SDP, without calling
> fix_nated_sdp().
>
> Best regards,
>
> Razvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.**com 
>
>
> On 05/09/2013 02:33 PM, Nick Khamis wrote:
>
>> It's not a bug, many of us here use RTP proxy in the same scenario.
>> Can you please provide a sip trace using ngrep
>> (http://wiki.freeswitch.org/**wiki/Packet_Capture).
>> Secondly, post the
>> relevant far end nat related scripting please.
>>
>>
>> Nick.
>>
>> On 5/9/13, qasimak...@gmail.com  wrote:
>>
>>> Hi,
>>>
>>> I am facing a problem when a client connects to opensips from NATed
>>> network. I am using rtpproxy in bridging mode i.e. from publicnetwork to
>>> private network. When i use fix_nated_sdp function from nathelper the
>>> local
>>> IP address of the caller is replaced by its public IP but the problem
>>> starts when i use engage_rtp_proxy instead of replacing server's public
>>> ip
>>> to private it embeds private ip after the caller's publicIP like
>>> X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and
>>> engage_rtp_proxy
>>> with flag rie.
>>>
>>> The question is am i using something wrong here or should it be counted
>>> as
>>> a bug.
>>>
>>> If you want some more clarification can draw a flow diagram also.
>>>
>>> Regards,
>>> Qasim
>>>
>>>
>> __**_
>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread Răzvan Crainea


Hi, Qasim!

Basically this is what the rtpproxy module does: when you call 
rtpproxy_offer("ei") function, opensips tells the rtpproxy server that a 
new session has to be created and the media flow will be from external 
to internal. Rtpproxy assigns the proper interface(IP) and port and 
returns them to OpenSIPS, which advertises in the ongoing INVITE. So, 
considering the rtpproxy server has been configured correctly, all you 
have to do is call rtpproxy_offer() with the proper direction.


Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 05/09/2013 02:54 PM, qasimak...@gmail.com wrote:

Hi Razvan,

My scenerio is like this

Client <---> NAT <---> OpenSIPs/RTPProxy <---> Client


in this scenerio left side of OpenSIPs is public side and the right side
is on private network. Secondly i have tried using
rtpproxy_offer/answer() but the same problem. I will try using
rtpproxy_offer/answer() again in a bit more detail now specially after
hearing about problems in engage_rtpproxy in brigding mode. Now can you
point me how i can achieve nat handling in rtpproxy module?

Regards,
Qasim


On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea mailto:raz...@opensips.org>> wrote:

Hi, Qasim!

There are two problems with your approach: the first one is that you
are using the engage_rtp_proxy() function in a bridging mode
scenario. The behavior of this is undefined, because the rtpproxy
module cannot fully determine your scenario (for example what's the
direction of the media flow in the reply). That's why you should use
the rtpproxy_offer() and rtpproxy_answer() functions to explicitly
indicate the direction in INVITE and replies.
The second problem is that you try to change the SDP twice: first by
the fix_nated_sdp() and then by engage_rtp_proxy(). These changes
confuse OpenSIPS, who tries to apply both of them. Try to use only
one. My suggestion is to rtpproxy_offer/answer() to fix the SDP,
without calling fix_nated_sdp().

Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.__com 


On 05/09/2013 02:33 PM, Nick Khamis wrote:

It's not a bug, many of us here use RTP proxy in the same scenario.
Can you please provide a sip trace using ngrep
(http://wiki.freeswitch.org/__wiki/Packet_Capture
). Secondly,
post the
relevant far end nat related scripting please.


Nick.

On 5/9/13, qasimak...@gmail.com 
mailto:qasimak...@gmail.com>> wrote:

Hi,

I am facing a problem when a client connects to opensips
from NATed
network. I am using rtpproxy in bridging mode i.e. from
publicnetwork to
private network. When i use fix_nated_sdp function from
nathelper the local
IP address of the caller is replaced by its public IP but
the problem
starts when i use engage_rtp_proxy instead of replacing
server's public ip
to private it embeds private ip after the caller's publicIP like
X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and
engage_rtp_proxy
with flag rie.

The question is am i using something wrong here or should it
be counted as
a bug.

If you want some more clarification can draw a flow diagram
also.

Regards,
Qasim


_
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





___
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] Opensips 1.6.4-2 call handling problem

2013-05-09 Thread Bogdan-Andrei Iancu



  
  
Hello,
  
  Yes, it is because of the RADIUS server - OpenSIPS performs the
  RADIUS queries in a synchronous (blocking) mode - it blocks and
  wait for the reply from the RADIUS server.
  
  So if your RADIUS server stops answering (or answering in a very
  slow manner), it will also drag down OpenSIPS as you may end up
  with all OpenSIPS processes blocked in waiting for RADIUS replies.
  
  Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 05/06/2013 12:38 PM, dpa wrote:

  
  
  
  
  
Hello! 
 
There is  Opensips 1.6.4-2.
Today I found a problem that
Opensips  hasn`t been responded to any SIP message that has
been sent to it for a sometime.
 
I began to learn log file and
found such messages: 
“rc_ip_hostname: couldn't look up
host by addr: xx
May  6 09:50:17 opensips-main
/usr/local/opensips1.6.4-2/sbin/opensips[2146]:
rc_send_server: no reply from RADIUS server unknown:1812
May  6 09:50:17 opensips-main
/usr/local/opensips1.6.4-2/sbin/opensips[2146]:
ERROR:aaa_radius:send_auth_func: radius authentication
message failed with TIMEOUT”
 
These messages appeared in log
file somewhere about at that time while Opensips hasn`t been
responded to SIP messages. 
The fact is I am using radius for
prepaid scheme which I apply to some subscribers (but not
for all). 
 
May be it is just coincidence
  but my question is.  May radius problem affect normal
  Opensips working?
 
Thank you for any help.
 
 
  
  

___
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] Standalone OpenSIPS LCR Server

2013-05-09 Thread Bogdan-Andrei Iancu

Hello Daryawish,

The best practice is to use the DR module in combination with some
external script to translate the LCR info into info as DR understands.

DR is not cost aware, it simply routes (for a prefix) to a set of
gateways (in the given order). So, what your script has to do is to
arrange the gateways (for a prefix) in an order that reflects the cost.

Once you have the list of gws (for each prefix), DR module will do the
routing and failover by itself.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/06/2013 11:20 PM, Dārayavahush Khola wrote:
> Hello Everyone,
>
> I hope this has not been covered before and I am just generating noise
> however, I would like to put together an opensips server who's soul
> purpose is to handle LCR. The server will:
>
> * Receive requests from anywhere (Media Servers, other proxies etc...)
> * Use the DR module to perform LCR
> * Forward the request to the cheapest route
>
> In determining the least-cost, and forwarding to the cheapest route
> there is a strict flow of events that I would like to implement:
>
> * Pull up all entries for a given prefix (exact vs longest matching to
> be discussed)
> * Pick the gateway with the cheapest cost
> |
> -- 1) Is the retail price cheaper that list? (Yes: Go to 2)
>  |
>  --> 2) Gateway Available? (Yes: Create the route) (No: Go to 3)
> |
> > 3) Gateway not Available (Go to the next cheapest
> gateway for the prefix) (iterate to 1)
>
> I have been using Opensips for a couple of years now to do some
> typical tasks however, nothing that would require the implementation
> of such logic. If it's ok with the list's moderators and subscribers,
> I would like to ask for the help from this list in implementing an
> "OpenSIPS LCR Server". The final configuration will be made public
> within this thread, and can be included on the OpenSIPS website if
> felt worthy of it ;).
>
> Before pointing to  solutions such as CDRTool etc.., and how they can
> be retrofitted to get the sought after results, I would like to
> implement an LCR server using *only* opensips with some fields added
> to DR related tables (dialplan, dr_*), and the LCR logic.
>
> If this email is to be accepted as a thread like discussion, I can
> start by including the database fields that should be added, and go
> from there
>
>
> Your help is appreciated,
>
> Daryawish Khola (PhD).
>
> ___
> 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] Using Dispatcher with destination as a host name

2013-05-09 Thread Bogdan-Andrei Iancu

Hello John,

So, after the  ds_select_domain("2", "0");  , when doing first relay();
, you see 2 INVITEs going out ? Are the 2 INVITEs the same (check the
branch param for the top most VIA).

Also, add an xlog() just before the relay() printing $ru/$du and
$branch[*] - to see all destinations.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/07/2013 11:57 AM, John Quick wrote:
> I am using the Dispatcher module on OpenSIPS version 1.8.2-notls.
> The destination field for 'Set 2' is sip:sipipgw.magrathea.net (which
> resolves in DNS to two different IP addresses).
> The code in my failure_route when a call has failed to reach a 'Set 1'
> destination, is essentially like this:
> ds_select_domain("2", "0");
> route(15);
>
> ...and route 15 contains some lines like this:
> t_on_failure("3");
> t_relay();
>
> After executing the code outlined above, a SIP trace shows that OpenSIPS
> sends two identical INVITE requests to one magrathea address. The two
> INVITE's are sent almost simultaneously. Is this an error? I would expect to
> see one INVITE to one address or maybe one to each address (parallel
> forking), but not two to one address.
>
> John Quick
> Smartvox Limited
> Web: www.smartvox.co.uk
>
>
>
>
> ___
> 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] Using Dispatcher with destination as a host name

2013-05-09 Thread Bogdan-Andrei Iancu

Hello John,

The dispatcher module will simply push the configured destination SIP
uri (from dispatcher table) as destination for the call ($du or $ru) -
it is the t_relay() which will evaluate the destination from DNS point
of view, doing NAPTR, SRV and A lookup - if there are multiple choices,
weights will be used to select the result, but at the end only one IP
will be used at a time. The other IPs may be used via dns-based failover
if first IP results in timeout or 502 replies. The dns-based failover,
if activated, will be automatically done by TM (as serial forking),
totally transparent for the script.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 05/07/2013 12:03 PM, John Quick wrote:
> Sorry, I just realised there may be other factors in this duplicate INVITE
> problem so it may not be connected with the DNS resolving to two IP's.
> I would still be interested to know how dispatcher should behave when using
> a host name that resolves to more than one IP.
>
> John Quick
> Smartvox Limited
> Web: www.smartvox.co.uk
>
>
>
>
> ___
> 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] Detect failed SIP server

2013-05-09 Thread Bogdan-Andrei Iancu

Hi Chen-Che,

In OpenSIPS there are 2 timers - fr_timer and fr_inv_timer ; fr_timer -
timeout if no reply at all was received from next hop ; fr_inv_timer -
timeout to final reply (negative or positive).

First fr_timer is activate, until a reply is received -> it is switched
to fr_inv_timer.

So, in your case, I guess you do get a reply, so fr_timer is replaced
with fr_inv_timer ?!?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/09/2013 08:49 AM, microx wrote:
> HI Bogdan-Andrei,
>
> Thanks for your answer. However, in my configuration file, I set 
> modparam("tm", "fr_timer", 10)
> modparam("tm", "fr_timer_avp", "$avp(timeout)")
>
> route {
> $avp(timeout) = 32;
> !t_relay();
> }
>
> A caller still receives 408 request timeout when the caller does not receive
> 200 OK in 10 seconds (after sending INVITE) rather than 32 seconds. What
> should I set to make the caller receive 408 request timeout after 32
> seconds? Thanks for your help.
>
> Best regards,
> Chen-Che
>
>
>
>
> --
> View this message in context: 
> http://opensips-open-sip-server.1449251.n2.nabble.com/Detect-failed-SIP-server-tp7585427p7586240.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
>

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Standalone OpenSIPS LCR Server

2013-05-09 Thread Dārayavahush Khola

Hello Bogdan,

Thank you so much for your response. I did see that the DR module had
not notion of cost that is why I was perplexed when trying to piece
this together. My first question is, does the script have to be
external or can we somehow implement the logic using opensips script?
Processing the request using main, branch, reply route logic is much
more elegant than using cron jobs, stored procedures etc.. Not to
mention more portable.

For example, by adding a few more fields to the "dr_rules" table,
paired with opensips script to implement a cost aware OpenSIPS LCR
server? Along with dr_rules default fields (ruleid, groupid, prefix,
timerec, priority, routeid, gwlist, attrs, description), we would add:

BillingMinimum
BillIngIncrement
ListRate
RetailRate

We would use dr_groups.groupid and dr_rules.groupid to link the
different carrier to their specific routes. First off though, do we
have the flexibility of a C++ or Java  like language within OpenSIPS
script. More specifically, the use of arrays, loops, string
manipulation etc...
If so, this can all be done within the configuration file?

If this has not been attempted yet, which I am sure it has been, then
it's been a long time coming, and once implemented, I would like to
make it available to the OpenSIPS community.

Thanks in Advance,

Daryawish.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] crash after failover

2013-05-09 Thread Vlad Paiu


Hello,

It seems that the core dump is corrupt, since the BT full output does 
not really make any sense.
I've just tried to test the dlg_db_sync MI command on Postgres, and it 
works for me.


Perhaps the issue/bug is in the way you are updating the OpenSIPS 
sockets in the DB in the case of fail-over ?
Could you give an example of a DB record for such a call, after you have 
updated it to match the new sockets ?


Best Regards,

--
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Using Dispatcher with destination as a host name

2013-05-09 Thread John Quick

Sorry. My mistake. The dual INVITE was reported in ngrep because this server
has bonded eth ports, not because of anything in OpenSIPS.

John

-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] 
Sent: 09 May 2013 15:06
To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Using Dispatcher with destination as a host
name

Hello John,

So, after the  ds_select_domain("2", "0");  , when doing first relay(); ,
you see 2 INVITEs going out ? Are the 2 INVITEs the same (check the branch
param for the top most VIA).

Also, add an xlog() just before the relay() printing $ru/$du and $branch[*]
- to see all destinations.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/07/2013 11:57 AM, John Quick wrote:
> I am using the Dispatcher module on OpenSIPS version 1.8.2-notls.
> The destination field for 'Set 2' is sip:sipipgw.magrathea.net (which 
> resolves in DNS to two different IP addresses).
> The code in my failure_route when a call has failed to reach a 'Set 1'
> destination, is essentially like this:
> ds_select_domain("2", "0");
> route(15);
>
> ...and route 15 contains some lines like this:
> t_on_failure("3");
> t_relay();
>
> After executing the code outlined above, a SIP trace shows that 
> OpenSIPS sends two identical INVITE requests to one magrathea address. 
> The two INVITE's are sent almost simultaneously. Is this an error? I 
> would expect to see one INVITE to one address or maybe one to each 
> address (parallel forking), but not two to one address.
>
> John Quick
> Smartvox Limited
> Web: www.smartvox.co.uk
>
>
>
>
> ___
> 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] Detect failed SIP server

2013-05-09 Thread microx

Hi Bogdan-Andrei,

In my test environment, an outbound proxy forwards each received message
from UA to an internal SIP proxy server.
The SIP proxy server sends the message back to the outbound proxy after the
proxy server processed the message. 
As you said, the SIP proxy server returns 100 try to the outbound proxy when
receiving an INVITE (the message flow is shown below). So fr_timer should be
replaced with fr_inv_timer (but I leave the fr_inv_timer to default).
Anyway, after I modified my configuration to 
modparam("tm", "fr_timer", 10) 
modparam("tm", "fr_inv_timer", 32) 
modparam("tm", "fr_timer_avp", "$avp(timeout)") 
modparam("tm", "fr_inv_timer_avp", "$avp(intimeout)")
route { 
$avp(timeout) = 32;
$avp(intimeout)=32;
!t_relay(); 
} 
nothing changes. A caller remains to receive 408 request timeout after 10
seconds. I did lookup this forum but couldn't find directly related threads.
Please help me address this issue. Thanks so much.

Best regards,
Chen-Che

INVITE
1. caller->outbound proxy---proxy server
 100 try
2. callerproxy server
100 try
4. caller--outbound proxy<-proxy server
INVITE
5. caller--outbound proxy<-proxy server
INVITE
6. caller--outbound proxy->proxy server
.
.
.
   408 timeout
n. caller--outbound proxy->proxy server
   408 timeout
n+1. caller--outbound proxy<---proxy server
 408 timeout
n+2. caller

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

2013-05-09 Thread qasimak...@gmail.com

Yes exactly that is being done perfectly but what i want to do is to handle
NAT on client's end. The IP of client that comes in the SDP's c= param is
his local IP address and rtpproxy swaps that IP with server's local IP but
on the other way arround it tries to send the IP back to client's local IP
address which is not visible to server.

Actually we have two nated acenerios. One on the server end and the other
on the client's end.

Regards,
Qasim


On Thu, May 9, 2013 at 5:59 PM, Răzvan Crainea  wrote:

> Hi, Qasim!
>
> Basically this is what the rtpproxy module does: when you call
> rtpproxy_offer("ei") function, opensips tells the rtpproxy server that a
> new session has to be created and the media flow will be from external to
> internal. Rtpproxy assigns the proper interface(IP) and port and returns
> them to OpenSIPS, which advertises in the ongoing INVITE. So, considering
> the rtpproxy server has been configured correctly, all you have to do is
> call rtpproxy_offer() with the proper direction.
>
>
> Best regards,
>
> Razvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.**com 
>
> On 05/09/2013 02:54 PM, qasimak...@gmail.com wrote:
>
>> Hi Razvan,
>>
>> My scenerio is like this
>>
>> Client <---> NAT <---> OpenSIPs/RTPProxy <---> Client
>>
>>
>> in this scenerio left side of OpenSIPs is public side and the right side
>> is on private network. Secondly i have tried using
>> rtpproxy_offer/answer() but the same problem. I will try using
>> rtpproxy_offer/answer() again in a bit more detail now specially after
>> hearing about problems in engage_rtpproxy in brigding mode. Now can you
>> point me how i can achieve nat handling in rtpproxy module?
>>
>> Regards,
>> Qasim
>>
>>
>> On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea > > wrote:
>>
>> Hi, Qasim!
>>
>> There are two problems with your approach: the first one is that you
>> are using the engage_rtp_proxy() function in a bridging mode
>> scenario. The behavior of this is undefined, because the rtpproxy
>> module cannot fully determine your scenario (for example what's the
>> direction of the media flow in the reply). That's why you should use
>> the rtpproxy_offer() and rtpproxy_answer() functions to explicitly
>> indicate the direction in INVITE and replies.
>> The second problem is that you try to change the SDP twice: first by
>> the fix_nated_sdp() and then by engage_rtp_proxy(). These changes
>> confuse OpenSIPS, who tries to apply both of them. Try to use only
>> one. My suggestion is to rtpproxy_offer/answer() to fix the SDP,
>> without calling fix_nated_sdp().
>>
>> Best regards,
>>
>> Razvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.**__com > solutions.com >
>>
>>
>>
>> On 05/09/2013 02:33 PM, Nick Khamis wrote:
>>
>> It's not a bug, many of us here use RTP proxy in the same
>> scenario.
>> Can you please provide a sip trace using ngrep
>> 
>> (http://wiki.freeswitch.org/__**wiki/Packet_Capture
>> 
>> >).
>> Secondly,
>>
>> post the
>> relevant far end nat related scripting please.
>>
>>
>> Nick.
>>
>> On 5/9/13, qasimak...@gmail.com 
>>
>> mailto:qasimak...@gmail.com>> wrote:
>>
>> Hi,
>>
>> I am facing a problem when a client connects to opensips
>> from NATed
>> network. I am using rtpproxy in bridging mode i.e. from
>> publicnetwork to
>> private network. When i use fix_nated_sdp function from
>> nathelper the local
>> IP address of the caller is replaced by its public IP but
>> the problem
>> starts when i use engage_rtp_proxy instead of replacing
>> server's public ip
>> to private it embeds private ip after the caller's publicIP
>> like
>> X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and
>> engage_rtp_proxy
>> with flag rie.
>>
>> The question is am i using something wrong here or should it
>> be counted as
>> a bug.
>>
>> If you want some more clarification can draw a flow diagram
>> also.
>>
>> Regards,
>> Qasim
>>
>>
>> __**___
>> Users mailing list
>> Users@lists.opensips.org 
>> > >
>> 
>> http://lists.opensips.org/cgi-**__bin/mailman/listinfo/users
>> 
>>

Re: [OpenSIPS-Users] Registrar not saving received from Path header

Re: [OpenSIPS-Users] Tuning for maximum number of TCP connections

[OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

Re: [OpenSIPS-Users] one way audio in voip clients

[OpenSIPS-Users] RTPProxy for users behind NAT.

Re: [OpenSIPS-Users] refer scenario - record-route header

Re: [OpenSIPS-Users] one way audio in voip clients

Re: [OpenSIPS-Users] one way audio in voip clients

Re: [OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

Re: [OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

Re: [OpenSIPS-Users] OpenSIPS with public/private interface and RTPProxy

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

Re: [OpenSIPS-Users] Opensips 1.6.4-2 call handling problem

Re: [OpenSIPS-Users] Standalone OpenSIPS LCR Server

Re: [OpenSIPS-Users] Using Dispatcher with destination as a host name

Re: [OpenSIPS-Users] Using Dispatcher with destination as a host name

Re: [OpenSIPS-Users] Detect failed SIP server

Re: [OpenSIPS-Users] Standalone OpenSIPS LCR Server

Re: [OpenSIPS-Users] crash after failover

Re: [OpenSIPS-Users] Using Dispatcher with destination as a host name

Re: [OpenSIPS-Users] Detect failed SIP server

Re: [OpenSIPS-Users] RTPProxy for users behind NAT.

25 matches

Site Navigation

Mail list logo

Footer information