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

2013-05-16 Thread Nathaniel L Keeling III

Hello Bogdan,

I added the patch and here is what I found: "OpenSips[4378]: [ID 269964 
local1.debug] DBG:registrar:pack_ci: xXx - flags are 0". I have also 
included the log file.


Thanks

Nathaniel Keeling

On 5/16/13 3:47 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

Attached is an extended patch - remove the old one and apply this one. 
Again look for any xXx logs .


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

On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:

Hello Bogdan,

here is the output from opensips's og file of the save() with the 
patch and the code snippet from the opensips.cfg. I did not see any 
ant logs with "xXx". Also,I have usrloc's db_mode set to 3.


xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE 
");

if (!save("location","p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to 
save Register's request location");

sl_reply_error();
}
xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has 
successfully registered with Akan Voice");
exit; 


May 16 23:35:53   OpenSips[4378]: [ID 292666 local1.debug] DBG:core:parse_msg: 
SIP Request:
May 16 23:35:53   OpenSips[4378]: [ID 776402 local1.debug] DBG:core:parse_msg:  
method:  
May 16 23:35:53   OpenSips[4378]: [ID 700387 local1.debug] DBG:core:parse_msg:  
uri: 
May 16 23:35:53   OpenSips[4378]: [ID 641661 local1.debug] DBG:core:parse_msg:  
version: 
May 16 23:35:53   OpenSips[4378]: [ID 497291 local1.debug] 
DBG:core:parse_headers: flags=2
May 16 23:35:53   OpenSips[4378]: [ID 202288 local1.debug] 
DBG:core:parse_via_param: found param type 232,  = ; 
state=16
May 16 23:35:53   OpenSips[4378]: [ID 218084 local1.debug] DBG:core:parse_via: 
end of header reached, state=5
May 16 23:35:53   OpenSips[4378]: [ID 636936 local1.debug] 
DBG:core:parse_headers: via found, flags=2
May 16 23:35:53   OpenSips[4378]: [ID 481110 local1.debug] 
DBG:core:parse_headers: this is the first via
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 1, name=, body=
May 16 23:35:53   OpenSips[4378]: [ID 499462 local1.debug] DBG:core:parse_msg:  
first  via:  <209.252.110.38:5060(5060)>
May 16 23:35:53   OpenSips[4378]: [ID 573780 local1.debug] DBG:core:parse_msg: 
;
May 16 23:35:53   OpenSips[4378]: [ID 937246 local1.debug] DBG:core:parse_msg: 
May 16 23:35:53   OpenSips[4378]: [ID 979351 local1.debug] DBG:core:parse_msg: 
exiting
May 16 23:35:53   OpenSips[4378]: [ID 911547 local1.debug] 
DBG:core:receive_msg: After parse_msg...
May 16 23:35:53   OpenSips[4378]: [ID 451678 local1.debug] 
DBG:core:receive_msg: preparing to run routing scripts...
May 16 23:35:53   OpenSips[4378]: [ID 497291 local1.debug] 
DBG:core:parse_headers: flags=40
May 16 23:35:53   OpenSips[4378]: [ID 202288 local1.debug] 
DBG:core:parse_via_param: found param type 234,  = <208.54.44.253>; 
state=6
May 16 23:35:53   OpenSips[4378]: [ID 202288 local1.debug] 
DBG:core:parse_via_param: found param type 235,  = <44494>; state=6
May 16 23:35:53   OpenSips[4378]: [ID 202288 local1.debug] 
DBG:core:parse_via_param: found param type 232,  = ; 
state=16
May 16 23:35:53   OpenSips[4378]: [ID 218084 local1.debug] DBG:core:parse_via: 
end of header reached, state=5
May 16 23:35:53   OpenSips[4378]: [ID 636936 local1.debug] 
DBG:core:parse_headers: via found, flags=40
May 16 23:35:53   OpenSips[4378]: [ID 903840 local1.debug] 
DBG:core:parse_headers: parse_headers: this is the second via
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 1, name=, body=
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 8, name=, body=<30>
May 16 23:35:53   OpenSips[4378]: [ID 218084 local1.debug] DBG:core:parse_to: 
end of header reached, state=10
May 16 23:35:53   OpenSips[4378]: [ID 841317 local1.debug] DBG:core:parse_to: 
display={}, ruri={sip:nkeel...@akanvoice.com}
May 16 23:35:53   OpenSips[4378]: [ID 993225 local1.debug] 
DBG:core:get_hdr_field:  [30]; uri=[sip:nkeel...@akanvoice.com] 
May 16 23:35:53   OpenSips[4378]: [ID 159376 local1.debug] 
DBG:core:get_hdr_field: to body [^M
May 16 23:35:53   ]
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 3, name=, 
body=<>
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 4, name=, 
body=<;tag=z9hG4bK97036383>
May 16 23:35:53   OpenSips[4378]: [ID 994387 local1.debug] 
DBG:core:parse_headers: header field type 6, name=, 
body=<548361087116@100.229.65.174>
May 16 23:35:53   OpenSips[4378]: [ID 421386 local1.debug] DBG:core:parse_uri: 
parsed uri:
May 16 23:35:53type=1 user=<>(0)
May 16 23:35:53passwd=<>(0)
May 16 23:35:53host=(13)
May 16 23:35:53port=<>(0): 0
May 16 23:35:53params=<>(0)
May 16 23:35:53headers=<>(0)

Re: [OpenSIPS-Users] memory consumed by t_relay

2013-05-16 Thread microx
Hi Bogdan-Andrei,

Please refer to the log 
OpenSIP_outbound_memory.log

  

Many thanks for your help.

Best regards,
Chen-Che



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/memory-consumed-by-t-relay-tp7586016p7586368.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


Re: [OpenSIPS-Users] use of is_from_gw directive from drouting module.

2013-05-16 Thread Ovidiu Sas
Try to use dr_is_gw():
http://www.opensips.org/html/docs/modules/1.9.x/drouting.html#id294057

Regards,
Ovidiu Sas

On Tue, May 14, 2013 at 9:16 PM, Miguel J.  wrote:
> Dear UserList Opensips:
>
> I used drouting with OpenSips 1.8.0 release, the gateways list was in
> the dr_gateways table and no ports where configurated in it. For incoming
> calls wasn't necesary.
>
> Now, I upgrade OpenSips to 1.9.1 release and for incoming calls from a
> few providers, I can't do match they whith the "is_from_gw()" directive. I
> tried in this diferents forms:
>
> is_from_gw(), OpenSips start and providers with 5060-udp port match
> fine, but a few providers who employ other random ports haven't match.
> is_from_gw("", "n"), OpenSips start but incoming calls haven't match
> with the gateways on dr_gateways table.
> is_from_gw("-1", "n"), OpenSips don't start.
> is_from_gw("diferents_formats", "n"), OpenSips start but incoming
> calls haven't match with the gateways on dr_gateways table.
>
> Then I need to ask you...
>
> ¿How I have to use the is_from_gw directive with "n" parameter and
> dr_gateways table with the list of incoming calls providers?.
>
> ¿Which is the field on the dr_gateways table where i can make match with
> type parameter on the is_from_gw directive?.
>
> Thanyou very much and best regards.
>
> Miguel J. López.
>
> ___
> 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


Re: [OpenSIPS-Users] use of is_from_gw directive from drouting module.

2013-05-16 Thread Miguel J.
Dear Bogdan-Andrei

I've tried to asign a new group for this providers, (group 3, I can't
asign it to group 0 because this group is used by another type of
users). I've filled dr_groups registers with this new information,
(dr_gateways was filled before, on 1.8 release):

select * from dr_gateways;
++-+--++---++---++---+
| id | gwid| type | address| strip | pri_prefix
| attrs | probe_mode | description   |
++-+--++---++---++---+
|  1 | Provider_0  |2 | XXX.XXX.XXX.XXX| 0 | NULL
| NULL  |  0 | Provider0_incoming|



select * from dr_groups;
++---+-+-+---+
| id | username  | domain  | groupid | description
|
++---+-+-+---+
| 24 | Provider_0|  XXX.XXX.XXX.XXX|   3 |
Provider0_incoming|


And the new configuration:

} else if (is_from_gw()) {
# request comes from gw
setflag(21);

} else if (is_from_gw("3","n")) {
# request comes from gw with strange udp-ports
setflag(21);
}

With this configuration, the is_from_gw() directive is working right for
providers without dr_groups db information and using 5060 port, but the
is_from_gw("3","n") aren't working, it don't match with providers of
group 3 and working with ports diferents of 5060.

¿Are this configuration wrong?.

Thankyou very much for your help.


-- 



-
Sus datos de carácter personal (nombre, apellidos, dirección postal y de
correo electrónico, etc.) son tratados para la gestión de su relación
con la Entidad, así como para el envío de información sobre nuestra
actividad y la de terceros relacionadas con la actividad de Consulting
Smartic Solutions, S.L., CIF: B85130037, C/Pº de la Castellana, 135, 7ª
planta, 28046 Madrid. Usted puede ejercer sus derechos de acceso,
rectificación, cancelación y oposición dirigiéndose por escrito, con
copia de un documento que acredite su identidad, a la dirección info
(arroba) smartic.es.
Este mensaje puede contener información confidencial. Si usted no es su
destinatario, no debe leerlo, copiarlo, distribuirlo, ni hacer uso de la
información que contiene. En este caso, por favor, llámenos o
comuníquenoslo por escrito y borre este mensaje de su sistema.
- 

-Mensaje original-
De: Bogdan-Andrei Iancu 
Para: OpenSIPS users mailling list 
Cc: "\"Miguel J.\" López Valverde" 
Asunto: Re: [OpenSIPS-Users] use of is_from_gw directive from drouting
module.
Fecha: Wed, 15 May 2013 20:59:47 +0300

Hello Miguel,

Starting with 1.9, DR module does SIP wise resolving of the destination
(in order to find all the IPs behind the a FQDN, via NATPR, SRV and A
lookups). A side effect is that according to SIP, no port means 5060.

In your case, the "n" flag should do the trick - but I understand that
when using it, your problem is what group to use (by the way, "" group
is translated to group 0 ) . Are your GWs in various groups?

Regards,

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


On 05/15/2013 04:16 AM, Miguel J. López Valverde wrote: 

> Dear UserList Opensips:
> 
> I used drouting with OpenSips 1.8.0 release, the gateways list was
> in the dr_gateways table and no ports where configurated in it. For
> incoming calls wasn't necesary.
> 
> Now, I upgrade OpenSips to 1.9.1 release and for incoming calls
> from a few providers, I can't do match they whith the "is_from_gw()"
> directive. I tried in this diferents forms:
> 
> is_from_gw(), OpenSips start and providers with 5060-udp port
> match fine, but a few providers who employ other random ports haven't
> match.
> is_from_gw("", "n"), OpenSips start but incoming calls haven't
> match with the gateways on dr_gateways table.
> is_from_gw("-1", "n"), OpenSips don't start.
> is_from_gw("diferents_formats", "n"), OpenSips start but
> incoming calls haven't match with the gateways on dr_gateways table.
> 
> Then I need to ask you...
> 
> ¿How I have to use the is_from_gw directive with "n" parameter and
> dr_gateways table with the list of incoming calls providers?.
> 
> ¿Which is the field on the dr_gateways table where i can make
> match with type parameter on the is_from_gw directive?.
> 
> Thanyou very much and best regards.
> 
> Miguel J. López. 
> 
> 
> ___
> 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] Odd opensips REGISTER/INVITE behavior for many simultaneous users

2013-05-16 Thread James Tranovich
Hello Bogdan,

Thanks for your reply! We are using opensips 1.8.0-notls (x86_64/linux).

We do not think this issue is load related but perhaps older registrations
have not yet expired. We will try setting the min_expires parameter to a
low number to test this hypothesis; any other approaches we could try?

Thanks once again!

James


On Thu, May 16, 2013 at 1:53 AM, Bogdan-Andrei Iancu wrote:

> **
> Hello James,
>
> No, there is no such known bug or issue. What I suspect is that there are
> short intervals (milisecs) where an AOR is not registered - this may happen
> because :
> - the test tool is not performing properly under high load and fails
> to do re-register before old registration expires.
> - OpenSIPS is overloaded (too few processes ?) and it is not able to
> process traffic in realtime (check the LOAD related statistics).
>
> What OpenSIPs versions are you using ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/15/2013 01:56 AM, James Tranovich wrote:
>
>   Hello all --
>
>  First, we love opensips :)
>
> Lately, we have been running into a strange issue which seems to be
> related to handling a ton of REGISTER messages. Basically, we have a test
> script that tries to simulate about 50 to 100 simultaneous calls; they all
> register en masse and then randomly start placing calls to another test
> number (after a random time interval). Every once in a while, though, an
> INVITE won't go through because opensips apparently can't find that phone
> number. Oddly enough, if we do an "opensipsctl online" immediately
> before/after, that command shows that, in fact, the recipient's number is
> present and presumably already registered. SIP logs/ngrep tracing confirm
> this.
>
>  I was wondering if this is a known bug. This behavior only happens when
> registering a certain number of calls at once; if we test with a low number
> of calls (10, say), this behavior does not happen. It may be that we are
> spamming opensips with too many REGISTER messages (authentication is
> required, so two REGISTER messages are sent, the first w/o auth, the second
> with auth). But I don't see why opensips should have problems with this.
>
>  Any thoughts on this? Is this a known issue already? (Searching for this
> issue didn't yield much). Thanks!
>
> James
>
>
> ___
> 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


[OpenSIPS-Users] Slight problem routing 100s and 183s

2013-05-16 Thread Nick Khamis
Hello Everyone,

Hope all is well. Here in Canada our 2 weeks of summer is almost over
and now it's almost autumn ;). Those of you who are in Montreal know
what I am talking about

Long story short, we love OpenSIPS so much that we decided to add
another box between our media servers and our service provider,
yielding a:

NAT Box   <> OpenSIPSIn   <--> Asterisk1...N <>OpenSIPSOut

OpenSIPSIn: 192.168.2.5
Asterisk: 192.168.2.10
OpenSIPSOut: 192.168.2.20

Everything was working fine in our natted environment until we added
OpenSIPSOut.
Looking at the trace, I see a problem with via and rr. The trace from
OpenSIPSIn:

U 2013/05/16 13:12:53.978573 192.168.2.5:5060 -> 192.168.2.10:5060
INVITE sip:15148392...@server.example.com:5060;user=phone SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 192.168.2.5:5060;branch=z9hG4bKd9a4.dfbf0a33.0.
Via: SIP/2.0/UDP
192.168.2.11:5060;rport=5060;received=192.168.2.11;branch=z9hG4bKc3495b99FCBA96F0.


Then the "Giving a Try" coming in from our services provider to OpenSIPSIn
do not get responded to:


U 2013/05/16 13:12:54.177744 10.5.2.13:5060 -> 192.168.2.5:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
192.168.2.20:5060;received=79.12.11.7;branch=z9hG4bK5b6b.146a4f8.0.
Via: SIP/2.0/UDP
192.168.2.10:5060;received=192.168.2.10;branch=z9hG4bK1225fb65;rport=5060.

Givng a try

Givng a try

Givng a try

.

And so is the case for "Session Progress" coming in from our service provider:

U 2013/05/16 13:13:07.655052 10.5.2.13:5060 -> 192.168.2.5:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 192.168.2.20:5060;branch=z9hG4bK5b6b.146a4f8.0.
Via: SIP/2.0/UDP
192.168.2.10:5060;received=192.168.2.10;branch=z9hG4bK1225fb65;rport=5060.
Record-Route: .

Session Progress

Session Progress

Session Progress

.

To make things more interesting, asterisk creates a new callid when
receiving the initial request from OpenSIPSIn:

Call-ID: 16a8997f-217a7945-ca8ec106@192.168.2.11. vs
Call-ID: 1f5b92da3d973b2b7a6fb2752e8df585@192.168.2.10:5060.

In the past, we handled BYEs getting 404'ed by opensips because of the change in
callid by explicitly forcing the dialog matching using match/validate/
and fix_route_dialog() (Thanks Vlad! ;)

Would we force dialog matching for the 100 and 180's the same way we
did for BYEs?
If so where would be the safest place to do this.

Thanks in Advance,

Nick.

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


Re: [OpenSIPS-Users] MongoDB bug

2013-05-16 Thread kamika
Dear Vlad,

Dorry for being noisy, but will you prepare a separate patch or update the
module in next version of Opensips?
I just stuck in this, as perl driver loose the connection to mongoDb if
database was accedently restarted.. 

Thank you

Kamil



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/MongoDB-bug-tp7586282p7586360.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


Re: [OpenSIPS-Users] Where to place acc_aaa_request ?

2013-05-16 Thread Bogdan-Andrei Iancu
Well, do you want to do accouting via RADIUS (aaa) or via DB (in acc
table) ???

Regards,

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


On 05/16/2013 01:18 PM, Michele Pinassi wrote:
> Thanks Bodgan for your kindly reply but now accounting don't work:
> nothing will be added to acc table !
>
> Here's the full routing logic. Maybe there's something wrong:
>
> modparam("aaa_radius", "radius_config",
> "/etc/radiusclient-ng/radiusclient.conf")
>
>
> modparam("acc", "early_media", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "log_level", 1)
> modparam("acc", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf")
> modparam("acc", "aaa_flag", 1)
> modparam("acc", "aaa_extra",  "via=$hdr(Via[*]); \
>Digest-User-Name=$Au; \
>Calling-Station-Id=$from; \
>Called-Station-Id=$to; \
>Sip-Translated-Request-URI=$ru; \
>Sip-RPid=$avp(s:rpid); \
>Source-IP=$avp(s:source_ip); \
>Source-Port=$avp(s:source_port); \
>SIP-Proxy-IP=$avp(s:sip_proxy_ip); \
>Canonical-URI=$avp(s:can_uri); \
>
> Divert-Reason=$avp(s:divert_reason); \
>User-Agent=$hdr(user-agent); \
>Contact=$hdr(contact); \
>Event=$hdr(event) ;\
>ENUM-TLD=$avp(s:enum_tld)")
>
>
> ### 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 (check_address("4","$si","$sp","$proto")) {
> # xlog("L_INFO","IP $si Allowed");
>   } else {
>   xlog("L_INFO","IP $si Forbidden");
>   sl_send_reply("403", "Forbidden");
>   }
>   
>   
>   if (has_totag()) {
>   if (loose_route()) {
>   if (is_method("BYE")) {
>   setflag(1);
>   } else if (is_method("INVITE")) {
>   record_route();
>   }
>   route(1);
>   } else {
>   /* uncomment the following lines if you want to enable 
> presence */
>   if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") {
>   route(2);
>   exit;
>   }
>   if ( is_method("ACK") ) {
>   if ( t_check_trans() ) {
>   t_relay();
>   exit;
>   } else {
>   exit;
>   }
>   }
>   sl_send_reply("404","Not here");
>   }
>   exit;
>   }
>
>   if (is_method("CANCEL"))
>   {
>   if (t_check_trans())
>   t_relay();
>   exit;
>   }
>
>   if (is_method("INVITE")) {
>   setflag(1);
>   }
>
>   t_check_trans();
>
>   if (!(method=="REGISTER") && is_from_local())
>   {
>   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();
>
>   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"))
>

[OpenSIPS-Users] Multi Update Invites

2013-05-16 Thread M.Khaled W Chehab
Hi,

when a call hit opensips it send a 100 trying but if the softphone does not
receive 180/183 or 200 OK it will send an update invite ,and I want to block
it 

I read in the documentation that t_newtran() can stop it ,please can you
send me a sample where and how it should be  exists since I fail
implementing as 
You can find down where I am using t_check_trans
 
if (has_totag()) {
} else {
  if ( is_method("ACK") ) {
   if ( t_check_trans() ) {
   t_relay();
exit;
   } else {
# ACK without matching
transaction ->
# ignore and discard
exit;
   }
# CANCEL processing
if (is_method("CANCEL")) {
   if (t_check_trans()) {
   t_relay();
   }
   exit;
}
t_check_trans();
 
 
Regards
 

 

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


Re: [OpenSIPS-Users] LRN numbers

2013-05-16 Thread M.Khaled W Chehab
Dear Bogdan ,

 

I  Fix it by  setting do_routing()  instead of route(7) with t_relay 

 

Thanks 

 

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] 
Sent: Wednesday, May 15, 2013 8:36 PM
To: OpenSIPS users mailling list
Cc: M.Khaled W Chehab; users-boun...@lists.opensips.org
Subject: Re: [OpenSIPS-Users] LRN numbers

 

Hello,

You get that error as signaling functions are not allowed in branch route -
you invoke there route[7] which tried to send back a reply - the reply
sending function is not allowed in branch route.

Regards,



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


On 05/13/2013 04:28 PM, M.Khaled W Chehab wrote: 

Hi again,

 

I fix it using the below code but still there is a mistake since I can find
the below error, please can you check if I am coding in correct way

 

CRITICAL:tm:w_t_reply: unsupported route_type (8)

ERROR:signaling:sig_send_reply_mod: failed to send reply with tm module

 

 

if ($rU=~"^.") {

route(7);

route(1);

exit;

route[1] {

if (subst_uri('/(sip:.*);nat=yes/\1/')) {

setbflag(6);

}

if (isflagset(5)) {

   search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');

}

 

# for INVITEs enable some additional helper routes

if (is_method("INVITE")) {

 

t_on_branch("2");

t_on_reply("2");

t_on_failure("1");

avp_db_query("UPDATE `opensips`.`invites` set `trunkip`
='$rd' where  `CALLID` = '$ci' ");

} else if (is_method("BYE")) {

setflag(1); # do accounting ...

setflag(3); #transaction falis

setflag(4); #CDR Table

xlog("Route 1
Bye---");

   

} else if (is_method("ACK")) {

# call answered an ACKed, start billing here

} else if (is_method("CANCEL")) {

# call cancelled by caller, do clean up here' ");

}

if (!t_relay()) {

xlog("L_INFO", "--Debug Customer
ID:$avp(Cusid)/IP:$si--#11###Reply: $T_reply_code\n");

send_reply("500","Internal Error");

};

exit;

}

 

 

 

route[7]{

if (!do_routing("$avp(Cusid)","FW")) {

send_reply("404","No PSTN Route found");

exit;

}

}

 

route[6] {

if ( use_next_gw() ) {

$var(prefix) =
$(avp(gw_attrs){csv.value,1});

$rU = $var(prefix) + $avp(dst);

xlog("L_INFO", "--Debug Customer
ID:$avp(Cusid)/IP:$si-Calling number to Next Provier $rU\n");

setflag(26); #Missed calls

t_on_failure("1");

t_relay();

exit;

}

}

 

branch_route[2] {

xlog("L_INFO", "--Debug Customer ID:$avp(Cusid)/IP:$si-new
branch at $ru\n");

route(7);

}

 

failure_route[1] {

 

 

 if (!t_check_status("302")) {

if (!next_routing()){

xlog("L_INFO", "LRN - Unable to DIP");

t_reply("500","Unable to DIP");

exit;

}

xlog("L_INFO", "LRN - Unable to DIP - Trying Next");

t_on_failure("1");

t_relay();

exit;  

}

if (!$(ct.fields(uri){param.value,rn})){

xlog("L_INFO", "LRN - No redirect information found");

route(1);

}else if ($(ct.fields(uri){param.value,rn}) == $tU){

xlog("L_INFO", "LRN - Returned same number, no need to
redirect");

 route(1);

}else{ 

xlog("LRN-$rU---Else lRN
$avp(lrnct)-");

$rU=$avp(lrnct);

   

xlog("LRN-$rU---Else lRN
$avp(lrnct)-");

 route(1);

   

}

 

if (t_was_cancelled()) {

xlog("L_INFO", "--Debug Customer
ID:$avp(Cusid)/IP:$si-Call Canceled--SIP Reason:$T_reply_code\n");

xlog("L_INFO", "##==End of invite for
Customer ID:$avp(Cusid)/IP:$si--Over
$rdon_route_failure_1==##3 \n");

avp_db_query("delete   FROM `invites` WHERE `CALLID`
='$ci'");

 

exit;

}

 

 

 

if (t_check_status("481") ) {

acc_db_request("200 Dialog Timeout", "acc");

xlog("-Reply:
$T_reply_code#--481-422-487--#$rm from $si
(callid=$ci)##");

}

Re: [OpenSIPS-Users] Where to place acc_aaa_request ?

2013-05-16 Thread Michele Pinassi
Thanks Bodgan for your kindly reply but now accounting don't work:
nothing will be added to acc table !

Here's the full routing logic. Maybe there's something wrong:

modparam("aaa_radius", "radius_config",
"/etc/radiusclient-ng/radiusclient.conf")


modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
modparam("acc", "detect_direction", 0)
modparam("acc", "log_level", 1)
modparam("acc", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf")
modparam("acc", "aaa_flag", 1)
modparam("acc", "aaa_extra",  "via=$hdr(Via[*]); \
   Digest-User-Name=$Au; \
   Calling-Station-Id=$from; \
   Called-Station-Id=$to; \
   Sip-Translated-Request-URI=$ru; \
   Sip-RPid=$avp(s:rpid); \
   Source-IP=$avp(s:source_ip); \
   Source-Port=$avp(s:source_port); \
   SIP-Proxy-IP=$avp(s:sip_proxy_ip); \
   Canonical-URI=$avp(s:can_uri); \

Divert-Reason=$avp(s:divert_reason); \
   User-Agent=$hdr(user-agent); \
   Contact=$hdr(contact); \
   Event=$hdr(event) ;\
   ENUM-TLD=$avp(s:enum_tld)")


### 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 (check_address("4","$si","$sp","$proto")) {
#   xlog("L_INFO","IP $si Allowed");
} else {
xlog("L_INFO","IP $si Forbidden");
sl_send_reply("403", "Forbidden");
}


if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(1);
} else if (is_method("INVITE")) {
record_route();
}
route(1);
} else {
/* uncomment the following lines if you want to enable 
presence */
if (is_method("SUBSCRIBE") && $rd == "voip.unisi.it") {
route(2);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}

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

if (is_method("INVITE")) {
setflag(1);
}

t_check_trans();

if (!(method=="REGISTER") && is_from_local())
{
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();

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");
exit;
}

if (!db_check_to())
{
sl_send_reply("403","Forbidden auth ID");
exit;
}

  

Re: [OpenSIPS-Users] VIA relay error using mhomed=1

2013-05-16 Thread qasimak...@gmail.com
On further investigation i see that i only face this issue when both caller
and callee are on the same network. If both are on separate network it
works fine.

Regards,
Qasim


On Thu, May 16, 2013 at 3:05 PM, qasimak...@gmail.com
wrote:

> yes.
>
> Regards,
> Qasim
>
>
> On Thu, May 16, 2013 at 2:50 PM, Bogdan-Andrei Iancu 
> wrote:
>
>> **
>> And do you have UDP 202.152.203.195 port 6000 as listener defined in
>> OpenSIPS ??
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 05/16/2013 12:32 PM, qasimak...@gmail.com wrote:
>>
>>  Hi Bodgan,
>>
>>  Yes i see the following route header in my packet.
>>
>> Route:
>> 
>>
>>
>>  And yes i am routing it through loose_route.
>>
>>  Regards,
>> Qasim
>>
>>
>> On Wed, May 15, 2013 at 10:40 PM, Bogdan-Andrei Iancu <
>> bog...@opensips.org> wrote:
>>
>>>  Hello Qasim,
>>>
>>> The ACK should be routed via loose_route() based on the "Route" headers
>>> from it. Could you check if the Route hdrs (from the ACK) are correctly
>>> reflecting your opensips interfaces ?
>>>
>>> Best regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>> On 05/14/2013 07:55 AM, qasimak...@gmail.com wrote:
>>>
>>>   Hi,
>>>
>>>  I am using OpenSIPs in Public<->Private bridging mode and have enabled
>>> mhomed=1. But the problem is that when we have a call in which both parties
>>> are on Public interface the INVITE gets relayed properly but and ACK of
>>> that invite gives the following error.
>>>
>>> ERROR:core:get_out_socket: no socket found
>>> ERROR:core:forward_request: cannot forward to af 2, proto 1 no
>>> correspondinglistening socket
>>>
>>>  Regards,
>>> Qasim
>>>
>>>
>>> ___
>>> 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] VIA relay error using mhomed=1

2013-05-16 Thread qasimak...@gmail.com
yes.

Regards,
Qasim


On Thu, May 16, 2013 at 2:50 PM, Bogdan-Andrei Iancu wrote:

> **
> And do you have UDP 202.152.203.195 port 6000 as listener defined in
> OpenSIPS ??
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/16/2013 12:32 PM, qasimak...@gmail.com wrote:
>
>  Hi Bodgan,
>
>  Yes i see the following route header in my packet.
>
> Route:
> 
>
>
>  And yes i am routing it through loose_route.
>
>  Regards,
> Qasim
>
>
> On Wed, May 15, 2013 at 10:40 PM, Bogdan-Andrei Iancu  > wrote:
>
>>  Hello Qasim,
>>
>> The ACK should be routed via loose_route() based on the "Route" headers
>> from it. Could you check if the Route hdrs (from the ACK) are correctly
>> reflecting your opensips interfaces ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 05/14/2013 07:55 AM, qasimak...@gmail.com wrote:
>>
>>   Hi,
>>
>>  I am using OpenSIPs in Public<->Private bridging mode and have enabled
>> mhomed=1. But the problem is that when we have a call in which both parties
>> are on Public interface the INVITE gets relayed properly but and ACK of
>> that invite gives the following error.
>>
>> ERROR:core:get_out_socket: no socket found
>> ERROR:core:forward_request: cannot forward to af 2, proto 1 no
>> correspondinglistening socket
>>
>>  Regards,
>> Qasim
>>
>>
>> ___
>> 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] VIA relay error using mhomed=1

2013-05-16 Thread Bogdan-Andrei Iancu
And do you have UDP 202.152.203.195 port 6000 as listener defined in
OpenSIPS ??

Regards,

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


On 05/16/2013 12:32 PM, qasimak...@gmail.com wrote:
> Hi Bodgan,
>
> Yes i see the following route header in my packet.
>
> Route:
> 
>
>
> And yes i am routing it through loose_route.
>
> Regards,
> Qasim
>
>
> On Wed, May 15, 2013 at 10:40 PM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hello Qasim,
>
> The ACK should be routed via loose_route() based on the "Route"
> headers from it. Could you check if the Route hdrs (from the ACK)
> are correctly reflecting your opensips interfaces ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/14/2013 07:55 AM, qasimak...@gmail.com
>  wrote:
>> Hi,
>>
>> I am using OpenSIPs in Public<->Private bridging mode and have
>> enabled mhomed=1. But the problem is that when we have a call in
>> which both parties are on Public interface the INVITE gets
>> relayed properly but and ACK of that invite gives the following
>> error.
>>
>> ERROR:core:get_out_socket: no socket found
>> ERROR:core:forward_request: cannot forward to af 2, proto 1 no
>> correspondinglistening socket
>>
>> 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] VIA relay error using mhomed=1

2013-05-16 Thread qasimak...@gmail.com
Hi Bodgan,

Yes i see the following route header in my packet.

Route: 


And yes i am routing it through loose_route.

Regards,
Qasim


On Wed, May 15, 2013 at 10:40 PM, Bogdan-Andrei Iancu
wrote:

> **
> Hello Qasim,
>
> The ACK should be routed via loose_route() based on the "Route" headers
> from it. Could you check if the Route hdrs (from the ACK) are correctly
> reflecting your opensips interfaces ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/14/2013 07:55 AM, qasimak...@gmail.com wrote:
>
>  Hi,
>
>  I am using OpenSIPs in Public<->Private bridging mode and have enabled
> mhomed=1. But the problem is that when we have a call in which both parties
> are on Public interface the INVITE gets relayed properly but and ACK of
> that invite gives the following error.
>
> ERROR:core:get_out_socket: no socket found
> ERROR:core:forward_request: cannot forward to af 2, proto 1 no
> correspondinglistening socket
>
>  Regards,
> Qasim
>
>
> ___
> 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] SIP 3g and a bucket of pain

2013-05-16 Thread Bogdan-Andrei Iancu
Hi Max,

Have you tried to create an account with the VoIP service from
OpenSIPs.org (http://www.opensips.org/Community/VoipService) ? If it
does not work there either, we can take a look at the SIP traffic on our
server to see if we find problems.

Also, have you tried to make a sip capture of the machine where you run
the client ? just to check if the signaling is ok.

Regards,

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


On 05/15/2013 01:09 PM, m...@schneidersoft.net wrote:
> Hello,
>
> I live on a small farm and use a RUT105 from Teltonica to get
> connected to the rest of the world.
> I've got both linux and windows machines running blink, as well as
> some Siemens hardware SIP clients.
> No matter what i do, I can never get SIP to work properly. I can
> register dial and connect, but connections are always one way.
>
> I've got a vps and can get around linux fairly well, but I'm a
> networking noob.
> Can opensips help me fix my SIP problem? maybe a sip proxy on the
> virtual server?
> The RUT105 also supports vpn, does it make any sense to look into that?
>
> Thanks in advance,
> Max Schneider
>
> ___
> 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] Odd opensips REGISTER/INVITE behavior for many simultaneous users

2013-05-16 Thread Bogdan-Andrei Iancu
Hello James,

No, there is no such known bug or issue. What I suspect is that there
are short intervals (milisecs) where an AOR is not registered - this may
happen because :
- the test tool is not performing properly under high load and fails
to do re-register before old registration expires.
- OpenSIPS is overloaded (too few processes ?) and it is not able to
process traffic in realtime (check the LOAD related statistics).

What OpenSIPs versions are you using ?

Regards,

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


On 05/15/2013 01:56 AM, James Tranovich wrote:
> Hello all --
>
> First, we love opensips :)
>
> Lately, we have been running into a strange issue which seems to be
> related to handling a ton of REGISTER messages. Basically, we have a
> test script that tries to simulate about 50 to 100 simultaneous calls;
> they all register en masse and then randomly start placing calls to
> another test number (after a random time interval). Every once in a
> while, though, an INVITE won't go through because opensips apparently
> can't find that phone number. Oddly enough, if we do an "opensipsctl
> online" immediately before/after, that command shows that, in fact,
> the recipient's number is present and presumably already registered.
> SIP logs/ngrep tracing confirm this.
>
> I was wondering if this is a known bug. This behavior only happens
> when registering a certain number of calls at once; if we test with a
> low number of calls (10, say), this behavior does not happen. It may
> be that we are spamming opensips with too many REGISTER messages
> (authentication is required, so two REGISTER messages are sent, the
> first w/o auth, the second with auth). But I don't see why opensips
> should have problems with this.
>
> Any thoughts on this? Is this a known issue already? (Searching for
> this issue didn't yield much). Thanks!
>
> James
>
>
> ___
> 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] Registrar not saving received from Path header

2013-05-16 Thread Bogdan-Andrei Iancu
Hello Nathaniel,

Attached is an extended patch - remove the old one and apply this one.
Again look for any xXx logs .

Regards,

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


On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> here is the output from opensips's og file of the save() with the
> patch and the code snippet from the opensips.cfg. I did not see any
> ant logs with "xXx". Also,I have usrloc's db_mode set to 3.
>
> ##
> # Try to save the Register's requests location information
> ##
>
> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE
> ");
> if (!save("location","p1"))
> {
> xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to
> save Register's request location");
> sl_reply_error();
> }
>
> ##
> # Subscriber's register request was successfully authenticated
> # and saved
> ##
>
> xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has
> successfully registered with Akan Voice");
> exit;
>
>
> Thanks
>
> Nathaniel
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Index: modules/registrar/save.c
===
--- modules/registrar/save.c	(revision 10023)
+++ modules/registrar/save.c	(working copy)
@@ -247,11 +247,14 @@
 		}
 
 		/* extract Path headers */
+		LM_DBG("xXx - flags are %X \n",_flags);
 		if ( _flags®_SAVE_PATH_FLAG ) {
+			LM_DBG("xXx - saving path into usrloc \n");
 			if (build_path_vector(_m, &path, &path_received, _flags) < 0) {
 rerrno = R_PARSE_PATH;
 goto error;
 			}
+			LM_DBG("xXx - path is <%.*s>(%d)\n",path.len,path.s,path.len);
 			if (path.len && path.s) {
 ci.path = &path;
 /* save in msg too for reply */
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Early Media with OpenSIPS

2013-05-16 Thread Bogdan-Andrei Iancu
Hello Kchitiz,

If only called party or both are sending media is up the end-devices
implementation - from SIP and SDP point of view there is no difference -
both end points have the SDP of the other party, so both of them are
able to send and receive RTP (if they want). But be careful of the
sendonly  / recvonly indications in SDP.

>From OpenSIPS + Media relay point of view there is no difference, it
should work with a default NAT traversal script.

Regards,

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


On 05/16/2013 09:30 AM, Kchitiz Saxena wrote:
> Hi
> We are planning to have OpenSIPS working as a proxy in our network and
> MediaProxy as media relay/proxy.
> We have a requirement of early media which is a bit different from
> general or usual early media concept. In my case, the calling party
> and called party need to have a media path before the final answer for
> following:
> 1. Calling party should be able to send video stream and called party
> should be able to receive the same before the called party send a
> final response(2XX) for the INVITE (Lets say after 183)
> 2. Both the parties should be able to send and receive audio streams.
>
> This is different from general early media used in IVR like system
> where only called party sends audio stream to calling party.
>
> Is it possible to have this feature when OpenSIPS is acting as a proxy
> in between and doing things like NAT traversal? Does OpenSIPS require
> any special configuration/change to achieve this?
>
> Thanks
> Kchitiz
>
>
> ___
> 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] Where to place acc_aaa_request ?

2013-05-16 Thread Bogdan-Andrei Iancu
Hi Michele,

The acc_aaa_request() function will generate a RADIUS acc request on the
spot, so it will happen for all your INVITEs disregarding if the calls
will establish or not in the future.

If you want to account only established calls, do not use the
acc_aaa_request() function, but trigger the accounting via flags only.
Use the aaa_flag only (do not set aa_missed_flag) and it should do the
trick.

Regards,

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


On 05/16/2013 10:36 AM, Michele Pinassi wrote:
> Hi all,
>
> here's my acc module config, using radius backend and MySQL.
>
> modparam("acc", "early_media", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "failed_transaction_flag", 3)
> modparam("acc", "log_level", 1)
> modparam("acc", "log_flag", 1)
> modparam("acc", "log_missed_flag", 2)
> modparam("acc", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf")
> modparam("acc", "aaa_flag", 1)
> modparam("acc", "aaa_missed_flag", 2)
> modparam("acc", "aaa_extra",  "via=$hdr(Via[*]); \
>Digest-User-Name=$Au; \
>Calling-Station-Id=$from; \
>Called-Station-Id=$to; \
>Sip-Translated-Request-URI=$ru; \
>Sip-RPid=$avp(s:rpid); \
>Source-IP=$avp(s:source_ip); \
>Source-Port=$avp(s:source_port); \
>SIP-Proxy-IP=$avp(s:sip_proxy_ip); \
>Canonical-URI=$avp(s:can_uri); \
>
> Divert-Reason=$avp(s:divert_reason); \
>User-Agent=$hdr(user-agent); \
>Contact=$hdr(contact); \
>Event=$hdr(event) ;\
>ENUM-TLD=$avp(s:enum_tld)")
>
> my routing logic is:
>
> ### 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 (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;
>   }
>
>   if (is_method("CANCEL"))
>   {
>   if (t_check_trans())
>   t_relay();
>   exit;
>   }
>
>   t_check_trans();
>
>   if (!(method=="REGISTER") && is_from_local())
>   {
>   if(!check_source_address("0")){
>   if (!proxy_authorize("", "subscriber")) {
>   proxy_challenge("", "0");
>   exit;
>   }
>   if (!db_check_from()) {
>   sl_send_reply(

Re: [OpenSIPS-Users] Error 404 not here

2013-05-16 Thread Bogdan-Andrei Iancu
Hello,

For what SIP requests do you get the "404 not here" reply ? Also, are
you using the default opensips cfg file ?

Regards,

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


On 05/16/2013 10:33 AM, sermj 2012 wrote:
> Hi All,
>
> My VoIP clients are registerd with opensips.
> When i tried to call other end client, i can hear only one way audio
> in clients (In caller),somewhere is going wrong and i am not getting
> audio (Voice) in both sides. By using tshark tracer i can see there is
> an '404 not here' status code.
>
> PS: I am working under standalone network infrastructure, and VoIP
> phones are Wi-Fi enabled.
> I just reinstalled my operating system (Ubuntu 10.04) and Opensips for
> several times,but unable to resolve this issue.
>
> what may be the reason for this '404 Not here' issue? and how can i
> solve it?
> Please help me, i have just stuck with this issue from last 15 days.
>
> Find the attachment, which is sip trace file.
>
> I hope you could help me...
>
>
> ___
> 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] Need config file manipulation help

2013-05-16 Thread Bogdan-Andrei Iancu
In this case you should consider configuring multiple TCP interfaces
(listeners) in OpenSIPS and use force_send_socket() core function or $fs
var to select a different one all the time (before sending the call out).

Regards,

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


On 05/16/2013 07:19 AM, Priyaranjan Nayak wrote:
> Hi Bogdan-Andrei Iancu,
>
> yes I need in IP level. While I am running 20cps traffic, it is sending from 
> one port to  server only.so after sometime it will send RST to server. 
> According to server design I need to send from different port for different 
> call.
>
>
>
> Thanks
> Priyaranjan

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


[OpenSIPS-Users] Where to place acc_aaa_request ?

2013-05-16 Thread Michele Pinassi
Hi all,

here's my acc module config, using radius backend and MySQL.

modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
modparam("acc", "detect_direction", 0)
modparam("acc", "failed_transaction_flag", 3)
modparam("acc", "log_level", 1)
modparam("acc", "log_flag", 1)
modparam("acc", "log_missed_flag", 2)
modparam("acc", "aaa_url", "radius:/etc/radiusclient-ng/radiusclient.conf")
modparam("acc", "aaa_flag", 1)
modparam("acc", "aaa_missed_flag", 2)
modparam("acc", "aaa_extra",  "via=$hdr(Via[*]); \
   Digest-User-Name=$Au; \
   Calling-Station-Id=$from; \
   Called-Station-Id=$to; \
   Sip-Translated-Request-URI=$ru; \
   Sip-RPid=$avp(s:rpid); \
   Source-IP=$avp(s:source_ip); \
   Source-Port=$avp(s:source_port); \
   SIP-Proxy-IP=$avp(s:sip_proxy_ip); \
   Canonical-URI=$avp(s:can_uri); \

Divert-Reason=$avp(s:divert_reason); \
   User-Agent=$hdr(user-agent); \
   Contact=$hdr(contact); \
   Event=$hdr(event) ;\
   ENUM-TLD=$avp(s:enum_tld)")

my routing logic is:

### 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 (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;
}

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

t_check_trans();

if (!(method=="REGISTER") && is_from_local())
{
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 INV

[OpenSIPS-Users] Error 404 not here

2013-05-16 Thread sermj 2012
Hi All,

My VoIP clients are registerd with opensips.
When i tried to call other end client, i can hear only one way audio in
clients (In caller),somewhere is going wrong and i am not getting audio
(Voice) in both sides. By using tshark tracer i can see there is an '404
not here' status code.

PS: I am working under standalone network infrastructure, and VoIP phones
are Wi-Fi enabled.
I just reinstalled my operating system (Ubuntu 10.04) and Opensips for
several times,but unable to resolve this issue.

what may be the reason for this '404 Not here' issue? and how can i solve
it?
Please help me, i have just stuck with this issue from last 15 days.

Find the attachment, which is sip trace file.

I hope you could help me...


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