from:"Jai Rangi"

[OpenSIPS-Users] Fragmentation issue

2016-01-23 Thread Jai Rangi

My Previous message got high jacked due to Subject. Posting is again as a
new thread.

Hello,

I have two opensip servers, exactly same configuration, but one is acting
different. This is the call  flow.
Origination -- Invite> Opensips
Origination < 100 Trying -- Opensips
 ---Opensips invite --> End user
(freeswitch)
Opensips <--- 100 trying --
Freeswitch
Opensips <-- 183 Ringing --
Freeswitch
Keeps waiting and never forward 183 back to Origination.

While 2nd opensips works just fine/

MTU is 1500 on both.
Working Server versions
Centos 5.2, Openisps 11-2

Not working, version (Different OS, same version of Opensips)
Cent OS 5.4, Opensips 11-2

Below is the full trace. Any hint to fix this will big help. I am
suspecting fragmented packet size in 183 Session Progress, but not sure how
to fix it. If the packet is not fragmented all works fine.
Did some more testing, if I route the call to another IP, that works
fine. So something very specific to this IP only.

This is original trace, ALL IPs has been modified for security.

 15.43.72.36:5060 -> 29.16.115.170:5060
INVITE sip:+130 at domain.opensips.company.com
:5060;user=phone;transport=UDP;maddr=29.16.115.170
SIP/2.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: 
>*;screen=yes;party=calling;privacy=off.
*f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 15.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 29.16.115.170:5060 -> 15.43.72.36:5060
SIP/2.0 100 Giving a try.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Server: Opensips SIP Gateway.
Content-Length: 0.
.

#
U 29.16.115.170:5060 -> 28.3.8.20:5060
INVITE sip:130 at 28.3.8.20
:5060;user=phone;transport=UDP
SIP/2.0.
Record-Route:
.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: 
>*;screen=yes;party=calling;privacy=off.
*f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 14.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP

[OpenSIPS-Users] Opensips Packet Size Issue

2016-01-23 Thread Jai Rangi

Hello,

I have two opensip servers, exactly same configuration, but one is acting
different. This is the call  flow.
Origination -- Invite> Opensips
Origination < 100 Trying -- Opensips
 ---Opensips invite --> End user
(freeswitch)
Opensips <--- 100 trying --
Freeswitch
Opensips <-- 183 Ringing --
Freeswitch
Keeps waiting and never forward 183 back to Origination.

While 2nd opensips works just fine/

MTU is 1500 on both.
Working Server versions
Centos 5.2, Openisps 11-2

Not working, version (Different OS, same version of Opensips)
Cent OS 5.4, Opensips 11-2

Below is the full trace. Any hint to fix this will big help. I am
suspecting fragmented packet size in 183 Session Progress, but not sure how
to fix it. If the packet is not fragmented all works fine.

This is original trace, ALL IPs has been modified for security.

 15.43.72.36:5060 -> 29.16.115.170:5060
INVITE 
sip:+1304...@domain.opensips.company.com:5060;user=phone;transport=UDP;maddr=29.16.115.170
SIP/2.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: ;screen=yes;party=calling;privacy=off.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 15.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 29.16.115.170:5060 -> 15.43.72.36:5060
SIP/2.0 100 Giving a try.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Server: Opensips SIP Gateway.
Content-Length: 0.
.

#
U 29.16.115.170:5060 -> 28.3.8.20:5060
INVITE sip:130@28.3.8.20:5060;user=phone;transport=UDP SIP/2.0.
Record-Route:
.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: ;screen=yes;party=calling;privacy=off.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 14.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 28.3.8.20:5060 -> 29.16.115.170:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
Via: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Via: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
Via: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Record-Route:
.
Record-Route: .
Record-Route: .
From: ;tag=-45026-1a697ef-67d2935e-1a697ef.
To:

[OpenSIPS-Users] Dialog Replication in Active Active mode

2014-08-07 Thread Jai Rangi

Hello,

I am trying to setup two active active open-sip servers sharing the same
database. Listening on IP 192.168.1.110 (OSP1) and 192.168.1.111 (OSP2)

This is how my dialog configuration looks like.
OSP1
bin_listen = 192.168.1.110:8080
bin_children = 4
loadmodule dialog.so
modparam(dialog, hash_size, 1024)
modparam(dialog, default_timeout, 130)
modparam(dialog, db_url, mysql://dbuser:password@@192.168.1.2/opensips
)
modparam(dialog, db_mode, 0)
modparam(dialog, db_update_period, 60)
modparam(dialog, profiles_with_value, ib ; ob; io)
modparam(dialog, ping_interval, 20)
modparam(dialog, accept_replicated_dialogs, 1)
modparam(dialog, replicate_dialogs_to, 192.168.1.111:8080)


OSP2
bin_listen = 192.168.1.111:8080
bin_children = 4
loadmodule dialog.so
modparam(dialog, hash_size, 1024)
modparam(dialog, default_timeout, 130)
modparam(dialog, db_url, mysql://dbuser:password@@192.168.1.2/opensips
)
modparam(dialog, db_mode, 0)
modparam(dialog, db_update_period, 60)
modparam(dialog, profiles_with_value, ib ; ob; io)
modparam(dialog, ping_interval, 20)
modparam(dialog, accept_replicated_dialogs, 1)
modparam(dialog, replicate_dialogs_to, 192.168.1.110:8080)

When OSP1 get the call, it send the dialog packet to OSP2, OSP2 crashes
with this message in the logs.


Aug  7 09:45:09 localhost /usr/local/opensip/sbin/opensips[20563]:
WARNING:dialog:fetch_socket_info: non-local socket udp:192.168.1.110:5060
...ignoring
Aug  7 09:45:09 localhost /usr/local/opensip/sbin/opensips[20563]:
WARNING:dialog:fetch_socket_info: non-local socket udp:192.168.1.110:5060
...ignoring
Aug  7 09:45:09 localhost /usr/local/opensip/sbin/opensips[20563]:
ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any
listening sockets
Aug  7 09:45:09 localhost /usr/local/opensip/sbin/opensips[20563]:
ERROR:dialog:dlg_replicated_create: Received malformed UDP binary packet!
Aug  7 09:45:09 localhost /usr/local/opensip/sbin/opensips[20563]:
ERROR:dialog:receive_binary_packet: Failed to process a binary packet!
Aug  7 09:45:23 localhost /usr/local/opensip/sbin/opensips[20559]:
INFO:core:handle_sigs: child process 20562 exited by a signal 11
Aug  7 09:45:23 localhost /usr/local/opensip/sbin/opensips[20559]:
INFO:core:handle_sigs: core was generated
Aug  7 09:45:23 localhost /usr/local/opensip/sbin/opensips[20559]:
INFO:core:handle_sigs: terminating due to SIGCHLD
Aug  7 09:45:23 localhost /usr/local/opensip/sbin/opensips[20561]:
INFO:core:sig_usr: signal 15 received
Aug  7 09:45:23 localhost /usr/local/opensip/sbin/opensips[20570]:
INFO:core:sig_usr: signal 15 received


I found two threads with no solutions and from the threads it looks like
dialog replication wont work in active active configuration. It required a
shared IP and will work for failover only.
I will appreciate any suggestions, or if some can share working
configuration.

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

[OpenSIPS-Users] DTMF Detection in RTP-Proxy

2014-07-29 Thread Jai Rangi

Hello,

I am working on setting up freeswitch and opensips integrations. Actually
followed this link.

http://www.opensips.org/Documentation/Tutorials-OpenSIPSFreeSwitchIntegration

Everything worked right out of the box with minor tweeks here and there.
Thank you

*Giovanni Maruzzelli *
I am stuck at passing DTMF digits to freeswitch when two UAs  are in the
middle of conversations. Say user A called user B. Now user B want to park
the call by pressing *8500, so that user C can pick up the call by pressing
*8501. During this time user A should be on hold listening to music etc.

Any idea what would be best approach to achieve this. All UAs are
registered on Opensips.

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

Re: [OpenSIPS-Users] How to send SIP header 302 registration request to Asterisk

2009-12-17 Thread Jai Rangi

Getting some ngrep traces will help some other to help you. Unauthorized
message is for useraccount or for opensip.
-Jai


On Thu, Dec 17, 2009 at 10:25 PM, Ahmed Munir ahmedmunir...@gmail.comwrote:

 Hi,

 I'm using OpenSIPs version 1.6, the module I'm using is dispatcher using
 mysql. My question is how can I send SIP header 302 registration request to
 Asterisk? Because Asterisk is sending me unAuthorized message to OpenSIPs.
 Even the credentials I'm using for Asterisk is the same as I'm using for
 OpenSIPs.


 Kindly advise me to resolve this issue.

 --
 Regards,

 Ahmed Munir



 ___
 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] CDRTool 6.9.9 with OpenSIPS 1.6 Issue - No Trusted DB Table

2009-12-15 Thread Jai Rangi

There is no trusted table in 1.6. All the entries goes to address table.
Need to add fix/update to CDRTool..

-Jai

On Tue, Dec 15, 2009 at 12:09 PM, osiris123d duane.lar...@gmail.com wrote:


 I am trying to set up CDRTool on Ubuntu from source and was almost done,
 but
 I am not able to get into the CDRTool webpage because I am getting the
 following error
 Database error: Invalid SQL: select * from trusted MySQL error: 1146 (Table
 'opensips.trusted' doesn't exist) 59Session halted.

 I see that OpenSIPS 1.6 no longer has the Trusted table in its database.
  Is
 there a workaround for this?
 --
 View this message in context:
 http://n2.nabble.com/CDRTool-6-9-9-with-OpenSIPS-1-6-Issue-No-Trusted-DB-Table-tp4171857p4171857.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] Issue with call routing due to maddr

2009-12-14 Thread Jai Rangi

**snip***
So, I see here 2 issues (bugs):

1) why the A device places in RURI maddr  its own IP  RURI points to
destination, so no info about source should be there. Typically maddr is
used in building Contact hdrs.

2) opensips should automatically remove the maddr param when the script
function do change the domain part of the RURI - logically speaking, if
you want to change the destination, all fields with destination info
should be affected.
 snip ***

Indeed.
For now the quick fix was to remove maddr just before relaying the call. I
could have update $du as a work around, but that would have caused the issue
with next hope using opensip.
Either one of these 2 can do that trick
if($(ru{uri.maddr}) != ) {
$du = sip: + $rU + @ + $rd + : + $rp ;
OR
$ru = sip: + $rU + @ + $rd + : + $rp +;user=phone;transport=UDP;  //
I prefered this one.

But ultimately would be nice to see the fix in module itself. Just pushed
this to production, so far things looks good. Hope I will have good night
sleep and happy morning :)

Best,

-Jai





On Mon, Dec 14, 2009 at 2:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro
 wrote:

 Hi Jai,

 Jai Rangi wrote:
  I found another discussion on this,
  http://www.openser.org/pipermail/users/2007-July/012258.html
 Correct :)
 
  Again specially in this case it does not make sense at all to send
  call to maddr in place of host in the domain.
 yes, I agree - I suggest you remove the maddr param from the RURI.
 
  Say this is the desired scenario
 
  A - B(Opensips1.6) - C
 
  - If A send call to B with maddr the call works perfect and goes to C.
 This works because lookup(location) replace the entire RURI  (including
 the maddr), so the maddr is simply discarded.

  - But if A send call to B with maddres B send invite back to A (Does
  not make any sense)
 If you just change the domain part (as drouting does) of the RURI, the
 maddr param is preserved and will break the outbound routing of the call.

 So, I see here 2 issues (bugs):

 1) why the A device places in RURI maddr  its own IP  RURI points to
 destination, so no info about source should be there. Typically maddr is
 used in building Contact hdrs.

 2) opensips should automatically remove the maddr param when the script
 function do change the domain part of the RURI - logically speaking, if
 you want to change the destination, all fields with destination info
 should be affected.

 Regards,
 Bogdan




 
  Also in another case
 
  A Send call to B'is IP on some domain (Domain is in the table)
  B is not updating the maddr in the SIP header but update domain part
  of uri and sending call back to itself because of maddr and resulting
  in 403 Forbidden here.
 
  U 192.168.2.11:5060 http://192.168.2.11:5060 - 192.168.2.21:5060
  http://192.168.2.21:5060
  INVITE
  sip:19498859...@somedomain.com:5060
 ;user=phone;transport=UDP;maddr=192.168.2.21
  SIP/2.0.
 
  Call processed through routing module found the rule that
  19498859944 should be forwarded to 192.168.2.30
 
  After loading the dr_load
  $ru is
  sip:19498859...@192.168.2.30 sip%3a19498859...@192.168.2.30
  mailto:sip%3a19498859...@192.168.2.30sip%253a19498859...@192.168.2.30
 ;user=phone;transport=UDP;maddr=192.168.2.21
 
  t_relay send call to 192.168.2.21 and call fails in the (is_uri_local)
  cause it does not find 192.168.2.30 in the domain table. If you add
  192.168.2.30 in the domain table that will create a loop cause maddr
  is never going to get update. :(
 
  Now I think this is bug here in drouting module, which is not updating
  the maddr. I believe the new $ru should be
  sip:19498859...@192.168.2.30 sip%3a19498859...@192.168.2.30
  mailto:sip%3a19498859...@192.168.2.30sip%253a19498859...@192.168.2.30
 ;user=phone;transport=UDP;maddr=192.168.2.30
 
 
  Hope I gave good example, any thoughts?
  So either t_relay should not send call to maddr.
  Or maddr should be updated in the drouting module as well as LCR and
  carrier route modules.
 
  I believe this can be fixed in the script itself. Looking for better
  suggestions.
 
 
  -Jai
 
 
 
 
  On Sun, Dec 13, 2009 at 12:12 PM, Jai Rangi jpra...@didforsale.com
  mailto:jpra...@didforsale.com wrote:
 
  I am having issue with call routing in certain situation. I am
  using drouting module and permission module for authentications.
 
  Here is the trace
 
  * # Call comes from 192.168.1.11 to 192.168.1.11*
 
  U 192.168.1.11:5060 http://192.168.1.11:5060 -
  192.168.1.13:5060 http://192.168.1.13:5060
 
  INVITE
  sip:19498858...@192.168.1.13:5060
 ;user=phone;transport=UDP;maddr=192.168.1.11
  SIP/2.0.
 
  Record-Route:
  sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on.
 
  Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.
 
  v: SIP/2.0/UDP
  65.243.172.245:5060
 ;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.
 
  Record-Route: sip:65.243.172.245:5060;lr.
 
  v: SIP/2.0

[OpenSIPS-Users] Issue with call routing due to maddr

2009-12-13 Thread Jai Rangi

I am having issue with call routing in certain situation. I am using
drouting module and permission module for authentications.

Here is the trace

* # Call comes from 192.168.1.11 to 192.168.1.11*

U 192.168.1.11:5060 - 192.168.1.13:5060

INVITE 
sip:19498858...@192.168.1.13:5060;user=phone;transport=UDP;maddr=192.168.1.11
SIP/2.0.

Record-Route: sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on.

Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.

v: SIP/2.0/UDP 65.243.172.245:5060
;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.

Record-Route: sip:65.243.172.245:5060;lr.

v: SIP/2.0/UDP 63.110.102.239:5060
;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.

record-route: sip:63.110.102.239;lr.

Remote-Party-ID:
sip:+19496794...@63.110.102.239sip%3a%2b19496794...@63.110.102.239
;screen=yes;party=calling;privacy=off.

f: sip:+19496794...@199.173.94.144:5060
;user=phone;tag=dc7-13c4-5db56e-28caa21e-5db56e.

t: sip:+19498858...@63.110.102.239:5060;user=phone.

i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.

CSeq: 1 INVITE.

Max-Forwards: 16.

k: 100rel, replaces.

allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.

v: SIP/2.0/UDP
SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.

m: sip:199.173.94.144:5060;transport=UDP.

c: application/SDP.

l: 233.

.

v=0.

o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.

s=-.

p=+1 613555.

c=IN IP4 199.173.77.34.

t=0 0.

m=audio 55632 RTP/AVP 18 0 8 101.

a=rtpmap:101 telephone-event/8000.

a=fmtp:101 0-15.

a=ptime:20.

a=fmtp:18 annexb=no.



#

U 192.168.1.13:5060 - 192.168.1.11:5060

SIP/2.0 100 Giving a try.

Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.

v: SIP/2.0/UDP 65.243.172.245:5060
;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.

v: SIP/2.0/UDP 63.110.102.239:5060
;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.

f: sip:+19496794...@199.173.94.144:5060
;user=phone;tag=dc7-13c4-5db56e-28caa21e-5db56e.

t: sip:+19498858...@63.110.102.239:5060;user=phone.

i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.

CSeq: 1 INVITE.

v: SIP/2.0/UDP
SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.

Server: OpenSIPS (1.6.0-notls (x86_64/linux)).

Content-Length: 0.

.
*
 According to drouting rules, call should be going to 192.168.1.3, but
somehow opensips is updating the maddress to the origination IP
(192.168.1.11 in this case) and is sending calls to *the IP in maddr. in
place to destination IP.

# Sending invite to originating IP.

*U 192.168.1.13:5060 - 192.168.1.11:5060
*
*INVITE sip:19498858...@192.168.1.3
sip%3a19498858...@192.168.1.3;user=phone;transport=UDP;maddr=192.168.1.11
SIP/2.0.*

Record-Route: sip:192.168.1.13;lr=on;ftag=dc7-13c4-5db56e-28caa21e-5db56e.

Record-Route: sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on.

Via: SIP/2.0/UDP 192.168.1.13;branch=z9hG4bK2c7a.cb3da61.0.

Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.

v: SIP/2.0/UDP 65.243.172.245:5060
;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.

Record-Route: sip:65.243.172.245:5060;lr.

v: SIP/2.0/UDP 63.110.102.239:5060
;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.

record-route: sip:63.110.102.239;lr.

Remote-Party-ID:
sip:+19496794...@63.110.102.239sip%3a%2b19496794...@63.110.102.239
;screen=yes;party=calling;privacy=off.

f: sip:+19496794...@199.173.94.144:5060
;user=phone;tag=dc7-13c4-5db56e-28caa21e-5db56e.

t: sip:+19498858...@63.110.102.239:5060;user=phone.

i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.

CSeq: 1 INVITE.

Max-Forwards: 15.

k: 100rel, replaces.

allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.

v: SIP/2.0/UDP
SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.

m: sip:199.173.94.144:5060;transport=UDP.

c: application/SDP.

l: 233.

.

v=0.

o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.

s=-.

p=+1 613555.

c=IN IP4 199.173.77.34.

t=0 0.

m=audio 55632 RTP/AVP 18 0 8 101.

a=rtpmap:101 telephone-event/8000.

a=fmtp:101 0-15.

a=p

#

My Routing logic is quite simple.

if (is_uri_host_local()) {
   # -- outbound to inbound
route(12);
}


route[4] {
#Routing to Public Network

if (!do_routing(10,1)) {
xlog(-- do_routing failed  \n);
sl_send_reply(503, Unable to load gateways);
exit ;
} else {
t_on_failure(1);  #--- This will be where you load the
nextgateway
route(1);
exit;
   };
} # End Route 4

route[12] {
# From an External Domain - inbound

lookup(aliases);
if (!lookup(location)) {
route(4);
exit ;
}

Re: [OpenSIPS-Users] Issue with call routing due to maddr

2009-12-13 Thread Jai Rangi

I found another discussion on this,
http://www.openser.org/pipermail/users/2007-July/012258.html

Again specially in this case it does not make sense at all to send call to
maddr in place of host in the domain.

Say this is the desired scenario

A - B(Opensips1.6) - C

- If A send call to B with maddr the call works perfect and goes to C.
- But if A send call to B with maddres B send invite back to A (Does not
make any sense)

Also in another case

A Send call to B'is IP on some domain (Domain is in the table)
B is not updating the maddr in the SIP header but update domain part of uri
and sending call back to itself because of maddr and resulting in 403
Forbidden here.

U 192.168.2.11:5060 - 192.168.2.21:5060
INVITE 
sip:19498859...@somedomain.com:5060;user=phone;transport=UDP;maddr=192.168.2.21
SIP/2.0.

Call processed through routing module found the rule that
19498859944 should be forwarded to 192.168.2.30

After loading the dr_load
$ru is
sip:19498859...@192.168.2.30 sip%3a19498859...@192.168.2.30
;user=phone;transport=UDP;maddr=192.168.2.21

t_relay send call to 192.168.2.21 and call fails in the (is_uri_local) cause
it does not find 192.168.2.30 in the domain table. If you add 192.168.2.30
in the domain table that will create a loop cause maddr is never going to
get update. :(

Now I think this is bug here in drouting module, which is not updating the
maddr. I believe the new $ru should be
sip:19498859...@192.168.2.30
sip%3a19498859...@192.168.2.30;user=phone;transport=UDP;maddr=192.168.2.30


Hope I gave good example, any thoughts?
So either t_relay should not send call to maddr.
Or maddr should be updated in the drouting module as well as LCR and carrier
route modules.

I believe this can be fixed in the script itself. Looking for better
suggestions.


-Jai




On Sun, Dec 13, 2009 at 12:12 PM, Jai Rangi jpra...@didforsale.com wrote:

 I am having issue with call routing in certain situation. I am using
 drouting module and permission module for authentications.

 Here is the trace

 * # Call comes from 192.168.1.11 to 192.168.1.11*

 U 192.168.1.11:5060 - 192.168.1.13:5060

 INVITE 
 sip:19498858...@192.168.1.13:5060;user=phone;transport=UDP;maddr=192.168.1.11
 SIP/2.0.

 Record-Route:
 sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on.

 Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.

 v: SIP/2.0/UDP 65.243.172.245:5060
 ;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.

 Record-Route: sip:65.243.172.245:5060;lr.

 v: SIP/2.0/UDP 63.110.102.239:5060
 ;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.

 record-route: sip:63.110.102.239;lr.

 Remote-Party-ID: 
 sip:+19496794...@63.110.102.239sip%3a%2b19496794...@63.110.102.239
 ;screen=yes;party=calling;privacy=off.

 f: sip:+19496794...@199.173.94.144:5060
 ;user=phone;tag=dc7-13c4-5db56e-28caa21e-5db56e.

 t: sip:+19498858...@63.110.102.239:5060;user=phone.

 i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.

 CSeq: 1 INVITE.

 Max-Forwards: 16.

 k: 100rel, replaces.

 allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.

 v: SIP/2.0/UDP
 SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.

 m: sip:199.173.94.144:5060;transport=UDP.

 c: application/SDP.

 l: 233.

 .

 v=0.

 o=PVG 1260705241820 1260705241820 IN IP4 199.173.77.34.

 s=-.

 p=+1 613555.

 c=IN IP4 199.173.77.34.

 t=0 0.

 m=audio 55632 RTP/AVP 18 0 8 101.

 a=rtpmap:101 telephone-event/8000.

 a=fmtp:101 0-15.

 a=ptime:20.

 a=fmtp:18 annexb=no.



 #

 U 192.168.1.13:5060 - 192.168.1.11:5060

 SIP/2.0 100 Giving a try.

 Via: SIP/2.0/UDP 192.168.1.11;branch=z9hG4bK2c7a.d24c40b5.0.

 v: SIP/2.0/UDP 65.243.172.245:5060
 ;branch=z9hG4bK31c0ba996f394d817b1f3364936c1b88.4a620e1.

 v: SIP/2.0/UDP 63.110.102.239:5060
 ;branch=z9hG4bK4be83d023d1c5e705dbce69dc257428e.61c8be4a;received=63.110.102.239.

 f: sip:+19496794...@199.173.94.144:5060
 ;user=phone;tag=dc7-13c4-5db56e-28caa21e-5db56e.

 t: sip:+19498858...@63.110.102.239:5060;user=phone.

 i: a1d74c18905eadc713c45db56e6e0cb7e4a9d9a091cba8848-0096-6871.

 CSeq: 1 INVITE.

 v: SIP/2.0/UDP
 SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-5db56e-6e0cb7e4-3dc36a18;received=199.173.94.144.

 Server: OpenSIPS (1.6.0-notls (x86_64/linux)).

 Content-Length: 0.

 .
 *
  According to drouting rules, call should be going to 192.168.1.3, but
 somehow opensips is updating the maddress to the origination IP
 (192.168.1.11 in this case) and is sending calls to *the IP in maddr. in
 place to destination IP.

 # Sending invite to originating IP.

 *U 192.168.1.13:5060 - 192.168.1.11:5060
 *
 *INVITE sip:19498858...@192.168.1.3 
 sip%3a19498858...@192.168.1.3;user=phone;transport=UDP;maddr=192.168.1.11
 SIP/2.0.*

 Record-Route:
 sip:192.168.1.13;lr=on;ftag=dc7-13c4-5db56e-28caa21e-5db56e.

 Record-Route:
 sip:192.168.1.11;ftag=dc7-13c4-5db56e-28caa21e-5db56e;lr=on.

 Via: SIP/2.0/UDP 192.168.1.13;branch

Re: [OpenSIPS-Users] Issue with permission module in opensip 1.6

2009-12-11 Thread Jai Rangi

Yes, Now I am not getting that issue any more. The change in hash table
fixed the issue.
Thanks a lot.

For  printing warning I changed this
LM_DBG(invalid ip field in address table, ignoring entry %d, %s\n, i,
str_src_ip.s);
to
LM_WARN(invalid ip field in address table, ignoring entry %d, %s\n, i,
str_src_ip.s);

I like the fact that this will spit the warning in log file even I am not
running in debug more.

Will do some more testing.

Again thank you so much.

-Jai



On Fri, Dec 11, 2009 at 1:46 AM, Irina Stanescu istane...@opensips.orgwrote:

 Hi Jai,

 As you suggested, i added the id of the entry to the debug info for
 ignored entries .

 Also, i committed a fix for the other problem you had with
 check_source_address. Please update from SVN and let me know if you find
 any other issues.


 Regards,
 Irina Stanescu


 Jai Rangi wrote:
  Excellent, I owe you one.
 
  As always users always want more and more ;)
  I got this in the logs when I try to
  Dec 10 13:55:02 [11176] DBG:permissions:reload_address_table: invalid
  ip field in address table, ignoring entry 0
  Dec 10 13:55:02 [11176] DBG:permissions:reload_address_table: invalid
  ip field in address table, ignoring entry 1
 
  Here ID or IPAddress will be more useful for debugging purpose.
 
  Here is the trace for the failing call form same IP.
 
  Dec 10 14:03:09 [11772] DBG:core:parse_via: end of header reached,
 state=5
  Dec 10 14:03:09 [11772] DBG:core:parse_headers: via found, flags=200
  Dec 10 14:03:09 [11772] DBG:core:get_hdr_field: content_length=235
  Dec 10 14:03:09 [11772] DBG:core:get_hdr_field: found end of header
  Dec 10 14:03:09 [11772] DBG:rr:find_first_route: No Route headers found
  Dec 10 14:03:09 [11772] DBG:rr:loose_route: There is no Route HF
   source ip is 65.211.120.237 and protocol is udp avp is null
  Dec 10 14:03:09 [11772] DBG:permissions:check_src_addr_3: Looking for
  : 0, 65.211.120.237, 5060, 1 in tables
  Dec 10 14:03:09 [11772] DBG:permissions:hash_match: no match in the
  hash table
  Dec 10 14:03:09 [11772] DBG:permissions:match_subnet_table: subnet
  table is empty
  Monitor Request not from trusted source from
  sip:+19496794...@199.173.94.144:5060;user=phone to
  sip:+19493334...@209.216.2.213:5060;user=phone;transport=UDP from IP
  65.211.120.237 Dec 10 14:03:09 [11772] DBG:core:parse_headers:
  flags=
  Dec 10 14:03:09 [11772] DBG:core:parse_headers: flags=
  Dec 10 14:03:09 [11772] DBG:core:check_ip_address: params
  65.211.120.237, 65.211.120.237, 0
  Dec 10 14:03:09 [11772] DBG:core:destroy_avp_list: destroying list (nil)
  Dec 10 14:03:09 [11772] DBG:core:receive_msg: cleaning up
  Dec 10 14:03:09 [11771] DBG:core:parse_msg: SIP Request:
 
  Dump from address cache
   ../../sbin/opensipsctl fifo address_dump | grep 65.211.120.237
12 65.211.120.237,0, 0, 0, ^sip:.*$, NULL
 
  Code in cfg file
   xlog( source ip is $si and protocol is $proto avp is $avp(i:9));
   if (check_source_address(0,$avp(i:9))) {
 
  Same Call from other IP works juts IP
 
  Dec 10 14:08:16 [11776] DBG:rr:loose_route: There is no Route HF
   source ip is 65.217.40.210 and protocol is udp avp is null
  Dec 10 14:08:16 [11776] DBG:permissions:check_src_addr_3: Looking for
  : 0, 65.217.40.210, 5060, 1 in tables
  Dec 10 14:08:16 [11776] DBG:permissions:hash_match: match found in the
  hash table
 
  ../../sbin/opensipsctl fifo address_dump | grep 65.217.40.210
 9 65.217.40.210,0, 0, 0, ^sip:.*$, NULL
 
  Best,
 
  -Jai
 
  On Thu, Dec 10, 2009 at 8:19 AM, Irina Stanescu
  istane...@opensips.org mailto:istane...@opensips.org wrote:
 
  Hi Jai,
 
  I modified the permissions module so that now any invalid db entry
  from
  the address table is skipped.
  I committed the change on trunk and also on the 1.6 branch.
 
  About the other issue you have found, what does the log say?
 
 
 
  Regards,
  Irina Stanescu
 
 
  Jai Rangi wrote:
   Bogda,
   Wow that was quick. Thank you,
  
   I found one more issue,
   I have this entry in address table
   944   0   65.211.120.237  32  0   any ^sip:.*$
   /NULL/  0   some
   descriptiond
  
  
   Here is a check in my route block
if (check_source_address(0,$avp(i:9))) {
  t_rely();
   } else {
 xlog(Monitor Request not from trusted source from $fu to $ru
 from
   IP $si );
  sl_send_reply(403, Forbidden, we dont trust you);
   }
  
   ../../sbin/opensipsctl fifo address_dump | grep 65.211.120.237
  
   12 65.211.120.237,0, 0, 0, ^sip:.*$, NULL
  
   I always get 403.
   Is there a limit in address table.
  
   -Jai
  
  
   On Thu, Dec 10, 2009 at 12:24 AM, Bogdan-Andrei Iancu
   bog...@voice-system.ro mailto:bog...@voice-system.ro
  mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro
  wrote:
  
   Hi Jai

Re: [OpenSIPS-Users] Issue with permission module in opensip 1.6

2009-12-10 Thread Jai Rangi

Bogda,
Wow that was quick. Thank you,

I found one more issue,
I have this entry in address table
944 0 65.211.120.237 32 0 any ^sip:.*$ *NULL* 0 some descriptiond
Here is a check in my route block
 if (check_source_address(0,$avp(i:9))) {
   t_rely();
} else {
  xlog(Monitor Request not from trusted source from $fu to $ru from IP $si
);
   sl_send_reply(403, Forbidden, we dont trust you);
}

../../sbin/opensipsctl fifo address_dump | grep 65.211.120.237

12 65.211.120.237,0, 0, 0, ^sip:.*$, NULL

I always get 403.
Is there a limit in address table.

-Jai


On Thu, Dec 10, 2009 at 12:24 AM, Bogdan-Andrei Iancu 
bog...@voice-system.ro wrote:

 Hi Jai,

 I think you are correct - the permission table should also be more
 permissive when comes to the errors and skip bogus entries. I will ask
 the maintainer (Irina) to fix this problem.

 Thanks for the report,
 Bogdan

 Jai Rangi wrote:
  Not sure if this this the right place for this post. May be I should
  post it on developers mailing list.  Please suggest.
 
  Just installed opensip1.6 with Mysql, drouting and permissions module.
  Did not take long to get it configure and get it going. Documentations
  is wonderful.
  While testing I noticed that,
 
  1. If there is any invalid entry in dr_routing tables, and I reload
  the dr_routing it spit the error for the mistyped/wrong entry and
  loads rest of the valid entries. Same thing with startup. Opensip will
  start up just fine even if there are some invalid rules in the table
  and throws the error with ruleid.
 
  2. On the other hand address table does not work that way. If there is
  any space (Typo) in the IP address, opensip wont start and wont reload
  the address table.
  I have to put the valid IP address, there is not option for dynamic
  domain names. (For people who does not have static IP). Not only that
  it does not even tell which IP has a problem that makes it even harder
  to debug when you have thousands of IPs in the trusted tables.
 
  I was wondering if there is a work around for this. I would like
  opensip to startup (or successful address_reload) with all the valid
  entries and throw an error for invalid entries. Also having the
  ability to add an domain would be nice.
 
  Any thoughts??
 
  -Jai
 
 
 
 
 
 
  
 
  ___
  Users mailing list
  Users@lists.opensips.org
  http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 


 --
 Bogdan-Andrei Iancu
 www.voice-system.ro


 ___
 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] Issue with permission module in opensip 1.6

2009-12-10 Thread Jai Rangi

Excellent, I owe you one.

As always users always want more and more ;)
I got this in the logs when I try to
Dec 10 13:55:02 [11176] DBG:permissions:reload_address_table: invalid ip
field in address table, ignoring entry 0
Dec 10 13:55:02 [11176] DBG:permissions:reload_address_table: invalid ip
field in address table, ignoring entry 1

Here ID or IPAddress will be more useful for debugging purpose.

Here is the trace for the failing call form same IP.

Dec 10 14:03:09 [11772] DBG:core:parse_via: end of header reached, state=5
Dec 10 14:03:09 [11772] DBG:core:parse_headers: via found, flags=200
Dec 10 14:03:09 [11772] DBG:core:get_hdr_field: content_length=235
Dec 10 14:03:09 [11772] DBG:core:get_hdr_field: found end of header
Dec 10 14:03:09 [11772] DBG:rr:find_first_route: No Route headers found
Dec 10 14:03:09 [11772] DBG:rr:loose_route: There is no Route HF
 source ip is 65.211.120.237 and protocol is udp avp is null
Dec 10 14:03:09 [11772] DBG:permissions:check_src_addr_3: Looking for : 0,
65.211.120.237, 5060, 1 in tables
Dec 10 14:03:09 [11772] DBG:permissions:hash_match: no match in the hash
table
Dec 10 14:03:09 [11772] DBG:permissions:match_subnet_table: subnet table is
empty
Monitor Request not from trusted source from
sip:+19496794...@199.173.94.144:5060;user=phone to
sip:+19493334...@209.216.2.213:5060;user=phone;transport=UDP from IP
65.211.120.237 Dec 10 14:03:09 [11772] DBG:core:parse_headers:
flags=
Dec 10 14:03:09 [11772] DBG:core:parse_headers: flags=
Dec 10 14:03:09 [11772] DBG:core:check_ip_address: params 65.211.120.237,
65.211.120.237, 0
Dec 10 14:03:09 [11772] DBG:core:destroy_avp_list: destroying list (nil)
Dec 10 14:03:09 [11772] DBG:core:receive_msg: cleaning up
Dec 10 14:03:09 [11771] DBG:core:parse_msg: SIP Request:

Dump from address cache
 ../../sbin/opensipsctl fifo address_dump | grep 65.211.120.237
  12 65.211.120.237,0, 0, 0, ^sip:.*$, NULL

Code in cfg file
 xlog( source ip is $si and protocol is $proto avp is $avp(i:9));
 if (check_source_address(0,$avp(i:9))) {

Same Call from other IP works juts IP

Dec 10 14:08:16 [11776] DBG:rr:loose_route: There is no Route HF
 source ip is 65.217.40.210 and protocol is udp avp is null
Dec 10 14:08:16 [11776] DBG:permissions:check_src_addr_3: Looking for : 0,
65.217.40.210, 5060, 1 in tables
Dec 10 14:08:16 [11776] DBG:permissions:hash_match: match found in the hash
table

../../sbin/opensipsctl fifo address_dump | grep 65.217.40.210
   9 65.217.40.210,0, 0, 0, ^sip:.*$, NULL

Best,

-Jai

On Thu, Dec 10, 2009 at 8:19 AM, Irina Stanescu istane...@opensips.orgwrote:

 Hi Jai,

 I modified the permissions module so that now any invalid db entry from
 the address table is skipped.
 I committed the change on trunk and also on the 1.6 branch.

 About the other issue you have found, what does the log say?



 Regards,
 Irina Stanescu


 Jai Rangi wrote:
  Bogda,
  Wow that was quick. Thank you,
 
  I found one more issue,
  I have this entry in address table
  944   0   65.211.120.237  32  0   any ^sip:.*$
  /NULL/  0   some
  descriptiond
 
 
  Here is a check in my route block
   if (check_source_address(0,$avp(i:9))) {
 t_rely();
  } else {
xlog(Monitor Request not from trusted source from $fu to $ru from
  IP $si );
 sl_send_reply(403, Forbidden, we dont trust you);
  }
 
  ../../sbin/opensipsctl fifo address_dump | grep 65.211.120.237
 
  12 65.211.120.237,0, 0, 0, ^sip:.*$, NULL
 
  I always get 403.
  Is there a limit in address table.
 
  -Jai
 
 
  On Thu, Dec 10, 2009 at 12:24 AM, Bogdan-Andrei Iancu
  bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
 
  Hi Jai,
 
  I think you are correct - the permission table should also be more
  permissive when comes to the errors and skip bogus entries. I will
 ask
  the maintainer (Irina) to fix this problem.
 
  Thanks for the report,
  Bogdan
 
  Jai Rangi wrote:
   Not sure if this this the right place for this post. May be I
 should
   post it on developers mailing list.  Please suggest.
  
   Just installed opensip1.6 with Mysql, drouting and permissions
  module.
   Did not take long to get it configure and get it going.
  Documentations
   is wonderful.
   While testing I noticed that,
  
   1. If there is any invalid entry in dr_routing tables, and I reload
   the dr_routing it spit the error for the mistyped/wrong entry and
   loads rest of the valid entries. Same thing with startup.
  Opensip will
   start up just fine even if there are some invalid rules in the
 table
   and throws the error with ruleid.
  
   2. On the other hand address table does not work that way. If
  there is
   any space (Typo) in the IP address, opensip wont start and wont
  reload
   the address table.
   I have to put the valid IP address, there is not option for dynamic
   domain names. (For people who

[OpenSIPS-Users] Fragmentation issue

[OpenSIPS-Users] Opensips Packet Size Issue

[OpenSIPS-Users] Dialog Replication in Active Active mode

[OpenSIPS-Users] DTMF Detection in RTP-Proxy

Re: [OpenSIPS-Users] How to send SIP header 302 registration request to Asterisk

Re: [OpenSIPS-Users] CDRTool 6.9.9 with OpenSIPS 1.6 Issue - No Trusted DB Table

Re: [OpenSIPS-Users] Issue with call routing due to maddr

[OpenSIPS-Users] Issue with call routing due to maddr

Re: [OpenSIPS-Users] Issue with call routing due to maddr

Re: [OpenSIPS-Users] Issue with permission module in opensip 1.6

Re: [OpenSIPS-Users] Issue with permission module in opensip 1.6

Re: [OpenSIPS-Users] Issue with permission module in opensip 1.6

12 matches

Site Navigation

Mail list logo

Footer information