Re: [OpenSIPS-Users] How to recalculate ha1 and ha1b

[DangVinh Nguyen]

 Hi Dioris

Thanks a lot for your tip.

When I calculated ha1 the first time,I missed the colon between fields. It
must be included in the hash.

Regards
DangVinh

On Fri, Jul 10, 2009 at 10:40 PM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:

> Hi Dioris,
>
> Could you upload this on the web site (TIPS section) for other people
> benefit ? See: http://www.opensips.org/Resources/Documentation#toc4
>
> If you create an account on the web site, you are free to edit the content.
>
> Thanks and regards,
> Bogdan
>
>
>
> Dioris Moreno wrote:
> > When you change the domain column in the subscriber table, you have to
> > recalculate ha1 and ha1b fields. In order to do that you must have the
> > password of each subscriber. It is stored in the 'password' column if
> > you have set STORE_PLAINTEXT_PW=1 in opensipsctlrc (default).
> >
> > HA1 is a MD5 hash of "username:domain:password". For example, if you
> > have created a SIP account 1...@mydomain.com
> >  using password 123456, then HA1 is the MD5
> > hash of "1000:mydomain.com:123456 "
> > (without quotes). On the other hand HA1B is the MD5 hash of
> > "usern...@domain:domain:password"; so using the same example above,
> > HA1B would be the MD5 hash of "1...@mydomain.com:mydomain.com:123456
> > " (without quotes).
> >
> > So, to recalculate and update ha1 and ha1b columns in the subscriber
> > table, just execute the following sql statement in mysql:
> >
> > update subscriber
> > set ha1 = md5(concat(username, ':', domain, ':', password)),
> > ha1b = md5(concat(username, '@', domain, ':', domain, ':', password))
> >
> > I hope this could be useful.
> >
> > Regards,
> >
> > Dioris
> >
> > 
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CDRTool - Rating engine does not rate

[ASHWINI NAIDU]

Have you populated all the relavent data needed for CDRTool rating
Destinations table,customers, prfiles and rates.

if yes. Delete the entries in Your memcache table and restart ur rating
engine and try to get search again. I guess this should work.


On Sat, Jul 11, 2009 at 3:21 AM, Alberto Listas  wrote:

> Hi,
>
> I have installed OpenSips 1.5.1, FreeRadius 2.1.6, CDRTool 6.8.0. The calls
> work but they all appear as
> free in CDRTool. I am using the standard customer and rate tables that come
> with the
> software. When I telnet to the rating engine and use the example in the
> documentation
> I get the result below:
>
> ShowPrice From=sip:1...@example.com  To=
> sip:0031650222...@example.com 
> Gateway=10.0.0.1 Duration=59
> 0
> Duration: 59 s
> App: audio
> Destination: 31650
> Customer: domain=example.com
> (And nothing else...)
>
> I don't get a price and the /var/log/syslog displays this error:
>
> Jul 10 18:28:49 os2 cdrtool[11392]: Error: Cannot find rates for callid=,
> billing party=...@example.com, customer domain=example.com,
> gateway=10.0.0.1, destination=31650, profile=grn_premium, app=audio
>
> I don't see the error. There is an entry in customers for the domain
> example.com, there
> is a rate for destination 31650. But the rating engine does find any.
>
> Anybody has a suggestion???
>
> Thanks,
>
> Alberto
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] nat_traversal fails on loose_route ACK

[Jeff Pyle]

¡Easy indeed!  I didn't have any NAT intelligence in the reply route.

Here's what I tried first:

onreply_route[1] {
if (client_nat_test("3")) {
xlog("L_INFO", "NAT Reply\n");
fix_contact();
} else {
xlog("L_INFO", "Reply\n");
}
}

This appeared to work a bit "too" well.  The client_nat_test returned true
even for non-NAT'd hosts.  I changed the test from "3" to "1" and it seems
to be behaving as expected.

None of the examples seem to use the number 4 "private IP address in the top
Via field" test.  Is there any particular reason for that?  In my searches I
haven't come across a discussion on the pros and cons of the various tests.


- Jeff
 


On 7/10/09 5:03 PM, "Iñaki Baz Castillo"  wrote:

> Easy: you must ensure that the proxy performs NAT detection for reply routes
> (onreply_route) for in-dialog requests, and fix the Contact (fix_contact()) in
> onreply_route.
> 
> This is:
> 
> - The UA sends INVITE behind NAT.
> - OpenSIPS fixed Contact and routes it to Asterisk.
> - Asterisk replies 200 => proxy => UA.
> - UA sends ACK => proxy => Asterisk.
> - Now Asterisk sends re-INVITE (in-dialog request) to the proxy.
> - The proxy routes it to UA.
> - UA replies 200.
> - Proxy *fixes Contact* for the 200 and routes to Asterisk.
> - Asterisk now will send ACK to proxy with RURI containing the fixed Contact
> address (UA's public IP:port).


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

Re: [OpenSIPS-Users] Routing Webinar was a success!

[Saúl Ibarra]

On Fri, Jul 10, 2009 at 5:51 PM, Bogdan-Andrei
Iancu wrote:
> Thank you guys,
>
> Indeed, in the following webinars, more complex topics will be approached,
> but I prefer to build a solid foundation before doing this.
>

Totally agree! :)


-- 
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."

http://www.saghul.net/

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

[OpenSIPS-Users] CDRTool - Rating engine does not rate

[Alberto Listas]

Hi,

I have installed OpenSips 1.5.1, FreeRadius 2.1.6, CDRTool 6.8.0. The calls 
work but they all appear as
free in CDRTool. I am using the standard customer and rate tables that come 
with the
software. When I telnet to the rating engine and use the example in the 
documentation
I get the result below:

ShowPrice From=sip:1...@example.com To=sip:0031650222...@example.com 
Gateway=10.0.0.1 Duration=59
0
Duration: 59 s
 App: audio
 Destination: 31650
 Customer: domain=example.com
(And nothing else...)

I don't get a price and the /var/log/syslog displays this error:

Jul 10 18:28:49 os2 cdrtool[11392]: Error: Cannot find rates for callid=, 
billing party=...@example.com, customer domain=example.com, 
gateway=10.0.0.1, destination=31650, profile=grn_premium, app=audio

I don't see the error. There is an entry in customers for the domain 
example.com, there
is a rate for destination 31650. But the rating engine does find any.

Anybody has a suggestion???

Thanks,

Alberto 


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

Re: [OpenSIPS-Users] nat_traversal fails on loose_route ACK

[Iñaki Baz Castillo]

El Viernes, 10 de Julio de 2009, Jeff Pyle escribió:
> Hello,
>
> On Opensips 1.5.1, the scenario is this:  A subscriber behind NAT places a
> call through the proxy that gets relayed to Asterisk whose canreinvite=yes.
> The call goes is answered and Asterisk reinvites the RTP endpoints
> together.
>
> The call starts to go badly when Asterisk ACKs the subscriber's 200 OK to
> its reinvite.  Opensips tries to relay the ACK to the private IP of the
> endpoint, not the public.  Everything up to this point has been to the
> public.

Easy: you must ensure that the proxy performs NAT detection for reply routes 
(onreply_route) for in-dialog requests, and fix the Contact (fix_contact()) in 
onreply_route.

This is:

- The UA sends INVITE behind NAT.
- OpenSIPS fixed Contact and routes it to Asterisk.
- Asterisk replies 200 => proxy => UA.
- UA sends ACK => proxy => Asterisk.
- Now Asterisk sends re-INVITE (in-dialog request) to the proxy.
- The proxy routes it to UA.
- UA replies 200.
- Proxy *fixes Contact* for the 200 and routes to Asterisk.
- Asterisk now will send ACK to proxy with RURI containing the fixed Contact 
address (UA's public IP:port).



-- 
Iñaki Baz Castillo 

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

[OpenSIPS-Users] nat_traversal fails on loose_route ACK

[Jeff Pyle]

Hello,

On Opensips 1.5.1, the scenario is this:  A subscriber behind NAT places a
call through the proxy that gets relayed to Asterisk whose canreinvite=yes.
The call goes is answered and Asterisk reinvites the RTP endpoints together.

The call starts to go badly when Asterisk ACKs the subscriber's 200 OK to
its reinvite.  Opensips tries to relay the ACK to the private IP of the
endpoint, not the public.  Everything up to this point has been to the
public.

Much like many of the examples I've seen, the following happens at the top
of the route[0] block:

if (client_nat_test("3")) {
force_rport();
$avp(s:received_uri) = $source_uri;
fix_contact();
setsflag(7);
}

nat_keepalive is called later on after a REGISTER, but I don't think that's
related.  The config as it is (plus a functioning Mediaproxy implementaiton)
seems to accomplish everything it needs to, except for this ACK at the end
of the reinvite transaction.

Until now I've been able to avoid NAT altogether.  Those blissful days have
passed.  Any suggestions on a direction to go from here would be most
appreciated.


Thanks,
Jeff





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

Re: [OpenSIPS-Users] Number portability

[Brett Nemeroff]

On a really bad day, you can make it work with a B2BUA in the middle. But
really, the technology shouldn't act so dumb, right? :)
On Fri, Jul 10, 2009 at 2:13 PM, Alex Balashov wrote:

> Brett is very right.   I think one of the reasons I reacted instinctively
> to this scenario was because I tried to implement something similar with a
> well-known switch once (I think it was a Metaswitch) and the signaling agent
> reacted to my "spiral" (which I didn't know to be such) as though it were a
> "loop."
>
> Brett Nemeroff wrote:
>
>  Just throwing this out.. Not all equipment can handle SIP Spiral properly.
>>  asterisk  (although I know there was work done on
>> Asterisk+SIP Sprial, I don't know where that ended up)
>>
>> so be careful before you spend a lot of time on that.  I'd love to hear
>> how all of that works for you. I've got plans to do something similar in the
>> LNP space..
>> -Brett
>>
>> On Fri, Jul 10, 2009 at 2:02 PM, Iñaki Baz Castillo > i...@aliax.net>> wrote:
>>
>>El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
>> > > npdi and rp are *userinfo* parameters (in fact they are TEL URI
>> > > paremeters so when converting to SIP URI they become part of
>>the userinfo
>> > > part). http://www.tech-invite.com/Ti-sip-abnf.html#teluri
>> > >
>> > > So, if the original RURI is:
>> > >   sip:+12345...@mydomain.org 
>>> >
>> > >
>> > > and OpenSIPS modifies it to:
>> > >   sip:+12345678;npdi=123;rn=...@mydomain.org
>>
>> > >
>> > > then both RURI's are differents and the softsiwtch won't
>>consider it a
>> > > loop.
>> > >
>> > > However, if the parameters are added as SIP URI parameters
>>(after the
>> > > hostpart) the it would be a loop (except if they are maddr,
>>user, ttl).
>> >
>> > How does that change the other logical attributes of a call leg,
>> i.e.
>> > Call ID GUID, From tag, CSeq, etc?
>>
>>If the RURI changes, then it's *not* a loop, but a spiral. Re-read the
>>appropiate section in RFC 3261 :)
>>
>>
>>--
>>Iñaki Baz Castillo mailto:i...@aliax.net>>
>>
>>___
>>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
>>
>
>
> --
> Alex Balashov
> Evariste Systems
> Web : http://www.evaristesys.com/
> Tel : (+1) (678) 954-0670
> Direct  : (+1) (678) 954-0671
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_on_failure()

[Patrick]

Ok, I took and comment out append_branch() and I only see one invite  
per destination.


On Jul 10, 2009, at 4:04 PM, Patrick wrote:


Interesting, in my testing I've seen the following:

I have a list of 4 destinations - if it fails for one, I'd like it to
roll through all four.I have that occurring,  but when I did a
packet capture I see two INVITEs sent for each of the new destinations
after the first initial failure.   The first one appears to be okay
though with only one INVITE sent.

failure_route[2] {
 if (t_was_cancelled()) {
 exit;
 };
 t_on_failure("2");
 append_branch();
 t_relay();
 exit;
}

Not only is this confirmed via a packet capture, but I see multiple
CDRs cut on the various destinations.

Here is the first two lines of the packets

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:551...@192.168.100.202:5060 SIP/2.0.

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:551...@192.168.100.202:5060 SIP/2.0.


These are in succession with no other packets in between


Patrick


On Jul 9, 2009, at 6:48 PM, Alex Balashov wrote:

I think from a methodological perspective, you're doing just fine.

Failure_route[1] isn't going to inherently be called cyclically
because failure replies that trigger it are final replies.  The only
way you can cycle through the same failure_route is if you created
another branch and armed that failure route for it, too, after the
t_relay().  Both of these have a recursion bottom;  failures only
happen once, unless you manually cause a certain (branch) sequence of
events to transpire beyond it.

If you saw failure_route[1] getting called twice, make sure it wasn't
in response to a CANCEL from the near-end.  You need to have something
like this in there, at the beginning.

  failure_route[1] {
 if(t_was_cancelled()) {
log that we got a cancel, blah blah
exit;
 }
  }

When you get a CANCEL, first failure_route[1] is called as part of
CANCEL processing (automatically, if armed, by TM), and then, you're
going to get it called again in response to the 487 Session Terminated
message that is returned by the far end in response to the CANCEL.
The 487 is part of the INVITE transaction, and since the proxy is only
transaction-stateful, that's the best it can do.

Patrick wrote:

> Sorry, I should have included the code like you have to illustrate
> my question (if you don't mind, I will borrow it):
> route {
> ...
> t_on_failure("1");
> if(!t_relay()) {
> sl_reply_error();
> exit;
> }
> }
> ...
> failure_route[1] {
>  t_on_failure("1");  <-   here is what I am asking
> about t_on_failure inside of a failure_route[x]
>  t_relay();
> ...
> }
> Prior to setting this, I only saw entries in failure route twice:
>  1) the first time the call was attempted
>  2) if the call failed
> It would stop there even when I had a third option.   Now it is
> trying all three options, but just wanted to make sure this was a
> logical methodology   I have safe guards in place to stop it
> from endlessly looping
> Patrick
> On Jul 9, 2009, at 6:00 PM, Alex Balashov wrote:
> You need both;  they do different things.
> The failure_route[x] won't get triggered by default unless you
> associate it with a transaction - in effect, telling OpenSIPS to
> trigger failure_route[x] if a failure code is received for this
> transaction after stateful relay.  That's what t_on_failure() does.
> route {
> ...
> t_on_failure("1");
> if(!t_relay()) {
> sl_reply_error();
> exit;
> }
> }
> ...
> # This will never be run unless t_on_failure("1") is set
> # above.
> failure_route[1] {
> ...
> }
> Patrick wrote:
>> Is it wise to have a t_on_failure inside of a failure_route[x] ?
>> Or  is there another method I could / should use?
>> Thanks,
>> Patrick
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671


___
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] t_on_failure()

[Patrick]

Interesting, in my testing I've seen the following:

I have a list of 4 destinations - if it fails for one, I'd like it to  
roll through all four.I have that occurring,  but when I did a  
packet capture I see two INVITEs sent for each of the new destinations  
after the first initial failure.   The first one appears to be okay  
though with only one INVITE sent.

failure_route[2] {
 if (t_was_cancelled()) {
 exit;
 };
 t_on_failure("2");
 append_branch();
 t_relay();
 exit;
}

Not only is this confirmed via a packet capture, but I see multiple  
CDRs cut on the various destinations.

Here is the first two lines of the packets

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:551...@192.168.100.202:5060 SIP/2.0.

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:551...@192.168.100.202:5060 SIP/2.0.


These are in succession with no other packets in between


Patrick


On Jul 9, 2009, at 6:48 PM, Alex Balashov wrote:

I think from a methodological perspective, you're doing just fine.

Failure_route[1] isn't going to inherently be called cyclically  
because failure replies that trigger it are final replies.  The only  
way you can cycle through the same failure_route is if you created  
another branch and armed that failure route for it, too, after the  
t_relay().  Both of these have a recursion bottom;  failures only  
happen once, unless you manually cause a certain (branch) sequence of  
events to transpire beyond it.

If you saw failure_route[1] getting called twice, make sure it wasn't  
in response to a CANCEL from the near-end.  You need to have something  
like this in there, at the beginning.

  failure_route[1] {
 if(t_was_cancelled()) {
log that we got a cancel, blah blah
exit;
 }
  }

When you get a CANCEL, first failure_route[1] is called as part of  
CANCEL processing (automatically, if armed, by TM), and then, you're  
going to get it called again in response to the 487 Session Terminated  
message that is returned by the far end in response to the CANCEL.   
The 487 is part of the INVITE transaction, and since the proxy is only  
transaction-stateful, that's the best it can do.

Patrick wrote:

> Sorry, I should have included the code like you have to illustrate  
> my question (if you don't mind, I will borrow it):
> route {
>  ...
>  t_on_failure("1");
>  if(!t_relay()) {
>  sl_reply_error();
>  exit;
>  }
> }
> ...
> failure_route[1] {
>   t_on_failure("1");  <-   here is what I am asking  
> about t_on_failure inside of a failure_route[x]
>   t_relay();
>  ...
> }
> Prior to setting this, I only saw entries in failure route twice:
>   1) the first time the call was attempted
>   2) if the call failed
> It would stop there even when I had a third option.   Now it is  
> trying all three options, but just wanted to make sure this was a  
> logical methodology   I have safe guards in place to stop it  
> from endlessly looping
> Patrick
> On Jul 9, 2009, at 6:00 PM, Alex Balashov wrote:
> You need both;  they do different things.
> The failure_route[x] won't get triggered by default unless you  
> associate it with a transaction - in effect, telling OpenSIPS to  
> trigger failure_route[x] if a failure code is received for this  
> transaction after stateful relay.  That's what t_on_failure() does.
> route {
>  ...
>  t_on_failure("1");
>  if(!t_relay()) {
>  sl_reply_error();
>  exit;
>  }
> }
> ...
> # This will never be run unless t_on_failure("1") is set
> # above.
> failure_route[1] {
>  ...
> }
> Patrick wrote:
>> Is it wise to have a t_on_failure inside of a failure_route[x] ?   
>> Or  is there another method I could / should use?
>> Thanks,
>> Patrick
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671


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

Re: [OpenSIPS-Users] Load balancer - how to not change origination ip

[Gabriel Georgescu]

Hi,

I used module dispatcher to make the load balancing and like this the 
ringing calls are disconnected without problem. CANCEL is treated 
correctly and forwarded to the termination gw.
So load_balancer module might have a bug here. I tried to treat the 
incoming CANCEL in routing script but everything seems to happend 
internaly. t_on_failure() does not seems to work in this case.
Also it would be nice to have a probing mechanism and a failover in 
load_balancer (as it is in dispatcher) to fully merit its name :-).

Best regards,
Gabriel




 >>
Salutare Bogdan,

I do exactly the tutorial routing. Yes there is a t_relay() at the 
end and one after loose_route().
 if (!has_totag()) {
 # initial request
  record_route();
 } else {
   # sequential request -> obey Route indication
   loose_route();
   t_relay();
   exit;
 }

I checked on the termination windows machine and there is no CANCEL 
received when I call through opensips (and disconnect while ringing).
But if I call directly to the windows machine the CANCEL is received 
and call disconnected.

So the CANCEL arrives at opensips but is not forwarded to the termination.
What am I missing? How should I catch this message and forward it?

Thanks much,
Gabi


At 02:36 PM 7/9/2009, Bogdan-Andrei Iancu wrote:
>Salut Gabriel,
>
>It looks like there is a problem in how you process the CANCEL - do 
>you do a t_relay() for the received CANCEL ? can you check this at 
>network level if the received CANCEL is actually sent out to the callee part?
>
>Regards,
>Bogdan
>
>Gabriel Georgescu wrote:
>>Thank you for your advices!
>>
>>Regarding the second point I already have a record_route() like 
>>below which does not help to disconnect ringing calls:
>> if (!has_totag()) {
>> # initial request
>> record_route();
>> }
>>I also tried like this without success:
>>
>>if
>>(is_method("INVITE"))
>>
>> record_route();
>>I wonder if the creator of the tutorial had same disconnect 
>>problems and how did he solved it...
>>
>>Looking into the trace there is a CANCEL received from softphone 
>>but it is not propagated to the destination server:
>>
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:build_res_buf_from_sip_res: copied size: orig:108, new: 
>>46, rest: 700 msg=#012SIP/2.0 183 Session Progress#015#012CSeq: 1 
>>INVITE#015#012Via: SIP/2.0/UDP 
>>192.168.1.36:13308;received=X.136.171.132;branch=z9hG4bK-d8754z-317a22388e1b1a23-1---d8754z-;rport=61425#015#012From:
>> 
>>"EyeBeamGG";tag=8a56554d#015#012Call-ID: 
>>YzE5NjRmMzY4YWVlZDJhMGU5MjdmZTlhNTgxY2MzN2M.#015#012To: 
>>"101";tag=0907290911276889507657541#015#012Contact: 
>>#015#012Content-Type: 
>>application/sdp#015#012Content-Length: 229#015#012Record-Route: 
>>#015#012#015#012v=0#015#012o=VoipSwitch
>> 
>>8540 8540 IN IP4 A.121.254.201#015#012s=VoipSIP#015#012i=Audio 
>>Session#015#012c=IN IP4 A.121.254.201#015#012t=0 0#015#012m=audio 
>>7540 RTP/AVP 18 101#015#012a=rtpmap:18 
>>G729/8000/1#015#012a=rtpmap:101 
>>telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:tm:run_trans_callbacks: trans=0xb5c31df8, callback type 128, id 0 entered
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:dialog:next_state_dlg: dialog 0xb5c31c58 changed from state 2 
>>to state 2, due event 2
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:tm:relay_reply: sent buf=0x816c2d8: SIP/2.0 1..., 
>>shmem=0xb5c344b8: SIP/2.0 1
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: DBG:tm:set_timer: 
>>relative timeout is 120
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:tm:insert_timer_unsafe: [1]: 0xb5c31f60 (200)
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: DBG:tm:t_unref: 
>>UNREF_UNSAFE: after is 0
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:destroy_avp_list: destroying list (nil)
>>Jul  9 12:19:34 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:receive_msg: cleaning up
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_msg: SIP Request:
>>*Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>method:  
>>*Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>uri: 
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: DBG:core:parse_msg:
>>version: 
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_headers: flags=2
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_via_param: found param type 232,  = 
>>; state=6
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_via_param: found param type 235,  = ; state=17
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_via: end of header reached, state=5
>>Jul  9 12:19:39 sippc /usr/sbin/opensips[32132]: 
>>DBG:core:parse_headers: via found, flags=2
>>Jul  9 12:19:39 sippc /usr/sbin/

Re: [OpenSIPS-Users] Number portability

[Iñaki Baz Castillo]

El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
> Brett is very right.   I think one of the reasons I reacted
> instinctively to this scenario was because I tried to implement
> something similar with a well-known switch once (I think it was a
> Metaswitch) and the signaling agent reacted to my "spiral" (which I
> didn't know to be such) as though it were a "loop."

Just curiosity: Did the proxy changed the RURI? or what?


-- 
Iñaki Baz Castillo 

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

Re: [OpenSIPS-Users] Number portability

[Alex Balashov]

Brett is very right.   I think one of the reasons I reacted 
instinctively to this scenario was because I tried to implement 
something similar with a well-known switch once (I think it was a 
Metaswitch) and the signaling agent reacted to my "spiral" (which I 
didn't know to be such) as though it were a "loop."

Brett Nemeroff wrote:

> Just throwing this out.. Not all equipment can handle SIP Spiral 
> properly.  asterisk  (although I know there was work done 
> on Asterisk+SIP Sprial, I don't know where that ended up)
> 
> so be careful before you spend a lot of time on that.  I'd love to hear 
> how all of that works for you. I've got plans to do something similar in 
> the LNP space..
> -Brett
> 
> On Fri, Jul 10, 2009 at 2:02 PM, Iñaki Baz Castillo  > wrote:
> 
> El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
>  > > npdi and rp are *userinfo* parameters (in fact they are TEL URI
>  > > paremeters so when converting to SIP URI they become part of
> the userinfo
>  > > part). http://www.tech-invite.com/Ti-sip-abnf.html#teluri
>  > >
>  > > So, if the original RURI is:
>  > >   sip:+12345...@mydomain.org
> 
>  > >
>  > > and OpenSIPS modifies it to:
>  > >   sip:+12345678;npdi=123;rn=...@mydomain.org
> 
>  > >
>  > > then both RURI's are differents and the softsiwtch won't
> consider it a
>  > > loop.
>  > >
>  > > However, if the parameters are added as SIP URI parameters
> (after the
>  > > hostpart) the it would be a loop (except if they are maddr,
> user, ttl).
>  >
>  > How does that change the other logical attributes of a call leg, i.e.
>  > Call ID GUID, From tag, CSeq, etc?
> 
> If the RURI changes, then it's *not* a loop, but a spiral. Re-read the
> appropiate section in RFC 3261 :)
> 
> 
> --
> Iñaki Baz Castillo mailto:i...@aliax.net>>
> 
> ___
> 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


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

Re: [OpenSIPS-Users] Number portability

[Iñaki Baz Castillo]

El Viernes, 10 de Julio de 2009, Brett Nemeroff escribió:
> Just throwing this out.. Not all equipment can handle SIP Spiral properly.
>  asterisk  (although I know there was work done on
> Asterisk+SIP Sprial, I don't know where that ended up)

That ended on "hummm, forget these complex scenarios, we just care about SIP 
for local networks and ISDN for PSTN".

The suggested path is not tested, and being the comments in the bug report 
(comments from Asterisk deevlopers) I expect they are not caapble to solve so 
"difficult" issue.

-- 
Iñaki Baz Castillo 

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

Re: [OpenSIPS-Users] Number portability

[Victor Pascual Avila]

On Fri, Jul 10, 2009 at 9:06 PM, Brett Nemeroff wrote:
> Just throwing this out.. Not all equipment can handle SIP Spiral properly.

Fully agree with that.

> so be careful before you spend a lot of time on that.  I'd love to hear how
> all of that works for you. I've got plans to do something similar in the LNP
> space..

Well, we actually had to implement the three different solutions I've
listed in my previous message in order to interop with different
boxes.

Cheers,
-- 
Victor Pascual Ávila

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

Re: [OpenSIPS-Users] RLS services content validation?

[Iñaki Baz Castillo]

El Jueves, 9 de Julio de 2009, Adrian Georgescu escribió:

> Scenario 1
>
> 1. I upload a million entry list of SIP uris into a rls-services
> document on the xcap server
> 2. I send a Subscribe to the address of the list I uploaded above
> 3. The server starts sending one million Subscribes amplifying my
> single SIP subscribe into a DOS attack on its own resources or a
> foreign domain

Solution 1: Validate document on the XCAP server (already possible in 
OpenXCAP) and reject it if it has more than XXX entries (configurable).

Solution 2: Set the limit in the PU, so it will never generate more than XXX 
subscriptions per RLS.



> Scenario 2
>
> 1. I create a RLS list with pointers to resource lists document (which
> are HTTP URIs) to other domains
> 2. I send a Subscribe to the list
> 3. The server starts sending one million HTTP GETS amplifying my
> single SIP Subscribe into a DOS attack on its own resources or a
> foreign HTTP domain

I can't understand the purpose of HTTP URI's here. Even if IETF documents 
define URI's in a very happy manner (by allowing *any* kind of URI) the fact 
is that a SIP SUBSCRIBE is just allowed for a presentity with scheme sip, tel? 
or press.
Being realistic I would ignore other URI's.

Solution 1: PU ignores "exotic" URI's (however it coudln't send the 
subscription there).

Solution 2: The XCAP server rejects a RLS with "happy" URI's.


> Scenario 3
>
> 1. I simply upload bogus data like bogus SIP URIs that might not
> resolve or point back to the server rls-services lists generating
> loops imposible to detect the reasons for
> 2. The server kills itself Subscribing to itself

Solution 1: The PA doesn't subscribe to the same list identifier (list SIP 
URI) when readin it from that list.

Solution 2: The XCAP server rejects the creation of a RLS if the name of the 
list (a SIP URI) is in fact an entry of the list. Well, not 100% correct, but 
you understand me :)



Just my 2 €


-- 
Iñaki Baz Castillo 

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

Re: [OpenSIPS-Users] Number portability

[Brett Nemeroff]

Just throwing this out.. Not all equipment can handle SIP Spiral properly.
 asterisk  (although I know there was work done on
Asterisk+SIP Sprial, I don't know where that ended up)
so be careful before you spend a lot of time on that.  I'd love to hear how
all of that works for you. I've got plans to do something similar in the LNP
space..
-Brett

On Fri, Jul 10, 2009 at 2:02 PM, Iñaki Baz Castillo  wrote:

> El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
> > > npdi and rp are *userinfo* parameters (in fact they are TEL URI
> > > paremeters so when converting to SIP URI they become part of the
> userinfo
> > > part). http://www.tech-invite.com/Ti-sip-abnf.html#teluri
> > >
> > > So, if the original RURI is:
> > >   sip:+12345...@mydomain.org 
> > >
> > > and OpenSIPS modifies it to:
> > >   sip:+12345678;npdi=123;rn=...@mydomain.org
> > >
> > > then both RURI's are differents and the softsiwtch won't consider it a
> > > loop.
> > >
> > > However, if the parameters are added as SIP URI parameters (after the
> > > hostpart) the it would be a loop (except if they are maddr, user, ttl).
> >
> > How does that change the other logical attributes of a call leg, i.e.
> > Call ID GUID, From tag, CSeq, etc?
>
> If the RURI changes, then it's *not* a loop, but a spiral. Re-read the
> appropiate section in RFC 3261 :)
>
>
> --
> Iñaki Baz Castillo 
>
> ___
> 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] Number portability

[Alex Balashov]

Iñaki Baz Castillo wrote:
> El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
>>> npdi and rp are *userinfo* parameters (in fact they are TEL URI
>>> paremeters so when converting to SIP URI they become part of the userinfo
>>> part). http://www.tech-invite.com/Ti-sip-abnf.html#teluri
>>>
>>> So, if the original RURI is:
>>>   sip:+12345...@mydomain.org
>>>
>>> and OpenSIPS modifies it to:
>>>   sip:+12345678;npdi=123;rn=...@mydomain.org
>>>
>>> then both RURI's are differents and the softsiwtch won't consider it a
>>> loop.
>>>
>>> However, if the parameters are added as SIP URI parameters (after the
>>> hostpart) the it would be a loop (except if they are maddr, user, ttl).
>> How does that change the other logical attributes of a call leg, i.e.
>> Call ID GUID, From tag, CSeq, etc?
> 
> If the RURI changes, then it's *not* a loop, but a spiral. Re-read the 
> appropiate section in RFC 3261 :)

Ah, I see.  I had just thought that something else must change also 
besides just the RURI to make a legitimate spiral.  Thank you and Victor 
for clarifying that.

-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

Re: [OpenSIPS-Users] Number portability

[Iñaki Baz Castillo]

El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
> > npdi and rp are *userinfo* parameters (in fact they are TEL URI
> > paremeters so when converting to SIP URI they become part of the userinfo
> > part). http://www.tech-invite.com/Ti-sip-abnf.html#teluri
> >
> > So, if the original RURI is:
> >   sip:+12345...@mydomain.org
> >
> > and OpenSIPS modifies it to:
> >   sip:+12345678;npdi=123;rn=...@mydomain.org
> >
> > then both RURI's are differents and the softsiwtch won't consider it a
> > loop.
> >
> > However, if the parameters are added as SIP URI parameters (after the
> > hostpart) the it would be a loop (except if they are maddr, user, ttl).
>
> How does that change the other logical attributes of a call leg, i.e.
> Call ID GUID, From tag, CSeq, etc?

If the RURI changes, then it's *not* a loop, but a spiral. Re-read the 
appropiate section in RFC 3261 :)


-- 
Iñaki Baz Castillo 

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

Re: [OpenSIPS-Users] Number portability

[Alex Balashov]

Iñaki Baz Castillo wrote:
> El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
>> Victor Pascual Avila wrote:
>>> On Fri, Jul 10, 2009 at 8:12 PM, Alex Balashov 
> wrote:
 Yes, you can.

 Just beware that you will _have_ to use something like 302s.  If you
 send the INVITE request back to the switch, it will be considered a
 call loop.
>>> Unless you added ;npdi or ;rn parameters to the RURI
>> I am not sure how adding those parameters would circumvent the
>> fundamental problem.
>>
>>Softswitch --> call leg 1 --> proxy --> still call leg 1 --> softswitch
> 
> npdi and rp are *userinfo* parameters (in fact they are TEL URI paremeters so 
> when converting to SIP URI they become part of the userinfo part).
>   http://www.tech-invite.com/Ti-sip-abnf.html#teluri
> 
> So, if the original RURI is:
>   sip:+12345...@mydomain.org
> 
> and OpenSIPS modifies it to:
>   sip:+12345678;npdi=123;rn=...@mydomain.org
> 
> then both RURI's are differents and the softsiwtch won't consider it a loop.
> 
> However, if the parameters are added as SIP URI parameters (after the 
> hostpart) the it would be a loop (except if they are maddr, user, ttl).

How does that change the other logical attributes of a call leg, i.e. 
Call ID GUID, From tag, CSeq, etc?


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

Re: [OpenSIPS-Users] Number portability

[Iñaki Baz Castillo]

El Viernes, 10 de Julio de 2009, Alex Balashov escribió:
> Victor Pascual Avila wrote:
> > On Fri, Jul 10, 2009 at 8:12 PM, Alex Balashov 
wrote:
> >> Yes, you can.
> >>
> >> Just beware that you will _have_ to use something like 302s.  If you
> >> send the INVITE request back to the switch, it will be considered a
> >> call loop.
> >
> > Unless you added ;npdi or ;rn parameters to the RURI
>
> I am not sure how adding those parameters would circumvent the
> fundamental problem.
>
>Softswitch --> call leg 1 --> proxy --> still call leg 1 --> softswitch

npdi and rp are *userinfo* parameters (in fact they are TEL URI paremeters so 
when converting to SIP URI they become part of the userinfo part).
  http://www.tech-invite.com/Ti-sip-abnf.html#teluri

So, if the original RURI is:
  sip:+12345...@mydomain.org

and OpenSIPS modifies it to:
  sip:+12345678;npdi=123;rn=...@mydomain.org

then both RURI's are differents and the softsiwtch won't consider it a loop.

However, if the parameters are added as SIP URI parameters (after the 
hostpart) the it would be a loop (except if they are maddr, user, ttl).


-- 
Iñaki Baz Castillo 

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

Re: [OpenSIPS-Users] Number portability

[Victor Pascual Avila]

On Fri, Jul 10, 2009 at 8:42 PM, Alex Balashov wrote:
> Victor Pascual Avila wrote:
>>
>> On Fri, Jul 10, 2009 at 8:12 PM, Alex Balashov
>> wrote:
>>>
>>> Yes, you can.
>>>
>>> Just beware that you will _have_ to use something like 302s.  If you
>>> send the INVITE request back to the switch, it will be considered a
>>> call loop.
>>
>> Unless you added ;npdi or ;rn parameters to the RURI
>
> I am not sure how adding those parameters would circumvent the fundamental
> problem.
>
>  Softswitch --> call leg 1 --> proxy --> still call leg 1 --> softswitch

The idea was not creating a loop but an spiral instead.

In such scenario, one could be using the following routing options (I
don't really know whether they are all implementable using opensips or
not):
- Direct routing: get invite, npdb dip, route the invite based on the
result (npdi, rn).
- Redirect routing: get invite, npdb dip, send back 302 (npdi, rn)
- Route updated invite back (spiral): get invite, npdb dip, send back
the updated invite (npdi, rn).

Cheers,
-- 
Victor Pascual Ávila

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

Re: [OpenSIPS-Users] Routing Webinar was a success!

[duane . larson]

How long before the webinar video is posted to the website?


On Jul 10, 2009 10:51am, Bogdan-Andrei Iancu  wrote:

Thank you guys,







Indeed, in the following webinars, more complex topics will be




approached, but I prefer to build a solid foundation before doing this.







Best regards,




Bogdan







Saúl Ibarra wrote:




> I agree, it was a sucess!




>




> bay2x1: it was the second webinar, I think it's too early fot that,




> but it'll be covered on future webinars (I guess) :)




>




>




> BTW: Bogdan, it'd be nice to have a webinar on presence with OpenXCAP :)




>




>




>










___




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] Number portability

[Alex Balashov]

Victor Pascual Avila wrote:
> On Fri, Jul 10, 2009 at 8:12 PM, Alex Balashov 
> wrote:
>> Yes, you can.
>>
>> Just beware that you will _have_ to use something like 302s.  If you
>> send the INVITE request back to the switch, it will be considered a
>> call loop.
> 
> Unless you added ;npdi or ;rn parameters to the RURI

I am not sure how adding those parameters would circumvent the 
fundamental problem.

   Softswitch --> call leg 1 --> proxy --> still call leg 1 --> softswitch

-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

Re: [OpenSIPS-Users] Number portability

[Victor Pascual Avila]

On Fri, Jul 10, 2009 at 8:12 PM, Alex Balashov wrote:
> Yes, you can.
>
> Just beware that you will _have_ to use something like 302s.  If you
> send the INVITE request back to the switch, it will be considered a
> call loop.

Unless you added ;npdi or ;rn parameters to the RURI
-- 
Victor Pascual Ávila

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

Re: [OpenSIPS-Users] Number portability

[Alex Balashov]

Yes, you can.

Just beware that you will _have_ to use something like 302s.  If you  
send the INVITE request back to the switch, it will be considered a  
call loop.

--
Sent from mobile device

On Jul 10, 2009, at 2:09 PM, "Paul Mancheno H."   
wrote:

> Hello.
>
> I have a project to do a system to implement numerical portability,  
> the calls
> go out from my Softswitch and they would go directly to OpenSIPs and  
> I look in
> a database (Postgresql or MySql) for the route that I must take,  
> return a
> message with code 302 using a prefix depending on the route and this  
> way my
> Softswtich, on having reanalyzed the number now, sends it on the  
> other hand.
>
> Can I do that with OpenSIP?
> Can I have a pool of connections to the database so that one is not  
> gaining
> access all the time?
> Perhaps is it better to use a project as Sailfin?
>
> A lot of thanks.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[OpenSIPS-Users] Number portability

[Paul Mancheno H.]

Hello.

I have a project to do a system to implement numerical portability, the calls 
go out from my Softswitch and they would go directly to OpenSIPs and I look in 
a database (Postgresql or MySql) for the route that I must take, return a 
message with code 302 using a prefix depending on the route and this way my 
Softswtich, on having reanalyzed the number now, sends it on the other hand.

Can I do that with OpenSIP?
Can I have a pool of connections to the database so that one is not gaining 
access all the time?
Perhaps is it better to use a project as Sailfin?

A lot of thanks.

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

[OpenSIPS-Users] Dynamic Routing - assigning GroupID to gateway without authentication

[Julien Chavanton]

Hi, I have started to use Dynamic Routing and I find it very conviniant so far, 
thanks and congradulation !
 
I have a question, GroupID is configured by user name, I wanted to assign group 
id to specific gateway, so that traffic comming from a gateway could be 
controlled like traffic comming from a user, with a specific set of rules etc.
 
 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ACC Module missing failed transactions

[Brett Nemeroff]

Sorry all,I'm not setting db_missed_flag. whoops!
-Brett


On Fri, Jul 10, 2009 at 10:25 AM, Brett Nemeroff  wrote:

> All,I had some problems a while ago with ACC and I thought I had them
> resolved, but looks like I'm still having issues..
>
> I've set failed_transaction flag (14) and db_flag (15).
>
> I arm both 14 and 15 at the top of my routing script. Then in my failure
> routes, I re-arm 14.
>
> My ACC looks pretty good, but when calls roll, I miss all of the ACC
> records from the original attempt (ie: calls go to gateway1, fail, then
> gateway2.. acc only shows messaging from gateway2).
>
> any ideas on why the original attempt (gateway1) doesn't show up in acc?
> For what it's worth, in siptraces, I DO see both attempts.
>
> Thanks,
>
> -Brett
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Load Balancer module only sending calls to 4 servers in a group

[Bogdan-Andrei Iancu]

Hello Bobby,

Let me test this scenario.

Regards,
Bogdan

Bobby Smith wrote:
> Hello,
>
> I've currently got the load balancer set up with a single group (we'll 
> call it "handset", as our opensips server using the loadbalancing is 
> just acting as a registrar/proxy to a softswitch).
>
> This is how it's defined in the database table:
>
> "1";1;"sip:1.2.3.4";"handset=75";"server1"
> "2";1;"sip:sip:1.2.3.5";"handset=75";"server2"
> "3";1;"sip:sip:1.2.3.6";"handset=75";"server3"
> "4";1;"sip:sip:1.2.3.7";"handset=75";"server4"
> "5";1;"sip:sip:1.2.3.8";"handset=75";"server5"
> "6";1;"sip:sip:1.2.3.9";"handset=75";"server6"
> "7";1;"sip:sip:1.2.3.10";"handset=75";"server7"
> "8";1;"sip:1.2.3.11";"handset=75";"server8"
> "9";1;"sip:1.2.3.12";"handset=75";"server9"
> "10";1;"sip:1.2.3.13";"handset=75";"server10"
> "11";1;"sip:1.2.3.14";"handset=75";"server11"
> "12";1;"sip:1.2.3.15";"handset=75";"server12"
> "13";1;"sip:1.2.3.16";"handset=75";"server13"
>
> When active, it seems the load balancer is only sending to the first 4 
> servers in the list:
>
> [r...@cloud_registrar_lb mnt]# opensipsctl fifo lb_list
> Destination:: sip:1.2.3.4 id=1
> Resource:: handset max=75 load=75
> Destination:: sip:1.2.3.5 id=2
> Resource:: handset max=75 load=75
> Destination:: sip:1.2.3.6 id=3
> Resource:: handset max=75 load=75
> Destination:: sip:1.2.3.7 id=4
> Resource:: handset max=75 load=75
> Destination:: sip:1.2.3.8 id=5
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.9 id=6
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.10 id=7
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.11 id=8
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.12 id=9
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.13 id=10
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.14 id=11
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.15 id=12
> Resource:: handset max=75 load=0
> Destination:: sip:1.2.3.16 id=13
> Resource:: handset max=75 load=0
>
> I don't see anything in the log identifying that we're even try to 
> send anything beyond the first 4 servers, and an ngrep confirms that 
> it's essentially balancing messages to just the first four without 
> trying the rest.
>
> Any thoughts?  I'm using the 1.5.1 version of the load balancer.
>
> Thanks,
>
> Bobby S
> 
>
> ___
> 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] Routing Webinar was a success!

[Bogdan-Andrei Iancu]

Thank you guys,

Indeed, in the following webinars, more complex topics will be 
approached, but I prefer to build a solid foundation before doing this.

Best regards,
Bogdan

Saúl Ibarra wrote:
> I agree, it was a sucess!
>
> bay2x1: it was the second webinar, I think it's too early fot that,
> but it'll be covered on future webinars (I guess) :)
>
>
> BTW: Bogdan, it'd be nice to have a webinar on presence with OpenXCAP :)
>
>
>   


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

Re: [OpenSIPS-Users] OpenSIPS started looking for SRV records

[Bogdan-Andrei Iancu]

Hi Gordon,

You claim that trunk and 1.5 behaves differently (from SRV point of 
view)  with the same cfg and on the same server/OS ?

Regards,
Bogdan

Gordon Ross wrote:
> I've discovered that this problem only occurs on the trunk build of OpenSIPS. 
> Reverting back to the 1.5.1 source tarball and things all run fine.
>
> GTG
> 
> From: users-boun...@lists.opensips.org [users-boun...@lists.opensips.org] On 
> Behalf Of Gordon Ross
> Sent: 09 July 2009 16:10
> To: users@lists.opensips.org
> Subject: [OpenSIPS-Users] OpenSIPS started looking for SRV records
>
> I built OpenSIPS 1.5.1 on a SLES 10 box and it basically worked. For various
> reasons, I then re-built it on an Ubuntu 9.04 server box.
>
> Since re-building it on the Ubuntu box, my X-Lite client registers fine, but
> my SIP hard phone doesn't, giving me the error "Too many hops". Running a
> wireshark on the Ubuntu box, I now see a load of DNS SRV/NAPTR requests.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


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

[OpenSIPS-Users] OpenSIPS + OpenIMS + NAT issues

[Olivier Dugeon]

Hello all,

I have some problems with OpenSIPS and OpenIMS due to NAT configuration.

My setup is a follow:

UA <--> HGW (embedded both OpenSIPS and NAT stuff) <--> P-CSCF (OpenIMS)

I used different UA (mainly Twinkle and X-Lite). The HGW (Home GateWay)
is running under OpenWRT on which I compile and install OpenSIPS. The
P-CSCF, S-CSCF and I-CSCF are all running on the same PC (standard
configuration from OpenIMS installation).

My OpenSIPS is just used to manage local message (perform some security
check) and manage the NAT configuration of the HGW.

My problem come from the fact that the P-CSCF (and subsequently the
S-CSCF) is registered my UA with its private @IP address and not the
public @IP address of the HGW. So, each time I sent a SIP message to the
IMS Core, the P-CSCF  reject my messages with a 403 "Forbidden. You must
registered first in the P-CSCF". This come from that the P-CSCF check
who is sending the SIP message based on the source @IP. In my case, the
source @IP address is the public one (i.e. the HGW public one). However,
this public @IP address is not know by the P-CSCF i.e. it doesn't
correspond to a registered UA. So, Outgoing call are not working.
Fortunately, Incoming call (i.e. from a UA which is directly connected
to the IMS Core) are working well.

I try several configuration using nathelper module, but I just got a
negative reply from the S-CSCF instead of the P-CSCF (I.e. I pass the
P-CSCF check by using force_rport in register and invite message)).

I fact, the problem come from the fix_nated_contact() and
fix_nated_register() function which don't do the job I want. They
rewrite the contact field with the source IP and Port of the original
message i.e. the @IP address and port of the UA.

So, what I'm looking for, is a way to hide the private @IP address and
the possibility to rewrite the Contact field with the public @IP of the
HGW in order for the P-CSCF thinks that the UA is registered with the
public @IP address and not the private one.

Is it possible and how ?

Thanks a lot for your help.

Olivier

PS: Here it is my opensips configuration:

# --- global configuration parameters 

debug=3  # debug level (cmd line: -dd)
log_stderror=yes # (cmd line: -E)
log_facility=LOG_LOCAL1

fork=yes
sip_warning=0

check_via=no# (cmd. line: -v)
#dns=yes   # (cmd. line: -r)
dns=no   # (cmd. line: -r)
#rev_dns=yes  # (cmd. line: -R)
rev_dns=no  # (cmd. line: -R)
disable_tcp=yes
disable_dns_blacklist=yes
disable_dns_failover=yes

listen=udp:192.168.1.1:5060
listen=udp:217.70.81.211:5060

children=1

auto_aliases=no
alias="zpna.systerminal.eu:5060"

# -- module loading --

mpath="/usr/lib/opensips/modules"
loadmodule "db_text.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "xlog.so"
loadmodule "mi_fifo.so"
loadmodule "maxfwd.so"
loadmodule "uac.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "alias_db.so"
loadmodule "uri.so"
loadmodule "uri_db.so"
loadmodule "domain.so"
loadmodule "nathelper.so"
loadmodule "textops.so"
loadmodule "avpops.so"
loadmodule "permissions.so"
loadmodule "presence.so"
loadmodule "presence_xml.so"
loadmodule "pua.so"
loadmodule "rls.so"
loadmodule "xcap_client.so"

# - setting module-specific parameters ---
# -- multi-modules params --
modparam("usrloc|permissions|auth_db|uri_db|domain|presence|presence_xml|rls|pua|xcap_client|alias_db",
  "db_url", "text:///etc/opensips/opensipsdb")
modparam("auth_db|alias_db|uri_db|usrloc", "use_domain", 1)

# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)

# -- nathelper --
modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")
modparam("nathelper", "natping_interval", 60)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "received_avp", "$avp(i:9)")

# -- timer params --
modparam("tm", "fr_timer", 5)
modparam("tm", "fr_inv_timer", 100)
modparam("tm", "wt_timer", 10)

# -- usrloc params --
modparam("usrloc", "db_mode", 1)
modparam("usrloc", "timer_interval", 10)
modparam("usrloc", "nat_bflag", 6)
modparam("usrloc", "desc_time_order", 1)

# -- auth params --
modparam("auth", "nonce_expire",  300)
modparam("auth", "realm_prefix", "sip.")
# modparam("auth", "rpid_avp", "$avp(rpid)")

# -- auth_db params --
modparam("auth_db", "password_column", "password")
modparam("auth_db", "calculate_ha1", 1)

# -- registrar params --
modparam("registrar", "max_contacts", 2)
modparam("registrar", "received_avp", "$avp(i:9)")
modparam("registrar", "sock_flag", 12)
modparam("registrar", "sock_hdr_name", "Local-Sock")
modparam("registrar", "max_expires", 3600)

# -- permissions param

Re: [OpenSIPS-Users] auth_db:get_ha1: failed to query database

[Bogdan-Andrei Iancu]

Hi Ram,

Looks like your subscriber table is corrupted and has no "username" column.

Regards,
Bogdan

ram wrote:
>
>
>
> Hi
>  
> iam setting up CDRtools with Radius and Opensips
>  
> everything working Fine
>  
> Opensips is running
>  
> when the client try to register i get the follwing errors in the 
> /var/log/syslog
>  
> I have downloaded latest SVN Trunk of 1.5.X
>  
>  
> Jul  9 12:56:56 freeswitch /usr/local/sbin/opensips[1386]: 
> REGISTER LOOP IN MAIN ROUTE
> Jul  9 12:56:56 freeswitch /usr/local/sbin/opensips[1386]: 
> ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare: 
> (1054) Unknown column 'username' in 'where clause'
> Jul  9 12:56:56 freeswitch /usr/local/sbin/opensips[1386]: 
> ERROR:db_mysql:db_mysql_do_prepared_query: failed to create new context
> Jul  9 12:56:56 freeswitch /usr/local/sbin/opensips[1386]: 
> ERROR:auth_db:get_ha1: failed to query database
>  
> any suggestions , or this is bug
>  
> Ram
>
> 
>
> ___
> 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] How to recalculate ha1 and ha1b

[Bogdan-Andrei Iancu]

Hi Dioris,

Could you upload this on the web site (TIPS section) for other people 
benefit ? See: http://www.opensips.org/Resources/Documentation#toc4

If you create an account on the web site, you are free to edit the content.

Thanks and regards,
Bogdan



Dioris Moreno wrote:
> When you change the domain column in the subscriber table, you have to 
> recalculate ha1 and ha1b fields. In order to do that you must have the 
> password of each subscriber. It is stored in the 'password' column if 
> you have set STORE_PLAINTEXT_PW=1 in opensipsctlrc (default).
>
> HA1 is a MD5 hash of "username:domain:password". For example, if you 
> have created a SIP account 1...@mydomain.com 
>  using password 123456, then HA1 is the MD5 
> hash of "1000:mydomain.com:123456 " 
> (without quotes). On the other hand HA1B is the MD5 hash of 
> "usern...@domain:domain:password"; so using the same example above, 
> HA1B would be the MD5 hash of "1...@mydomain.com:mydomain.com:123456 
> " (without quotes).
>
> So, to recalculate and update ha1 and ha1b columns in the subscriber 
> table, just execute the following sql statement in mysql:
>
> update subscriber
> set ha1 = md5(concat(username, ':', domain, ':', password)),
> ha1b = md5(concat(username, '@', domain, ':', domain, ':', password))
>
> I hope this could be useful.
>
> Regards,
>
> Dioris
>
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


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

Re: [OpenSIPS-Users] Opensips on OS X?

[Bogdan-Andrei Iancu]

Hi Matti,

It should compile - haven't personally tried for some time, but at some 
point it did and also there were not reports on this .

Regards,
Bogdan

Matti Zemack wrote:
> Hi all,
>
> Just a quick question. Before I try to convince some guys that Debian 
> would be MUCH easier for Opensips. Anyone tried OS X, was it easy 
> installing/compiling Opensips for OSX?
>
> Regards,
> Matti Zemack, Stockholm, Sweden
> 
>
> ___
> 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] Multi-homed systems

[Bogdan-Andrei Iancu]

You mean multi-home or bridging ? if multihome, you can use multiple 
instances of media relays running on different IPs and from OpenSIPS 
script, based on the signalling IP, you select corresponding media 
relay. Not tried with Mediaproxy, but works with RTPproxy

Regards,
Bogdan

Gordon Ross wrote:
> Thanks. As MediaProxy can't do multi-homing I've had to re-think my stratedgy 
> a bit.
>
> GTG
>
> - Original Message -
> From: Bogdan-Andrei Iancu 
> To: Gordon Ross
> Cc: users@lists.opensips.org 
> Sent: Fri Jul 10 16:23:23 2009
> Subject: Re: [OpenSIPS-Users] Multi-homed systems
>
> Hi Gordon,
>
> Also you can manually set an outbound interface via force_send_socket():
> http://www.opensips.org/Resources/DocsCoreFcn15#toc95
>
> Regards,
> Bogdan
>
> Gordon Ross wrote:
>   
>> On 07/07/2009 08:57, "Uwe Kastens"  wrote:
>>
>>   
>> 
>>> Hi,
>>>
>>> set mhomed=1 ?
>>> 
>>>   
>> Star !
>>
>> Thanks,
>>
>> GTG
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>   
>> 
>
>   


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

[OpenSIPS-Users] ACC Module missing failed transactions

[Brett Nemeroff]

All,I had some problems a while ago with ACC and I thought I had them
resolved, but looks like I'm still having issues..

I've set failed_transaction flag (14) and db_flag (15).

I arm both 14 and 15 at the top of my routing script. Then in my failure
routes, I re-arm 14.

My ACC looks pretty good, but when calls roll, I miss all of the ACC records
from the original attempt (ie: calls go to gateway1, fail, then gateway2..
acc only shows messaging from gateway2).

any ideas on why the original attempt (gateway1) doesn't show up in acc? For
what it's worth, in siptraces, I DO see both attempts.

Thanks,

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

Re: [OpenSIPS-Users] Multi-homed systems

[Bogdan-Andrei Iancu]

Hi Gordon,

Also you can manually set an outbound interface via force_send_socket():
http://www.opensips.org/Resources/DocsCoreFcn15#toc95

Regards,
Bogdan

Gordon Ross wrote:
> On 07/07/2009 08:57, "Uwe Kastens"  wrote:
>
>   
>> Hi,
>>
>> set mhomed=1 ?
>> 
>
> Star !
>
> Thanks,
>
> GTG
>
>
> ___
> 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] Error in compiling opensips on solaris-10

[Bogdan-Andrei Iancu]

Hi Anurag,

That is a real interesting one - looks lore GCC dependent . Sergio (here 
CC'ed) has some experience in compiling on SolarisSergio, any idea 
what this error means ?

Regards,
Bogdan


anurag wrote:
> Hi,
>
> I'm trying to compile opensips on solaris-10 and getting following
> error (though the same source is working fine on Linux):
>
> 
> gcc  -g -O9 -funroll-loops   -Wall  -DNAME='"opensips"'
> -DVERSION='"1.5.1-notls"' -DARCH='"sparc64"' -DOS='"solaris"'
> -DCOMPILER='"gcc 3.4.6"' -D__CPU_sparc64 -D__OS_solaris -D__SMP_yes
> -DCFG_DIR='"/etc/opensips/"' -DPKG_MALLOC -DSHM_MEM  -DSHM_MMAP -DUSE_IPV6
> -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS
> -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC  -DFAST_LOCK -DADAPTIVE_WAIT
> -DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H
> -DHAVE_SCHED_YIELD -DHAVE_ALLOCA_H -DUSE_SIGACTION
> -D_POSIX_PTHREAD_SEMANTICS -DHAVE_DEVPOLL -DHAVE_SELECT -c blacklists.c -o
> blacklists.o
> /usr/ccs/bin/as: "/var/tmp//ccMTaD7w.s", line 223: error: cannot use v8plus
> instructions in a non-v8plus target binary
> /usr/ccs/bin/as: "/var/tmp//ccMTaD7w.s", line 243: error: cannot use v8plus
> instructions in a non-v8plus target binary
> =
>
> Do I need to use some other version of GCC or opensips for this?
>
> Pls help!
>
> Thanx in advance,
> Anurag Guru
>
>
> ___
> 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] How To Ask Questions The Smart Way

[Raúl Alexis Betancor Santana]

On Friday 10 July 2009 12:33:31 li...@grounded.net wrote:
> Bunch of self important blowhards, this is the only mailing list that acts
> this way!

That's maybe your are not subscribed to technical lists, because on my more 
than 18 year old internet knowleadge, on all technicnal (and on non technical 
also) list I'm been subscrided to, work on the same way, anyone is forced to 
answer you.

Here, more than one of us have told you to read some docs and guide you to the 
path you should follow to get the NEEDED knowleage and enought background to 
be able to reach your goals.

You could ask doubds, post confings and traces of what you don't get running 
and I'm pretty sure you will get answers that will help you, but if you 
insists on doing "too general" questions you will allways get the same 
answers.


-- 
Raúl Alexis Betancor Santana
Dimensión Virtual

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

Re: [OpenSIPS-Users] XCAP table is just queried the first time

[Iñaki Baz Castillo]

2009/7/10 Adrian Georgescu :
> This can be elegantly done by improving the xcap-diff module.

> When an XCAP
> server has an update for a document for a given user it should Publish this
> to the PA for Event=xcap-diff.

Do you mean that an external XCAP server (but using OpenSIPS's xcap
table) could generate a SIP PUBLISH (Event: xcap-diff) and send it to
the presence server?


> The module then should internally cause a
> refresh_watchers()



-- 
Iñaki Baz Castillo


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

Re: [OpenSIPS-Users] XCAP table is just queried the first time

[Adrian Georgescu]

This can be elegantly done by improving the xcap-diff module. When an  
XCAP server has an update for a document for a given user it should  
Publish this to the PA for Event=xcap-diff. The module then should  
internally cause a refresh_watchers()

Adrian


On Jul 10, 2009, at 3:46 PM, Iñaki Baz Castillo wrote:

> 2009/7/10 Anca Vamanu :
>> Yes, you are right. This is the reason why the table is queried  
>> only the
>> first time. It is assumed that OpenXCAP will announce it when a  
>> change
>> occurs.
>
> Anca, what about if OpenSIPS runs with other XCAP server (also in
> "integrated_mode" using xcap table)?
> Would make sense an option in presence module  
> "always_query_xcap_table"?
> - If "no" (default value) the current behaviour would take place.
> - If "yes", the XCAP table would be queried every time.
>
> This would allow XCAP updates (XCAP table modifications) being updated
> in presence module (when not using OpenXCAP with "OpenSIPS" backend
> and opensips-mi-proxy).
>
>
>
>
> -- 
> Iñaki Baz Castillo
> 
>
> ___
> 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] How To Ask Questions The Smart Way

[Iñaki Baz Castillo]

2009/7/10 li...@grounded.net :
> Bunch of self important blowhards, this is the only mailing list that acts 
> this way!

Not true at all.

-- 
Iñaki Baz Castillo


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

Re: [OpenSIPS-Users] XCAP table is just queried the first time

[Iñaki Baz Castillo]

2009/7/10 Anca Vamanu :
> Yes, you are right. This is the reason why the table is queried only the
> first time. It is assumed that OpenXCAP will announce it when a change
> occurs.

Anca, what about if OpenSIPS runs with other XCAP server (also in
"integrated_mode" using xcap table)?
Would make sense an option in presence module "always_query_xcap_table"?
- If "no" (default value) the current behaviour would take place.
- If "yes", the XCAP table would be queried every time.

This would allow XCAP updates (XCAP table modifications) being updated
in presence module (when not using OpenXCAP with "OpenSIPS" backend
and opensips-mi-proxy).




-- 
Iñaki Baz Castillo


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

Re: [OpenSIPS-Users] How To Ask Questions The Smart Way

[Alex Balashov]

I'm on a rather nontrivial number of other mailing lists associated with 
various open-source projects and ecosystems, including quite a few in 
the VoIP space.

I can tell you that what you say here is definitely not the case.

li...@grounded.net wrote:

> Bunch of self important blowhards, this is the only mailing list that acts 
> this way!
> 
> On Fri, 10 Jul 2009 02:48:05 -0400 (EDT), Alex Balashov wrote:
>>  
>>  
>>  Thank you for posting this.  It is something that very, very often needs
>>  to be said and bears repeating.
>>  
>>>  This a good read for those who show up on mailing lists without any
>>>  guidance about how to ask the right questions and then complain that
>>>  nobody answers their questions as they want.
>>>  
>>>  http://www.catb.org/~esr/faqs/smart-questions.html
>>>  
>>>  It was also a good read for me.
>>>  
>>>  Regards,
>>>  Adrian
>>>  
>>>  
>>>  ___
>>>  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


-- 
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

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

Re: [OpenSIPS-Users] XCAP table is just queried the first time

[Iñaki Baz Castillo]

2009/7/10 Anca Vamanu :
> Yes, you are right. This is the reason why the table is queried only the
> first time. It is assumed that OpenXCAP will announce it when a change
> occurs.

ok, hope I can make "OpenSIPS" backend working in OpenXCAP.
Thanks.


-- 
Iñaki Baz Castillo


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

Re: [OpenSIPS-Users] XCAP table is just queried the first time

[Anca Vamanu]

Iñaki Baz Castillo wrote:
> 2009/7/9 Iñaki Baz Castillo :
>   
>> Hi, I restart OpenSIPS and perform a presence SUBSCRIBE.
>> I clearly see in MySQL logs a query to the xcap table:
>>
>>  select doc from xcap where username='alice' AND domain='domain.org'
>> AND doc_type=2
>>
>> After a while, I un-susbcribe and subscribe again. This time I don't
>> see the query to xcap table and the previous subscription status is
>> retrieved. Why?
>> 
>
> I think that it's supposed to work with OpenXCAp using "OpenSIPS"
> backend, so OpenXCAP will notify OpenSIPS (via opensips-mi-proxy)
> about XCAP updates, so the presence module will read them in order to
> generate nupdated notifications.
>
> Unfortunatelly I cannot get "OpenSIPS" backend working in OpenXCAP :(
>   http://openxcap.org/ticket/99
>
>
>   
Yes, you are right. This is the reason why the table is queried only the 
first time. It is assumed that OpenXCAP will announce it when a change 
occurs.

Anca


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

Re: [OpenSIPS-Users] MediaProxy communication problem

[Ruud Klaver]

Hi Gordon,

On 10 Jul 2009, at 10:54, Gordon Ross wrote:

> I've built and installed MediaProxy V2.3.4 from source on Ubuntu 9.04.
>
> After starting the dispatcher & relay I get the following message in
> /var/log/daemon.log
>
> Jul 10 10:47:12 op-test media-dispatcher[22209]: exceptions.TypeError:
> __init__() takes exactly 6 arguments (7 given)
> Jul 10 10:47:12 op-test media-relay[22242]: error: Could not connect  
> to
> dispatcher at 127.0.0.1:25060 (retrying in 10 seconds): A TLS packet  
> with
> unexpected length was received.
>
>
> A quick google reveals
> http://www.mail-archive.com/users@lists.opensips.org/msg01054.html
>
> However, that was back in January. Does that still apply, or have I  
> done
> something wrong ?
>
> GTG

What's your version of python-gnutls? You should have at least version  
1.1.8.

Ruud Klaver
AG Projects

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

Re: [OpenSIPS-Users] How To Ask Questions The Smart Way

[li...@grounded.net]

Bunch of self important blowhards, this is the only mailing list that acts this 
way!

On Fri, 10 Jul 2009 02:48:05 -0400 (EDT), Alex Balashov wrote:
> 
> 
> Thank you for posting this.  It is something that very, very often needs
> to be said and bears repeating.
> 
>> This a good read for those who show up on mailing lists without any
>> guidance about how to ask the right questions and then complain that
>> nobody answers their questions as they want.
>> 
>> http://www.catb.org/~esr/faqs/smart-questions.html
>> 
>> It was also a good read for me.
>> 
>> Regards,
>> Adrian
>> 
>> 
>> ___
>> Users mailing list
>> us...@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



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

[OpenSIPS-Users] rpid_avp and NULL values

[Carlo Dimaggio]

Hi all,

I'm using rpid column in subscriber table in order to set the display- 
name of the p-asserted header, but I have some problems with NULL  
values.
In detail, I use modparam("auth", "rpid_avp", "$avp(s:rpid)") to load  
the rpid. When rpid value is NULL, the $avp(s:rpid) sometimes contains  
values of other subscribers (that are not NULL)...

It's a strange behaviour... What can be the problem (is it possible  
that rpid_avp takes the rpid of another subscriber)?


Thanks,
Carlo Dimaggio


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

[OpenSIPS-Users] MediaProxy communication problem

[Gordon Ross]

I've built and installed MediaProxy V2.3.4 from source on Ubuntu 9.04.

After starting the dispatcher & relay I get the following message in
/var/log/daemon.log

Jul 10 10:47:12 op-test media-dispatcher[22209]: exceptions.TypeError:
__init__() takes exactly 6 arguments (7 given)
Jul 10 10:47:12 op-test media-relay[22242]: error: Could not connect to
dispatcher at 127.0.0.1:25060 (retrying in 10 seconds): A TLS packet with
unexpected length was received.


A quick google reveals
http://www.mail-archive.com/users@lists.opensips.org/msg01054.html

However, that was back in January. Does that still apply, or have I done
something wrong ?

GTG


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