Re: [OpenSIPS-Users] ping gateways in lcr or drouting?

[Andrew Pogrebennyk]

Bogdan-Andrei Iancu wrote:
> None of them do support pinging to GW, but I guess it will be a nice 
> feature for DR..

Bogdan,
Another nice feature would be to add a pseudo-variable to do_routing() 
to take caller's URI from. LCR module already can do that. Probably I 
will come up with a patch for drouting. Thank you.

-- 
Sincerely,
Andrew Pogrebennyk

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

users@lists.opensips.org

[Indiver]

Hi Andrew,
Which proprietary tool using for mixing of RTP files. So that we contact
them and try to use that. Cause that we have facing problems while using sox
and rtpbreak  interms of voice quality and other issues.

Regards,
Nehru.
-- 
View this message in context: 
http://n2.nabble.com/Query-regarding-Rtp-Proxy-opensips-tp4438620p4518350.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

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

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Thamer Alharbash]

Bogdan you are correct.

Thanks for your help. It was an issue with fixing the NATed contact  
on the first reply.

On 4-Feb-10, at 4:14 AM, Bogdan-Andrei Iancu wrote:

> Hi Thamer,
>
> actually I see a 408 TIMEOUT for the second re-INVITE - but I see not
> outgoing re-INVITE in the second step (only the inbound message)
>
> Looking at the 2 re-INVITEs, I would say you have a routing issue  
> as the
> first re-INVITE has as RURI a public IP
> (sip:1...@uac.ip.address.here:5060), while the second re-INVITE has a
> private IP (sip:1...@192.168.2.12:5060)
> So, maybe the NAT traversal logic for the sequential requests is not
> correct.
>
> Regards,
> Bogdan
>
> Thamer Alharbash wrote:
>> Hi Bogdan,
>>
>> Sorry for not getting back sooner. I've updated my config a bit. I'm
>> including what our reinvite handling looks like and the two reinvites
>> that pass through opensips. The second one as you can see has no
>> payload (ngrep shows ...) I have verified this as well under  
>> wireshark.
>>
>> if (has_totag()) {
>>
>>  # sequential request within a dialog should
>>  # take the path determined by record-routing
>>
>>  if (loose_route()) {
>>
>>  if (is_method("BYE")) {
>>  setflag(1); # do accounting ...
>>  setflag(3); # ... even if the
>> transaction fails
>>
>>  } else if (is_method("INVITE")) {
>>  # even if in most of the cases is
>> useless, do RR for
>>  # re-INVITEs also, as some buggy
>> clients do change route set
>>  # during the dialog.
>>  record_route_preset
>> ("proxy.ip.address.here");
>>  }
>>  # route it out to whatever destination was
>> set by loose_route()
>>  # in $du (destination URI).
>>  route(1);
>> ...
>> route[1] {
>>  # for INVITEs enable some additional helper routes
>>  if (is_method("INVITE")) {
>>  t_on_branch("1");
>>  t_on_reply("1");
>>  t_on_failure("1");
>>  if(has_body("application/sdp")) {
>>  rtpproxy_offer 
>> ("frc","proxy.ip.address.here");
>>  xlog ("Setting rtpproxy_offer");
>>  }
>>  if (isbflagset(6)) {
>>  fix_nated_contact();
>>  }
>>
>>  }
>>
>>
>>
>>
>> -- FIRST REINVITE
>>
>> U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
>> INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone  
>> SIP/
>> 2.0.
>> Via: SIP/2.0/UDP carrier.ip.address.here:
>> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
>> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
>> From: > 2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
>> +1+ad440023+8233f214.
>> To: "Thamer Al-Harbash" > 1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
>> CSeq: 878247939 INVITE.
>> Expires: 180.
>> Min-SE: 1800.
>> Session-Expires: 1800;refresher=uac.
>> Supported: 100rel,timer.
>> Max-Forwards: 69.
>> Contact: .
>> Content-Type: application/sdp.
>> Content-Length: 216.
>> Route: .
>> .
>> v=0.
>> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
>> s=-.
>> c=IN IP4 carrier.ip.address.here.
>> t=0 0.
>> m=audio 10044 RTP/AVP 0 101.
>> a=sendrecv.
>> a=ptime:20.
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-15.
>>
>>
>> U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
>> SIP/2.0 100 Giving a try.
>> Via: SIP/2.0/UDP carrier.ip.address.here:
>> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
>> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
>> From: > 2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
>> +1+ad440023+8233f214.
>> To: "Thamer Al-Harbash" > 1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
>> CSeq: 878247939 INVITE.
>> Server: OpenSIPS (1.6.0-notls (i386/linux)).
>> Content-Length: 0.
>> .
>>
>> U our.proxy.ip.address:5060 -> uac.ip.address.here:5060
>> INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone  
>> SIP/
>> 2.0.
>> Record-Route: .
>> Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
>> Via: SIP/2.0/UDP carrier.ip.address.here:
>> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
>> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
>> From: > 2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
>> +1+ad440023+8233f214.
>> To: "Thamer Al-Harbash" > 1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
>> CSeq: 878247939 INVITE.
>> Expires: 180.
>> Min-SE: 1800.
>> Session-Expires: 1800;refresher=uac.
>> Supported: 100rel,timer.
>> Max-Forwards: 68.
>> Contact: .
>> Cont

Re: [OpenSIPS-Users] Config Suggestions Request (SIP Trunks)

[Paul Cupis]

Mike O'Connor wrote:
> I've never once been able to get sipXecs to send out a register packet,
> the are very clear in the documentation that they expect a sip trunk. ie
> static configuration.

Have you tried using the sipXbridge module?

http://sipx-wiki.calivia.com/index.php/SipXbridge_Overview_and_Configuration

Regards,


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

Re: [OpenSIPS-Users] What is protocol/port mismatch?

[opensipslist]

Hello Bogdan,

An jeu., févr 04, 2010, Bogdan-Andrei Iancu schrieb:
>The backtrace from gdb seams really corrupted, but the pstack
>output is a bit consistent.
>
Sorry about that.

>What is strange is that dlg_validate_dialog () seams to call
>fm_realloc() which is not in the script.
>
Maybe a linked library is calling it?

>So, to eliminate any possibility of a mem corruption (the crash was
>in the mem manager), I suggest to compile the mem debugger to see
>if there are no mem issues (mem overwritten, double free, etc).
>
Good idea but... What do you mean by 'mem debugger'?

  $ w3m http://www.opensips.org/
  Results of search for  memory debugger:
  0 pages found out of 318 pages searched.

  opensips-1.6.1-tls $ grep -i 'mem.*debugger' *
  opensips-1.6.1-tls $

I see a variety of things on the page 'Resources/Documentation/
Out Of Memory' http://www.opensips.org/Resources/DocsTsMem, but
I'm not sure if you are referring to it which one exactly then?

Regards,
Brian

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

Re: [OpenSIPS-Users] B2BUA help

[opensipslist]

Hello Anca,

An ven., janv 29, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> An lun., janv 04, 2010, Anca Vamanu schrieb:
>>> I see that you say that the prepaid scenario does not work for you.
>>> What version are you testing with?
>>>
>>   Solaris 11 x86 (nv-b91)
>>   OpenSIPS 1.6.0 with TLS
>>
>> I've copied the example 'prepaid.xml' word for word from the URL:
>>
>>   http://www.opensips.org/Resources/B2buaTutorial16
>>
>> Here are the relevant parts of the route script:
>>
>> listen = udp:name.host.tld:5060
>> listen = tls:name.host.tld:5061
>>
>> modparam("tm", "pass_provisional_replies", 1)
>> modparam("b2b_entities", "server_address", "sip:b2...@name.host.tld")
>> modparam("b2b_logic", "script_scenario", 
>> "/pfx/etc/opensips/b2bua/prepaid.xml")
>>
>> if (has_totag()) {
>> if (loose_route()) {
>> # code here
>> }
>> }
>>
>> if (!is_method("REGISTER|MESSAGE")) {
>> record_route();
>> }
>>
>> if (is_method("INVITE") && src_ip != myself) {  # Start of B2BUA
>> if (!t_newtran()) { # logic block, do
>> sl_reply_error();   # media announcements
>> exit;   # to users
>> }
>> b2b_init_request("prepaid", "sip:playso...@name.host.tld:5080", 
>> "sip:playso...@name.host.tld:5080");
>> exit;
>> }
>>
>> if (src_ip != myself) {
>> if ($hdr(P-hint) != "outbound") {
>> append_hf("P-hint: outbound\r\n");
>> }
>> }
>>
>> Does that look like it should work? Is 't_newtran' necessary?
>>
>t_newtran is necessary because b2b should not handle retransmissions.
>And yes, the configuration file seems correct and should work. If it
>doesn't, try to find the exact problem. Check if there are errors in
>opensips log and watch the network traffic.
>
I've changed the parameters to:

  b2b_init_request("prepaid", "sip:playso...@name.host.tld:5080;transport=tcp", 
"sip:playso...@name.host.tld:5080;transport=tcp");

...because name.host.tld is listening on TCP port 5080. Before,
the B2BUA modules were sending over TLS, which is how the original
INVITE from the UAC is sent. Is there a better way to tell the B2BUA
modules to use TCP rather than another transport?

My main question now, is that the host name.host.tld is getting the
message, but challenging the B2BUA logic with a WWW-Authenticate 401
message. This gets passed implicitly back to the UAC which sent the
INVITE, however it seems that the B2BUA modules strip the WWW-
Authenticate header so that the UAC only sees a 'sanitized'
401 SIP message and cannot authenticate.

How can I adjust the prepaid scenario to accommodate 401 challenges?

Regards,
Brian

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

Re: [OpenSIPS-Users] high-availability - senario

[Julien Chavanton]

Option 2 works fine for me.
 
Thanks



From: users-boun...@lists.opensips.org on behalf of Stanislaw Pitucha
Sent: Tue 02/02/2010 3:03 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] high-availability - senario



On 02.02.2010 14:17, Julien Chavanton wrote:
> I still have a problem with binding all IP some headers do not have the IP 
> set :
> 
> Record-Route: .
> Via: SIP/2.0/UDP 0.0.0.0;branch=z9hG4bKfc58.1427b764.0.
> 
> Is there a way to tell Opensip to use the routing source IP, or other 
> alternative ?

There are two options, (never used the first one though - it might work):

1) advertised_address="1.2.3.4" (your real ip)

2) Set ip_nonlocal_bind via sysctl, which will allow you to bind to an
interface even if it's not available on that host. You can have a hot
standby host this way (on the virtual address), because it will start
getting messages as soon as you update the routing. Just bind to the
address you want instead of 0.0.0.0.

___
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] Starting OpenXCAP without any logs

[CheeWii]

Following your suggestions,I really make openxcap running in fork mode
successfully~ Thank you ,keep you posted !:)



2010/2/4 Saúl Ibarra Corretgé 

> Hi,
>
> El 03/02/10 15:49, CheeWii escribió:
> > Thanks a lot !
> > Looking forward to your reply kindly~ : )
> >
>
> Last night I setup a machine with the same package versions as yours and
> I easily reproduced the issue: OpenXCAP rums OK in foreground, but it
> fails to start in background.
>
> The issue is related to python-application package, at least in the
> version Debian Squeeze is packaging: 1.2.1
>
> To workaround the issue you may install python-application version 1.1.5
> as follows:
>
> wget
>
> http://pypi.python.org/packages/source/p/python-application/python-application-1.1.5.tar.gz
> tar zxvf python-application-1.1.5.tar.gz
> cd python-application-1.1.5
> python setup.py install
>
> I'll look into the 1.2.1 version issue, but this should do it ;) Thanks
> for the report!
>
>
> Kind regards,
>
> --
>  Saúl Ibarra Corretgé
> AG Projects
>
> ___
> 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] BYE - 404 not here

[Max Mühlbronner]

sorry, of course, here are the invites:


*Invite from asterisk --> opensips*

U 62.66.66.67:5060 -> 62.66.66.66:5060
INVITE sip:123549...@62.66.66.66 SIP/2.0.
Via: SIP/2.0/UDP 62.66.66.67:5060;branch=z9hG4bK16ff74c2;rport.
Max-Forwards: 70.
From: "49302332434343" ;tag=as1fcd8c32.
To: .
Contact: .
Call-ID: 7061c14c469285fc782f31d128791...@62.66.66.67.
CSeq: 102 INVITE.
User-Agent: INES.
Date: Thu, 04 Feb 2010 10:33:10 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 290.
.
v=0.
o=root 992341641 992341641 IN IP4 62.66.66.67.
s=Asterisk PBX 1.6.0-beta9.
c=IN IP4 62.66.66.67.
t=0 0.
m=audio 32482 RTP/AVP 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.



*Invite from opensips --> pstngw:

*
U 62.66.66.66:5060 ->  213.20.11.11:5060
INVITE sip:49...@213.20.11.11 SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP 62.66.66.66;branch=z9hG4bKbee2.9124c5b3.0.
Via: SIP/2.0/UDP 
62.66.66.67:5060;received=62.66.66.67;branch=z9hG4bK16ff74c2;rport=5060.
Max-Forwards: 69.
From: "49302332434343" ;tag=as1fcd8c32.
To: .
Contact: .
Call-ID: 7061c14c469285fc782f31d128791...@62.66.66.67.
CSeq: 102 INVITE.
User-Agent: INES.
Date: Thu, 04 Feb 2010 10:33:10 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 308.
Session-Expires: 1800.
.
v=0.
o=root 992341641 992341641 IN IP4 62.66.66.66.
s=Asterisk PBX 1.6.0-beta9.
c=IN IP4 62.66.66.66.
t=0 0.
m=audio 55408 RTP/AVP 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.


Hope you can find something useful. Thanks.


Brett Nemeroff schrieb:
> >From my experience, this usually happen either from a configuration 
> file error, or from the terminating UAS who sends the  BYE not sending 
> it to the RURI in the contact header from the original INVITE. Can we 
> see the original INVITE as it hits OpenSIPs?
> -Brett
>
>
> On Thu, Feb 4, 2010 at 4:56 AM, Max Mühlbronner  > wrote:
>
> Hello everyone,
>
> i have a problem when a call is hangup by the callee, i think i
> probably
> have some general routing logic Problem and i cant find any way to
> solve it.
>
> caller --> asterisk (62.66.66.67) --> opensips(62.66.66.66) (+rtpproxy
> on the same machine) --> pstngw (213.20.11.11)
>
> Everything seems to be working fine, i have been testing a long time
> but  i recognized some problem. When the callee rejects the call ,
> (486
> busy) the busy is fine, transmitted back to the caller.
> But if the call is established and the callee hangs up, the BYE is not
> received by the original calling side so it stays connected.
> My opensips knowledge is still very basic, so please excuse if it is
> some dumb routing mistake made by me.
>
> 62.66.66.66 --> opensips
> 62.66.66.67 --> asterisk
> 213.20.11.11 --> pstngw
>
>
> The busy is fine, and transmitted correctly (and callattempt is
> stopped), but the bye is not received on the side where the call was
> originating from (asterisk).
>
>
> U 213.20.11.11:5060  -> 62.66.66.66:5060
> 
> SIP/2.0 486 Busy Here.
> Via: SIP/2.0/UDP 62.66.66.66;branch=z9hG4bKf41a.b1b6523.0.
> Via: SIP/2.0/UDP
> 62.66.66.67:5060;received=62.66.66.67;branch=z9hG4bK79996cc9;rport=5060.
> From: "49302332434343"  >;tag=as67e89fcd.
> To:  >;tag=255533104.
> Call-ID: 2da8e3f7156077231d448a3530a87...@62.66.66.67
> .
> CSeq: 102 INVITE.
> Contact:  >.
> Content-Length: 0.
>
>
> -
>
>
> the not working BYE, followed by 404 not here, which is sent by the
> basic routing block (like in most of the example scripts /
> sl_send_reply("404","Not here");)
>
>
> U 213.20.11.11:5060  -> 62.66.66.66:5060
> 
> BYE sip:49302332434...@62.66.66.67
>  SIP/2.0.
> Via: SIP/2.0/UDP
> 213.20.11.11:5060;branch=z9hG4bK623vjs00c0q1bggou101sdg00
> .1.
> From:  >;tag=960392687.
> To: "49302332434343"  >;tag=as32838038.
> Call-ID: 150c32ca5a8adcb8589445f95e9ff...@62.66.66.67
> .
> CSeq: 1 BYE.
> Max-Forwards: 9.
> Supported: timer.
> 

Re: [OpenSIPS-Users] BYE - 404 not here

[Brett Nemeroff]

>From my experience, this usually happen either from a configuration file
error, or from the terminating UAS who sends the  BYE not sending it to the
RURI in the contact header from the original INVITE. Can we see the original
INVITE as it hits OpenSIPs?
-Brett


On Thu, Feb 4, 2010 at 4:56 AM, Max Mühlbronner  wrote:

> Hello everyone,
>
> i have a problem when a call is hangup by the callee, i think i probably
> have some general routing logic Problem and i cant find any way to solve
> it.
>
> caller --> asterisk (62.66.66.67) --> opensips(62.66.66.66) (+rtpproxy
> on the same machine) --> pstngw (213.20.11.11)
>
> Everything seems to be working fine, i have been testing a long time
> but  i recognized some problem. When the callee rejects the call , (486
> busy) the busy is fine, transmitted back to the caller.
> But if the call is established and the callee hangs up, the BYE is not
> received by the original calling side so it stays connected.
> My opensips knowledge is still very basic, so please excuse if it is
> some dumb routing mistake made by me.
>
> 62.66.66.66 --> opensips
> 62.66.66.67 --> asterisk
> 213.20.11.11 --> pstngw
>
>
> The busy is fine, and transmitted correctly (and callattempt is
> stopped), but the bye is not received on the side where the call was
> originating from (asterisk).
>
>
> U 213.20.11.11:5060 -> 62.66.66.66:5060
> SIP/2.0 486 Busy Here.
> Via: SIP/2.0/UDP 62.66.66.66;branch=z9hG4bKf41a.b1b6523.0.
> Via: SIP/2.0/UDP
> 62.66.66.67:5060;received=62.66.66.67;branch=z9hG4bK79996cc9;rport=5060.
> From: "49302332434343" 
> 
> >;tag=as67e89fcd.
> To: 
> >;tag=255533104.
> Call-ID: 2da8e3f7156077231d448a3530a87...@62.66.66.67.
> CSeq: 102 INVITE.
> Contact: .
> Content-Length: 0.
>
>
> -
>
>
> the not working BYE, followed by 404 not here, which is sent by the
> basic routing block (like in most of the example scripts /
> sl_send_reply("404","Not here");)
>
>
> U 213.20.11.11:5060 -> 62.66.66.66:5060
> BYE sip:49302332434...@62.66.66.67 SIP/2.0.
> Via: SIP/2.0/UDP
> 213.20.11.11:5060;branch=z9hG4bK623vjs00c0q1bggou101sdg00
> .1.
> From: 
> >;tag=960392687.
> To: "49302332434343" 
> 
> >;tag=as32838038.
> Call-ID: 150c32ca5a8adcb8589445f95e9ff...@62.66.66.67.
> CSeq: 1 BYE.
> Max-Forwards: 9.
> Supported: timer.
> Content-Length: 0.
> Route: .
>
>
> U 62.66.66.66:5060 -> 213.20.11.11:5060
> SIP/2.0 404 Not here.
> Via: SIP/2.0/UDP
> 213.20.11.11:5060
> ;rport=5060;received=213.20.11.11;branch=z9hG4bKk4ksmf10eosgjf41m3k0sdg00.1.
> From: 
> >;tag=1126364538.
> To: "49302332434343" 
> 
> >;tag=as1fcd8c32.
> Call-ID: 7061c14c469285fc782f31d128791...@62.66.66.67.
> CSeq: 1 BYE.
> Server: OpenSIPS (1.6.1-notls (i386/linux)).
> Content-Length: 0.
>
>
>
>
> Thanks very much for any help, really appreciated. :)
>
>
> Best Regards
>
> Max M.
>
>
> ___
> 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] Does Opensips Presence Support Content Indirection in PIDF ?

[Anca Vamanu]

Hi Mani,

Can you please tell me in what RFC is CID in PIDF defined?

Regards,

-- 
Anca Vamanu
www.voice-system.ro


mani sivaraman wrote:
> Could any one please let me know if opensips support CID (content 
> indirection) in PIDF PUBLISH and NOTIFY ?. Is there any configuration 
> to be done to enable if it is available ?
> 
>
> ___
> 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] BYE - 404 not here

[Max Mühlbronner]

File attached, Thanks very much for taking a look.

Regards


Andrew Pogrebennyk schrieb:

On 04.02.2010 12:56, Max Mühlbronner wrote:

But if the call is established and the callee hangs up, the BYE is not
received by the original calling side so it stays connected.
My opensips knowledge is still very basic, so please excuse if it is
some dumb routing mistake made by me.


I suppose you have a problem with routing in-dialog requests. Please 
attach your opensips.cfg.




#
# $Id: opensips.cfg 5503 2009-12-9 12:10 max robert muehlbronner $
#
# by Max M. 
#
# Please refer to the Core CookBook at:
#  http://www.opensips.org/index.php?n=Resources.DocsCookbooks
# for a explanation of possible statements, functions and parameters.
#


### Global Parameters #

debug=3
log_stderror=no
log_facility=LOG_LOCAL7
fork=yes
children=4

/* uncomment the next line to disable TCP (default on) */
#disable_tcp=yes
#disable_dns_blacklist=no
#dns_try_ipv6=yes
#auto_aliases=no

port=5060
/* uncomment and configure the following line if you want opensips to
   bind on a specific interface/port/proto (default bind on all available) */
listen=udp:62.133.33.33:5060

### Modules Section 
#set module path
mpath="//lib/opensips/modules/"

loadmodule "db_mysql.so"
loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
#B2BUA Module
loadmodule "b2b_entities.so"
loadmodule "b2b_logic.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
#loadmodule "uri_db.so"
#migration 1.6
loadmodule "uri.so"
loadmodule "xlog.so"
loadmodule "acc.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "alias_db.so"
loadmodule "domain.so"
loadmodule "presence.so"
loadmodule "presence_xml.so"
loadmodule "pua.so"
loadmodule "pua_usrloc.so"
loadmodule "pua_mi.so"
loadmodule "drouting.so"
loadmodule "avpops.so"
loadmodule "dialplan.so"
loadmodule "permissions.so"
loadmodule "group.so"
loadmodule "siptrace.so"
loadmodule "dialog.so"
loadmodule "sst.so"
loadmodule "nathelper.so"
#needed for uac operations
loadmodule "uac.so"

# - setting module-specific parameters ---
modparam("dialog", "dlg_flag", 13)
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_url", "mysql://opensips:opensip...@localhost/opensips16")
modparam("dialog", "timeout_avp", "$avp(i:4242)")
modparam("dialog", "bye_on_timeout_flag", 14)
#
modparam("sst", "sst_flag", 6)
modparam("sst", "timeout_avp", "$avp(i:4242)")
#modparam("sst", "min_se", 2400) # Must be >= 90
modparam("sst", "min_se", 1800) # Must be >= 90# minimum = 1800 (1799 = ERR 
422 value too small)
#


 B2BUA ###
#The functionality is obvious from the name and what this service does is
#to hide the network topology from the parties that establish a dialog.
#To achieve this, the B2BUA poses itself in the middle and established dialogs 
with both parties.
#Then all it will do next will be to translate a receipt request or reply into 
the dialog from the other side and forward it to the peer entity.
##
modparam("b2b_entities", "server_address", "sip:s...@62.133.33.33:5060")
#modparam("b2b_logic", "script_scenario", 
"/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml")
#modparam("b2b_logic", "extern_scenario", 
"/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml")
#modparam("b2b_entities", "script_req_route", "b2b_request")
#modparam("b2b_entities", "script_reply_route", "b2b_reply")


# - 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 cope with most of the UAs
modparam("rr", "enable_full_lr", 1)
# do not append from tag to the RR (no need for this script)
#modparam("rr", "append_fromtag", 0)
###needed for uac module
modparam("rr", "append_fromtag", 1)

# - registrar params -
#migration 1.6
#modparam("registrar", "method_filtering", 1)
/* uncomment the next line to disable parallel forking via location */
# modparam("registrar", "append_branches", 0)
/* uncomment the next line not to allow more than 10 contacts per AOR */
#modparam("registrar", "max_contacts", 10)

# - usrloc params -
modparam("usrloc", "db_mode",   0)
/* uncomment the following lines if you want to enable DB persistency
   for location entries */
modparam("usrloc", "db_mode",   2)
modparam("usrloc", "db_url",
"mysql://opensips:opensip...@localhost/opensips16")

# - uri_db params -
/* by default we disable the DB support in the module as we do not need it
   in this configuration */
#modparam("uri_db", "use_uri_table", 0)
modparam("uri", "use_uri_table", 0)
#migration 1.6 (uri_radius uri_db merged with uri module)
#modparam("uri_db", "db_url", "")

# - acc params -
/* what 

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Saúl Ibarra Corretgé]

Hi Magnus,

El 04/02/10 12:54, Magnus Burman escribió:
> Hmm, you are right, that wasn't the full syslog for that call.
> Investigating further I see that I get the following:
>
> Jan 11 22:28:07 sbc1 /usr/sbin/opensips[27792]:
> CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg
> 0x7f5e880692a0 [1305:480665684] with clid
> 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714' and tags
> 'e-13c4-10b392b-75e19db4-10b392b' ''
>
> This is right after the call has been established; the next event in the
> sip trace is at 22:53:40, the re-invite.
>
> According to a year old post by Bogdan
> (http://www.mail-archive.com/users@lists.opensips.org/msg00700.html)
> this means that ACK is received before 200 OK.
>
> Here's the sip trace up to the point of the dialog error:
> 22:27:56.376925 Trunk -> Proxy : INVITE
> 22:27:56.381153 Proxy -> Trunk : 100 TRYING
> 22:27:56.381215 Proxy -> UA___ : INVITE
> 22:27:56.437339 UA___ -> Proxy : 100 TRYING
> 22:27:56.552454 UA___ -> Proxy : 180 RINGING
> 22:27:56.552530 Proxy -> Trunk : 180 RINGING
> 22:28:07.179499 UA___ -> Proxy : 200 OK
> 22:28:07.182204 Proxy -> Trunk : 200 OK
> 22:28:07.197002 Trunk -> Proxy : ACK
> 22:28:07.197158 Proxy -> UA___ : ACK
>
> Could this be the source of the problem?
>

Indeed. Whats happening is that the dialog state is 'broken' because 
OpenSIPS received the ACK before actually processing the 200OK (the 
200OK is processed *after* it's sent). If you use engage_media_proxy 
function, MediaProxy will rely on the dialog state to internally call 
use_media_proxy function, but when that error happens MediaProxy doesn't 
act accordingly because the dialog state is broken.

So, I see 3 possible solutions:

1- Use the manual functions (use_media_proxy and end_media_session) 
instead of engage_media_proxy.

2- Backport the dialog module fixes to your OpenSIPS version (revisions 
5420 and 5422)

3- Upgrade OpenSIPS to a more recent version which includes the fix already.



Regards,


-- 
Saúl Ibarra Corretgé
AG Projects

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

Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)

[Magnus Burman]

Hmm, you are right, that wasn't the full syslog for that call. Investigating
further I see that I get the following:

Jan 11 22:28:07 sbc1 /usr/sbin/opensips[27792]:
CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg
0x7f5e880692a0 [1305:480665684] with clid
'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714' and tags
'e-13c4-10b392b-75e19db4-10b392b' ''

This is right after the call has been established; the next event in the sip
trace is at 22:53:40, the re-invite.

According to a year old post by Bogdan (
http://www.mail-archive.com/users@lists.opensips.org/msg00700.html) this
means that ACK is received before 200 OK.

Here's the sip trace up to the point of the dialog error:
22:27:56.376925 Trunk -> Proxy : INVITE
22:27:56.381153 Proxy -> Trunk : 100 TRYING
22:27:56.381215 Proxy -> UA___ : INVITE
22:27:56.437339 UA___ -> Proxy : 100 TRYING
22:27:56.552454 UA___ -> Proxy : 180 RINGING
22:27:56.552530 Proxy -> Trunk : 180 RINGING
22:28:07.179499 UA___ -> Proxy : 200 OK
22:28:07.182204 Proxy -> Trunk : 200 OK
22:28:07.197002 Trunk -> Proxy : ACK
22:28:07.197158 Proxy -> UA___ : ACK

Could this be the source of the problem?

Best Regards,
Magnus

2010/2/3 Saúl Ibarra Corretgé 

> Hi,
>
> El 03/02/10 14:43, Magnus Burman escribió:
> > Now I see what you're saying. I thought mediaproxy used the wrong port
> > in the re-invite, while it is in fact not engaged at all and thus the
> > original IP and port is sent on. That makes a lot of sense, thank you.
> >
> > According to the docs the engage_media_proxy should only be called once
> > on the initial invite thou and after that use the dialog module to trace
> > the dialog. Any suggestions as how to debug where it fails? I'm not
> > getting any output in the syslog.
> >
>
> You are correct, the by calling engage_mediaproxy the dialog module
> should take care. However, it's surprising that this only happens
> sometimes, so it's harder to debug :( Is the syslog you pasted in your
> earlier mail the only output you get for that call? Any warning from the
> dialog module?
>
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
> ___
> 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] BYE - 404 not here

[Andrew Pogrebennyk]

On 04.02.2010 12:56, Max Mühlbronner wrote:
> But if the call is established and the callee hangs up, the BYE is not
> received by the original calling side so it stays connected.
> My opensips knowledge is still very basic, so please excuse if it is
> some dumb routing mistake made by me.

I suppose you have a problem with routing in-dialog requests. Please 
attach your opensips.cfg.

-- 
Sincerely,
Andrew Pogrebennyk

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

[OpenSIPS-Users] BYE - 404 not here

[Max Mühlbronner]

Hello everyone,

i have a problem when a call is hangup by the callee, i think i probably 
have some general routing logic Problem and i cant find any way to solve it.

caller --> asterisk (62.66.66.67) --> opensips(62.66.66.66) (+rtpproxy 
on the same machine) --> pstngw (213.20.11.11)
  
Everything seems to be working fine, i have been testing a long time 
but  i recognized some problem. When the callee rejects the call , (486 
busy) the busy is fine, transmitted back to the caller.
But if the call is established and the callee hangs up, the BYE is not 
received by the original calling side so it stays connected.
My opensips knowledge is still very basic, so please excuse if it is 
some dumb routing mistake made by me.

62.66.66.66 --> opensips
62.66.66.67 --> asterisk
213.20.11.11 --> pstngw


The busy is fine, and transmitted correctly (and callattempt is 
stopped), but the bye is not received on the side where the call was 
originating from (asterisk).


U 213.20.11.11:5060 -> 62.66.66.66:5060
SIP/2.0 486 Busy Here.
Via: SIP/2.0/UDP 62.66.66.66;branch=z9hG4bKf41a.b1b6523.0.
Via: SIP/2.0/UDP 
62.66.66.67:5060;received=62.66.66.67;branch=z9hG4bK79996cc9;rport=5060.
From: "49302332434343" ;tag=as67e89fcd.
To: ;tag=255533104.
Call-ID: 2da8e3f7156077231d448a3530a87...@62.66.66.67.
CSeq: 102 INVITE.
Contact: .
Content-Length: 0.


-


the not working BYE, followed by 404 not here, which is sent by the 
basic routing block (like in most of the example scripts / 
sl_send_reply("404","Not here");)


U 213.20.11.11:5060 -> 62.66.66.66:5060
BYE sip:49302332434...@62.66.66.67 SIP/2.0.
Via: SIP/2.0/UDP 
213.20.11.11:5060;branch=z9hG4bK623vjs00c0q1bggou101sdg00   
  
.1.
From: ;tag=960392687.
To: "49302332434343" ;tag=as32838038.
Call-ID: 150c32ca5a8adcb8589445f95e9ff...@62.66.66.67.
CSeq: 1 BYE.
Max-Forwards: 9.
Supported: timer.
Content-Length: 0.
Route: .


U 62.66.66.66:5060 -> 213.20.11.11:5060
SIP/2.0 404 Not here.
Via: SIP/2.0/UDP 
213.20.11.11:5060;rport=5060;received=213.20.11.11;branch=z9hG4bKk4ksmf10eosgjf41m3k0sdg00.1.
From: ;tag=1126364538.
To: "49302332434343" ;tag=as1fcd8c32.
Call-ID: 7061c14c469285fc782f31d128791...@62.66.66.67.
CSeq: 1 BYE.
Server: OpenSIPS (1.6.1-notls (i386/linux)).
Content-Length: 0.




Thanks very much for any help, really appreciated. :)


Best Regards

Max M.


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

[OpenSIPS-Users] Res: RTP listener

[Flavio Goncalves]

Hi Yannick

There is an open source software http://oreka.sourceforge.net/ capable not only 
to listen, but to record and manage the calls. It requires a separate machine 
connected to a SPAN/MONITOR port of the network switch. I have tested both 
OREKA and the RTP Proxy feature, it works, you will need to mix the caller and 
callee streams to have the recording, the format is similar to the one found on 
wireshark. With RTP proxy, you have the advantage to be able to force the 
stream to pass on your server, with OREKA you need to record close to the 
gateways, but it is simpler to record and manage the calls. 

Good luck, 

Flavio E. Goncalves





De: Bogdan-Andrei Iancu 
Para: OpenSIPS users mailling list 
Enviadas: Quinta-feira, 4 de Fevereiro de 2010 7:41:14
Assunto: Re: [OpenSIPS-Users] RTP listener

Hi Yannick ,

check http://lists.opensips.org/pipermail/users/2010-January/010515.html

Regards,
Bogdan

Yannick LE COENT wrote:
>
> Hello all,
>
>  
>
> I would to listen and record RTP streams in real-time.
>
>  
>
> RTP proxy seems to be able to record RTP streams in pcap format.
>
>  
>
> Is there a way to listen RTP streams in real-time?
>
>  
>
> Thanks for any help,
>
> Yannick
>
> 
>
> ___
> 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

users@lists.opensips.org

[Andrew Pogrebennyk]

On 29.01.2010 11:29, Bogdan-Andrei Iancu wrote:
> I doubt you can change that as RTPproxy is not decoding the RTP stream -
> as the name says, the tool is only RTP aware, so cannot interpret the
> content. But I guess you can google for some other audio tools to help
> mixing the 2 streams.

Check this page: http://www.rtpproxy.org/wiki/RTPproxy/FAQ
I didn't try the rtpbreak/sox approach though. We are using proprietary 
tool here. I think that sox doesn't decode the g723 and g729 codecs.

One thing to keep in mind is that the RTP headers are not written in the 
platform-independent format, so expect they be decoded only on the same 
platform as the one that created the recording.

-- 
Sincerely,
Andrew Pogrebennyk

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

users@lists.opensips.org

[Andrew Pogrebennyk]

On 28.01.2010 11:07, Indiver wrote:
> I forgot to mention that files are not storing by callee or caller number.
> Moreover it is taking its own unique caller id. How to over come this in
> order to modify the recording file name as callee<->caller and time stamp
> format.

File names are created using template: 
"${callid}=${tag}.${direction}.${pstype}", where $direction = 'a' or 
'o', $pstype = 'rtp' or 'rtcp'. See rtpp_record.c and functions ropen() 
and rwrite().

-- 
Sincerely,
Andrew Pogrebennyk

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

Re: [OpenSIPS-Users] priorities with opensips

[wüber]

Thank you Bogdan!
this is really a useful hint!
-- 
View this message in context: 
http://n2.nabble.com/priorities-with-opensips-tp4506066p4512524.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

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

Re: [OpenSIPS-Users] opensips 1.6.1 crashes on NOTIFY?

[Bogdan-Andrei Iancu]

Hi Alex,

updating from 1.6 SVN branch, are these crashes still happening ?

Regards,
Bogdan

Alexander wrote:
> Any ideas? I'm afraid to touch something and make things worse :)
>
> 22 декабря 2009 г. 14:23 пользователь Alexander  > написал:
>
> What about this one:
>
> Program terminated with signal 11, Segmentation fault.
> [New process 15892]
> #0 0x00e1fddb in t_lookup_request (p_msg=0x81d2f20,
> leave_new_locked=1) at ../../mem/../hash_func.h:65
> 65 for (p=s2->s; p<=(end-4); p+=4){
> (gdb) bt
> #0 0x00e1fddb in t_lookup_request (p_msg=0x81d2f20,
> leave_new_locked=1) at ../../mem/../hash_func.h:65
> #1 0x00e21859 in t_newtran (p_msg=0x81d2f20) at t_lookup.c:1051
> #2 0x00e243a0 in w_t_newtran (p_msg=0x81d2f20, foo=0x0, bar=0x0)
> at tm.c:1006
> #3 0x080545dd in do_action (a=0x81cc30c, msg=0x81d2f20) at
> action.c:967
> #4 0x08057308 in run_action_list (a=0x81cc30c, msg=0x81d2f20) at
> action.c:139
> #5 0x080af2be in eval_expr (e=0x81cc378, msg=0x81d2f20, val=0x0)
> at route.c:1240
> #6 0x080aed39 in eval_expr (e=0x81cc3a4, msg=0x81d2f20, val=0x0)
> at route.c:1553
> #7 0x080aeccf in eval_expr (e=0x81cc3d0, msg=0x81d2f20, val=0x0)
> at route.c:1558
> #8 0x080533c2 in do_action (a=0x81cc770, msg=0x81d2f20) at
> action.c:689
> #9 0x08057308 in run_action_list (a=0x81cc770, msg=0x81d2f20) at
> action.c:139
> #10 0x080554a7 in do_action (a=0x81c85b4, msg=0x81d2f20) at
> action.c:119
> #11 0x08057308 in run_action_list (a=0x81c85b4, msg=0x81d2f20) at
> action.c:139
> #12 0x080554dd in do_action (a=0x81c868c, msg=0x81d2f20) at
> action.c:706
> #13 0x08057308 in run_action_list (a=0x81c868c, msg=0x81d2f20) at
> action.c:139
> #14 0x08056625 in do_action (a=0x81c86f8, msg=0x81d2f20) at
> action.c:712
> #15 0x08057308 in run_action_list (a=0x81c86f8, msg=0x81d2f20) at
> action.c:139
> #16 0x08056625 in do_action (a=0x81c8764, msg=0x81d2f20) at
> action.c:712
> #17 0x08057308 in run_action_list (a=0x81c8764, msg=0x81d2f20) at
> action.c:139
> #18 0x08056625 in do_action (a=0x81c87d0, msg=0x81d2f20) at
> action.c:712
> #19 0x08057308 in run_action_list (a=0x81c87d0, msg=0x81d2f20) at
> action.c:139
> #20 0x08056625 in do_action (a=0x81c883c, msg=0x81d2f20) at
> action.c:712
> #21 0x08057308 in run_action_list (a=0x81c883c, msg=0x81d2f20) at
> action.c:139
> #22 0x08056625 in do_action (a=0x81c88a8, msg=0x81d2f20) at
> action.c:712
> #23 0x08057308 in run_action_list (a=0x81c88a8, msg=0x81d2f20) at
> action.c:139
> #24 0x080554dd in do_action (a=0x81ca360, msg=0x81d2f20) at
> action.c:706
> #25 0x08057308 in run_action_list (a=0x81bd578, msg=0x81d2f20) at
> action.c:139
> #26 0x080576a3 in run_top_route (a=0x81bd578, msg=0x81d2f20) at
> action.c:119
> #27 0x0809ddf2 in receive_msg (
> buf=0x8192380 "NOTIFY sip:62.117.120.98 SIP/2.0\r\nVia:
> SIP/2.0/UDP 194.190.163.139:5061;branch=z9hG4bK-d5a4f117\r\nFrom:
> 206401  >;tag=d825811556491d55o0\r\nTo:
> \r\nCall-ID: d42b6"..., len=347,
> rcv_info=0xbfd71e84) at receive.c:162
> #28 0x080e5056 in udp_rcv_loop () at udp_server.c:492
> #29 0x08070adf in main (argc=3, argv=0xbfd72094) at main.c:821
>
> 22 декабря 2009 г. 13:10 пользователь Anca Vamanu
> mailto:a...@opensips.org>> написал:
>
> Hi Alexander,
>
> Unless you modified the sources, this is not the right
> backtrace. The
> line numbers do not correspond with the ones in the trace.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro 
>
>
> Alexander wrote:
> > Oh, found one. Seems to be right core file. GDB says:
> >
> > #0 0x080fbb52 in parse_params (_s=0xec, _c=695, _h=0x81d44bc,
> > _p=0x1d4) at parser/../trim.h:61
> > #1 0x080f135f in parse_msg (buf=0xb61eacc4 "э>\035\bп╛\036╤",
> > len=135861088, msg=0x305) at parser/msg_parser.c:567
> > #2 0x080ed9c7 in aaa_prot_bind (aaa_url=0xb61eacac,
> prot=0x80) at
> > aaa/aaa.c:85
> > #3 0x003b9205 in ?? ()
> > #4 0xb61eacac in ?? ()
> > #5 0x0080 in ?? ()
> > #6 0x003e2df4 in ?? ()
> > #7 0x371f3654 in ?? ()
> > #8 0x0007 in ?? ()
> > #9 0x08180e85 in _tr_buffer ()
> > #10 0x08180e81 in _tr_buffer ()
> > #11 0x in ?? ()
> >
> > 2009/12/22 Alexander    >>
> >
> > I have no core file for now:
> >
> >
> > Dec 22 11:02:08 srv opensips[26182]: INFO:core:handle_sigs: core
> > was not generated
> >
> > Stran

Re: [OpenSIPS-Users] Need help Nathelper + rtpproxy

[Bogdan-Andrei Iancu]

Hi,

do not pass both I and E flags !!  As you call force_rtp_proxy() twice 
(once for request and once for reply), you need to pass once the I and 
next one the E flags, depending which interface you want RTPP to use for 
the request or reply.

Regards,
Bogdan

Zilla1000 wrote:
> I am having problem setup the correct IP for RTP, please help.
>
> I have the same setup, and the only difference is the SIP server at calling
> party using a different for RTP stream -
>
> IP Phone  192.168.1.100(Opensips+Rtpproxy)10.10.1.10- SIP Server
> 10.10.1.20
>   
> 
> +Media Server 10.10.1.21
>
> I am using the same config with force_rtp_proxy("oie") when processing the
> response; but the rtpproxy does not pickup the IP in SDP (10.10.1.21), it
> uses the signaling IP (10.10.1.20). Any suggestion ?
>
> Thanks.
>   


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


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

Re: [OpenSIPS-Users] RTP listener

[Bogdan-Andrei Iancu]

Hi Yannick ,

check http://lists.opensips.org/pipermail/users/2010-January/010515.html

Regards,
Bogdan

Yannick LE COENT wrote:
>
> Hello all,
>
>  
>
> I would to listen and record RTP streams in real-time.
>
>  
>
> RTP proxy seems to be able to record RTP streams in pcap format.
>
>  
>
> Is there a way to listen RTP streams in real-time?
>
>  
>
> Thanks for any help,
>
> Yannick
>
> 
>
> ___
> 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

Re: [OpenSIPS-Users] TLS call failed

[Bogdan-Andrei Iancu]

Hi Steven,

For the NOKIA N97, could you post the entire log (debug 4) for the 
INVITE part (covering the receiving of the INVITE also) ?

Regards,
Bogdan

doolin wu wrote:
> Hello,
>  
> I'm trying use TLS feature of OpenSIPS-1.5-tls. TLS was 
> configured and server run successfully.
> I tried to make 2 SIP UAs work with my OpenSIPS-1.5-tls, but all of 
> them are failed.
> Here is my settings:
> >Server:
> tls_verify_server = 0
> tls_verify_client = 0
> tls_require_client_certificate = 0
> tls_method = TLSv1
> tls_certificate = 
> "/usr/local/opensips.1.5.tls/etc/opensips/tls/user/user-cert.pem"
> tls_private_key = 
> "/usr/local/opensips.1.5.tls/etc/opensips/tls/user/user-privkey.pem"
> tls_ca_list = 
> "/usr/local/opensips.1.5.tls//etc/opensips/tls/user/user-calist.pem"
>  
> >Client:
> The self-signed rootCA (tls\rootCA\cacert.pem)  was imported in to 
> client successfully
>  
> First one UA is VoIP client on NOKIA N97. Client register to SIP 
> server with TLS successfully, but when make call from N97 to others I 
> got error code 477 Send failed (477/TM).
> I traced opensips, looks like opensips tried to forward the invite to 
> callee, but the tls socket failed to send the request.
> Logs from opensips here:
>
> Feb  2 07:19:32 [5779] ERROR:core:tcp_send: failed to send
> Feb  2 07:19:32 [5779] ERROR:tm:msg_send: tcp_send failed
> Feb  2 07:19:32 [5779] ERROR:tm:t_forward_nonack: sending request
> failed
> Feb  2 07:19:32 [5779] DBG:tm:t_relay_to: t_forward_nonack
> returned error
> Feb  2 07:19:32 [5779] DBG:core:parse_headers: flags=
> Feb  2 07:19:32 [5779] DBG:core:check_via_address: params
> 10.57.52.186, 10.57.52.186, 0
> Feb  2 07:19:32 [5779] DBG:tm:cleanup_uac_timers: RETR/FR timers reset
> Feb  2 07:19:32 [5779] DBG:tm:set_timer: relative timeout is 30
> Feb  2 07:19:32 [5779] DBG:tm:insert_timer_unsafe: [0]: 0xb61a180c
> (92)
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: tcp connection found
> (0xb61d7908), acquiring fd
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: c= 0xb61d7908, n=8
> Feb  2 07:19:32 [5787] DBG:core:handle_ser_child: read response=
> b61f4b48, 2, fd 41 from 16 (5779)
> Feb  2 07:19:32 [5787] DBG:core:tcpconn_add: hashes: 719, 4
> Feb  2 07:19:32 [5787] DBG:core:io_watch_add:
> io_watch_add(0x817bbc0, 41, 2, 0xb61f4b48), fd_no=31
> Feb  2 07:19:32 [5787] DBG:core:handle_ser_child: read response=
> b61f4b48, -2, fd -1 from 16 (5779)
> Feb  2 07:19:32 [5787] DBG:core:io_watch_del: io_watch_del
> (0x817bbc0, 41, -1, 0x10) fd_no=32 called
> Feb  2 07:19:32 [5787] DBG:core:tcpconn_destroy: destroying
> connection 0xb61f4b48, flags 0002
> Feb  2 07:19:32 [5787] DBG:core:tls_close: closing SSL connection
> Feb  2 07:19:32 [5787] DBG:core:tls_update_fd: New fd is 41
> Feb  2 07:19:32 [5787] DBG:core:tls_shutdown: shutdown successful
> Feb  2 07:19:32 [5787] DBG:core:tls_tcpconn_clean: entered
> Feb  2 07:19:32 [5787] DBG:core:handle_ser_child: read response=
> b61d7908, 1, fd -1 from 16 (5779)
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: after receive_fd: c=
> 0xb61d7908 n=4 fd=34
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: sending...
> Feb  2 07:19:32 [5779] DBG:core:tls_update_fd: New fd is 34
> Feb  2 07:19:32 [5779] DBG:core:tls_write: write was successful
> (374 bytes)
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: after write: c=
> 0xb61d7908 n=374 fd=34
> Feb  2 07:19:32 [5779] DBG:core:tcp_send: buf=
>  
>
> Could some one help to have a look the problem?
>
>  
>
> Meanwhile, I use eyebeam 1.5 as client. Things more bad as the 
> register failed.
> I traced eyebeam and found the eyebeam failed when verify server's 
> certificate. Here I have something unclear about use the certificates 
> between client and server.
> To configure run opensips with TLS(just talk about the self-signed 
> case), we should create two certififcates. one is self-signed rootCA 
> (tls\rootCA\cacert.pem), another one is a certificate signed by rootCA 
> (tls\user\user-cert.pem).  The server hold rootCA by config 
> tls_ca_list and send certificate (by config tls_certificate) to client 
> when handshark with client.
> My question is how to config certificate in client side. In these two 
> cases (use N97 and eyebeam), I just imported the rootCA to my client.
> Is it right for config certificate on client? N97 seems OK with the 
> rootCA. But eyebeam failed. The guidline of eyebeam says:
>
> During the TLS handshke, *the TLS server has to send to the client
> the whole chain of certificate excepting the root certificate*;
> the client must posses the root certificate otherwise the
> authentication cannot happen.
>  
>
> Any idea to config opensips send 'the whole chain of certificate 
> excepting the root certificate' ?
>  
> Thanks for your kindly support

Re: [OpenSIPS-Users] priorities with opensips

[Bogdan-Andrei Iancu]

Well, this might be possible using a simple external script.
If you put all the calls through the dialog module, you have an external 
MI command to terminate a dialog (from the proxy). So what you need is a 
script to query (via MI - dlg_list command) what are the active calls 
and to terminate (via MI, dlg_end_dlg command) all the found dialogs.

Regards,
Bogdan

wüber wrote:
> yes, exactly!
> thanks a lot.
>   


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


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

Re: [OpenSIPS-Users] Starting OpenXCAP without any logs

[Saúl Ibarra Corretgé]

Hi,

El 03/02/10 15:49, CheeWii escribió:
> Thanks a lot !
> Looking forward to your reply kindly~ : )
>

Last night I setup a machine with the same package versions as yours and 
I easily reproduced the issue: OpenXCAP rums OK in foreground, but it 
fails to start in background.

The issue is related to python-application package, at least in the 
version Debian Squeeze is packaging: 1.2.1

To workaround the issue you may install python-application version 1.1.5 
as follows:

wget 
http://pypi.python.org/packages/source/p/python-application/python-application-1.1.5.tar.gz
tar zxvf python-application-1.1.5.tar.gz
cd python-application-1.1.5
python setup.py install

I'll look into the 1.2.1 version issue, but this should do it ;) Thanks 
for the report!


Kind regards,

-- 
Saúl Ibarra Corretgé
AG Projects

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

Re: [OpenSIPS-Users] priority differences between carrierroute and drouting

[Bogdan-Andrei Iancu]

Hi Gabriel,

The selection of the Gateways (from the list for a prefix) is a bit more 
complex in Drouting as you have 3 ways of choosing (including random, 
group based, etc) - see the "sort" param  
http://www.opensips.org/html/docs/modules/devel/drouting.html#id272114.
But indeed, maybe a new mode (for sort) could be added for having 
directly weight.

CR module in opensips is not actively maintained.

Regards,
Bogdan


Gabriel Bermudez wrote:
> Seems that a weighted load balancing is not directly posible with
> drouting 
> (http://lists.opensips.org/pipermail/users/2009-September/008106.html),
> but you can trick the system to behave like this. It would be great if
> the module could also support this feature natively, maybe by handling
> a special format on the gwlist colum (GW1=0.4,GW2=0.2,GW3=0.4)
>
> I was interested on use drouting, because it can be managed with
> opensips control panel.  Is the carrierroute module on plans?
>
> 2010/2/1 Gabriel Bermudez 
>   
>> Hi everybody,
>>
>> I've read the documentation on carrierroute and drouting, about the 
>> algorithm used to select a gateway.  I understand that on carrierroute the 
>> gateway selected depends on the prefix dialed and the value of the prob 
>> field.  For example for prefix 49, gateway x.x.x.x with prob=0.2 and gateway 
>> y.y.y.y with prob=0.8 can exists in the carrierroute table.
>>
>> ++-+---+-+---++---+
>> | id | carrier | domain | scan_prefix | flags | prob | rewrite_host  |
>> ++-+---+-+---++---+
>> | 1  |   1 |  0  | 49  | 0 |  0.2   | x.x.x.x
>>  |
>> | 2  |   1 |  0  | 49  | 0 |  0.8   | y.y.y.y
>>  |
>> ++-+---+-+---++---+
>>
>> I understand that this means 20% of the calls will be sent to x.x.x.x and 
>> 80% to y.y.y.y
>> Is this the same for drouting, or only the highest priority rule is selected?
>>
>> Thanks for your answers
>>
>> Regards,
>> 
>
> ___
> 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

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Bogdan-Andrei Iancu]

Hi Thamer,

actually I see a 408 TIMEOUT for the second re-INVITE - but I see not 
outgoing re-INVITE in the second step (only the inbound message)

Looking at the 2 re-INVITEs, I would say you have a routing issue as the 
first re-INVITE has as RURI a public IP 
(sip:1...@uac.ip.address.here:5060), while the second re-INVITE has a 
private IP (sip:1...@192.168.2.12:5060)
So, maybe the NAT traversal logic for the sequential requests is not 
correct.

Regards,
Bogdan

Thamer Alharbash wrote:
> Hi Bogdan,
>
> Sorry for not getting back sooner. I've updated my config a bit. I'm  
> including what our reinvite handling looks like and the two reinvites  
> that pass through opensips. The second one as you can see has no  
> payload (ngrep shows ...) I have verified this as well under wireshark.
>
> if (has_totag()) {
>
>  # sequential request within a dialog should
>  # take the path determined by record-routing
>
>  if (loose_route()) {
>
>  if (is_method("BYE")) {
>  setflag(1); # do accounting ...
>  setflag(3); # ... even if the  
> transaction fails
>
>  } else if (is_method("INVITE")) {
>  # even if in most of the cases is  
> useless, do RR for
>  # re-INVITEs also, as some buggy  
> clients do change route set
>  # during the dialog.
>  record_route_preset 
> ("proxy.ip.address.here");
>  }
>  # route it out to whatever destination was  
> set by loose_route()
>  # in $du (destination URI).
>  route(1);
> ...
> route[1] {
>  # for INVITEs enable some additional helper routes
>  if (is_method("INVITE")) {
>  t_on_branch("1");
>  t_on_reply("1");
>  t_on_failure("1");
>  if(has_body("application/sdp")) {
>  rtpproxy_offer("frc","proxy.ip.address.here");
>  xlog ("Setting rtpproxy_offer");
>  }
>  if (isbflagset(6)) {
>  fix_nated_contact();
>  }
>
>  }
>
>
>
>
> -- FIRST REINVITE
>
> U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
> INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
> 2.0.
> Via: SIP/2.0/UDP carrier.ip.address.here: 
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
> From:  2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7 
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash"  1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Expires: 180.
> Min-SE: 1800.
> Session-Expires: 1800;refresher=uac.
> Supported: 100rel,timer.
> Max-Forwards: 69.
> Contact: .
> Content-Type: application/sdp.
> Content-Length: 216.
> Route: .
> .
> v=0.
> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
> s=-.
> c=IN IP4 carrier.ip.address.here.
> t=0 0.
> m=audio 10044 RTP/AVP 0 101.
> a=sendrecv.
> a=ptime:20.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
>
> U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP carrier.ip.address.here: 
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
> From:  2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7 
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash"  1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Server: OpenSIPS (1.6.0-notls (i386/linux)).
> Content-Length: 0.
> .
>
> U our.proxy.ip.address:5060 -> uac.ip.address.here:5060
> INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
> 2.0.
> Record-Route: .
> Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
> Via: SIP/2.0/UDP carrier.ip.address.here: 
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
> From:  2165928...@our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7 
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash"  1...@our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Expires: 180.
> Min-SE: 1800.
> Session-Expires: 1800;refresher=uac.
> Supported: 100rel,timer.
> Max-Forwards: 68.
> Contact: .
> Content-Type: application/sdp.
> Content-Length: 217.
> .
> v=0.
> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
> s=-.
> c=IN IP4 our.proxy.ip.address.
> t=0 0.
> m=audio 32104 RTP/AVP 0 101.
> a=sendrecv.
> a=ptime:20.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
> -- SE

Re: [OpenSIPS-Users] What is protocol/port mismatch?

[Bogdan-Andrei Iancu]

Hi Brian,

The backtrace from gdb seams really corrupted, but the pstack output is 
a bit consistent.
What is strange is that dlg_validate_dialog () seams to call 
fm_realloc() which is not in the script.

So, to eliminate any possibility of a mem corruption (the crash was in 
the mem manager), I suggest to compile the mem debugger to see if there 
are no mem issues (mem overwritten, double free, etc).

Regards,
Bogdan


opensipsl...@encambio.com wrote:
> Hello Bogdan,
>
> An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>   
>> Regarding the crash you mentioned - do you have any backtraces ?
>>
>> 
> There's quite a lot of situations in which OpenSIPS crashes, so
> I'm not sure this one is related to TLS traffic arriving on a non
> TLS port. In any case, here's the last backtrace:
>
> $ gdb /pfx/sbin/opensips opensips.17272.name.host.tld.core 
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.11"...
> (no debugging symbols found)
> Cannot access memory at address 0x70795464
> (gdb) bt
> #0  0x0810eefc in fm_realloc ()
> #1  0xd0d8cc8c in ?? ()
> #2  0x080465a8 in ?? ()
> #3  0xd0d859d4 in ?? ()
> #4  0x08353c2c in mem_pool ()
> #5  0x0191 in ?? ()
> #6  0x08046640 in ?? ()
> #7  0x in ?? ()
> #8  0x in ?? ()
> #9  0x080467d8 in ?? ()
> #10 0x08046638 in ?? ()
> #11 0x0812437e in parse_min_se ()
> #12 0x083132e0 in mem_pool ()
> #13 0x in ?? ()
> #14 0x81af694b in ?? ()
> #15 0xd0d8c6fc in ?? ()
> #16 0x0001 in ?? ()
> #17 0x08353c2c in mem_pool ()
> #18 0xce43365d in ?? ()
> #19 0x080467c4 in ?? ()
> #20 0x0804678c in ?? ()
> #21 0x08353f9c in mem_pool ()
> #22 0x08046640 in ?? ()
> #23 0x08353f9c in mem_pool ()
> #24 0x0073 in ?? ()
> #25 0x082ff8e8 in ?? ()
> #26 0xd13dbbe9 in ?? ()
> #27 0x0002 in ?? ()
> #28 0x082ff8f0 in ?? ()
> #29 0x3332 in ?? ()
> #30 0x in ?? ()
> (gdb)
>
> $ pstack opensips.17272.name.host.tld.core core 
> 'opensips.17272.name.host.tld.core' of 17272:/pfx/sbin/opensips -P 
> /pfx/var/opensips/opensips.pid
>  0810eefc fm_realloc (0, 80467cc, 0, 80467d8, d10f, 8354104) + 4bc
>  d1011537 dlg_validate_dialog (8353c2c, ce4334b0, 8046a38, d101459b, 
> ce4334b0, 8323390) + 290
>  d10035ba w_validate_dialog (8353c2c, 0, 0, 0, 0, 0) + 2a
>  08076240 do_action (8323390, 8353c2c, 7275652e, 8046c00, 8046bf0, 0) + 15a5
>  08079877 run_action_list (8323390, 8353c2c, 844f7c8, 844f735, 83132ba, 13) + 
> 281
>  080d03a7 eval_expr (83233fc, 8353c2c, 0, 0, 313c5, 1) + 46a
>  080d014a eval_expr (8323428, 8353c2c, 0, 0, 0, 0) + 20d
>  080d0019 eval_expr (8323454, 8353c2c, 0, d0ff18b3, 0, 8354890) + dc
>  080d0172 eval_expr (8323480, 8353c2c, 0, 8354700, 8354a2c, 27) + 235
>  0807643d do_action (83238cc, 8353c2c, 40, 82b1c50, 80472d4, 80472d4) + 17a2
>  08079877 run_action_list (83238cc, 8353c2c, 0, 81aaf92, 82b1c50, ce4350a8) + 
> 281
>  08078381 do_action (832536c, 8353c2c, ce415b0d, d0dadd84, ce433690, 
> ce415b08) + 36e6
>  08079877 run_action_list (832536c, 8353c2c, 0, 0, 0, 0) + 281
>  08078381 do_action (8325654, 8353c2c, ce415790, 0, 8353c30, 1) + 36e6
>  08079877 run_action_list (832108c, 8353c2c, d106ea15, 8344074, 8353c2c, 0) + 
> 281
>  08079c50 get_bl_head_by_name (832108c, 8353c2c, 8353c2c, 80478f0, 308, 
> 8353c2c) + f3
>  080be5aa receive_msg (ce415808, 308, ce4157a0, 80478d4, ce375d9c, 2) + 5ac
>  080f4cf4 tcp_read_req (ce415790, 8047978, d11d10c5, d11bfa64, 17, ce375d4c) 
> + 18c
>  080f687d  (b, d001, 8047ac4, d06e7e60, d06e9ae0, 831a84c)
>  080f77a4 tcp_receive_loop (c, 2, 0, 8047b10, 9, 0) + 94b
>  080ed6f8 tcp_send (82cb1f4, 138a, 83178e8, 805f130, d1169cc8, 8047c5c) + 4b
>  08091d47 main (80749c0, 3, 8047bdc) + 3bab
>  080749c0 do_assign (3, 8047cc4, 8047cd8, 8047cdb, 0, 8047cfb) + d0
>
> $ pflags opensips.17272.name.host.tld.core
> core 'opensips.17272.name.host.tld.core' of 17272:/pfx/sbin/opensips 
> -P /pfx/var/opensips/opensips.pid
> data model = _ILP32  flags = ORPHAN|MSACCT|MSFORK
>  /1:flags = 0
> sigmask = 0xbefc,0x  cursig = SIGSEGV
>
>   
>> 1) t_relay() is not forcing any proto by itself: it preserves the 
>> inbound proto if the RURI (or socket) is not saying otherwise.
>>
>> 
> Okay, then I assume the t_relay() tried sending TLS traffic to
> the voicemail server, could not negotiate a TLS connection, and
> so resent the message over UDP instead. Is that right? Does
> t_relay() choose UDP instead of TCP when its first choice (the
> preserved inbound proto) cannot be used?
>
>   
>> 2) turning off the double RR may brake some things as opensips will
>> not be able to properly route between the original inbound and
>> outbo

Re: [OpenSIPS-Users] number of opensips children

[Bogdan-Andrei Iancu]

Hi Brian,

the average load (which is very small in your case) is not really 
relevant. Maybe you have a spike in traffic - like more than 8 requests 
received in the same time.

So, my advice is :
1) check on the network level if you receive bulk messages at a moment
2) maybe the processing you do for request is very slow - we could make 
an extension to the benchmark module to report the time required to run 
the script.

Regards,
Bogdan

opensipsl...@encambio.com wrote:
> Hello Bogdan,
>
> An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>   
>> opensipsl...@encambio.com wrote:
>> 
>>> I have eight TCP listeners configured and about sixteen UACs are
>>> connected. I get a ton of these warnings whenever REGISTER or INVITE
>>> messages come in:
>>>
>>>   Feb 02 18:17:22 name.host.tld  opensips[02126]: 
>>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>>> leastbusy one (1)
>>>   Feb 02 18:17:25 name.host.tld  opensips[02126]: 
>>> WARNING:core:send2child: no free tcp receiver, connection passed to the 
>>> leastbusy one (1)
>>>
>>>   
>> Also, to be sure you got it right, there is no relation between the
>> TCP WORKER and a connection. A TCP WORKER process is just reading
>> and processing a SIP message at a certain time. Next SIP message
>> 
> >from the same connection may end up in a different TCP WORKER proc.
>   
>> and this has nothing to do with the tcp_persistent_flag.
>>
>> 
> But what can be the reason that 8 TCP worker processes are unable to
> be idle enough to serve 16 UACs? The UACs are sending REGISTER and
> SUBSCRIBE messages every 5 minutes only, and hardly any INVITES are
> being made. It would seem that even a single TCP worker process
> should be able to serve the 16 UACs exchanging little traffic no?
>   


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