[OpenSIPS-Users] Problem with sip_trace storage, maybe a bug?

[opensipslist]

Hello list,

I'm using:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.4 with TLS

...and am logging dialogs with the siptrace module.

The problem is that every time I want to look at the traced messages
in the sip_trace table, I do:

  $ psql opensips opensips
  opensips=> select * from sip_trace where fromip = 'tcp:1.2.3.4:5678';
  id | time_stamp | callid | traced_user | msg | method | ...
  1234 | 2011-02-03 | ... | | \x494e56495445207369703a...

As you can see, the 'msg' column ASCII text is stored as hex values.
The next thing I do is use my mouse to cut and paste the message
(extremely long and tedious) to the window in:

  http://www.dolcevie.com/js/converter.html

...which translates '\x494e56495445207369703a' to 'INVITE sip:'.

This way of debugging is not acceptable at all, and I want to
see the ASCII text of the SIP message directly (without converting.)

How can I read the siptrace logs in this way?

Is it a bug that OpenSIPS stores the ASCII message text in hex?

Regards,
Brian

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

[OpenSIPS-Users] How to avoid rewriting NAT RURI

[opensipslist]

Hello list,

I'm using:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.4 with TLS

In order to allow two UAs behind the same NAT router to communicated
with each other directly, I'm trying to do something like this in the
main request route block:

  if (ruri.received_addr == registered(To-URI).received_hdr)
  noop;  # Do nothing
  else {  # UAs are behind different routers
  rewrite-request-URI-contact-with-ruri.recieved_addr;
  lookup(To-URI);  # Lookup will rewrite ruri with recv header
  }

Similar logic probably must go in the onreply_route block as well.

I don't need any help with the 'else' block, because that's the normal
case which is working very well for us now.

The problem with the example configurations distributed with the source
code is that they assume that any UA which is behind a NAT router will
always call other UAs behind another (different) router. That's not
always the case, though.

Does anybody have an example of how to do this? How have others solved
this problem?

Regards,
Brian

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

Re: [OpenSIPS-Users] Core Dump

[opensipslist]

Hello Bogdan,

An sam., févr 27, 2010, opensipsl...@encambio.com schrieb:
>An lun., févr 22, 2010, Bogdan-Andrei Iancu schrieb:
>>Maybe you should consider reporting the crashing you are mentioning
>>(if they are so many as you say), so somebody could fix them - in
>>this case everybody will be happier , I guess.
>>
>Here's a backtrace of the OpenSIPS 1.6.0 sometime after INVITE
>request comes in:
>
# gdb /pfx/sbin/opensips opensips.1234.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)
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1

Core was generated by `/pfx/sbin/opensips -P
/pfx/var/opensips/opensips.pid -m 64'.
Program terminated with signal 6, Aborted.
[New process 67527]
#0  0xd11d1d75 in _lwp_kill () from /lib/libc.so.1
(gdb) bt
#0  0xd11d1d75 in _lwp_kill () from /lib/libc.so.1
#1  0xd11cb73d in thr_kill () from /lib/libc.so.1
#2  0xd1185722 in raise () from /lib/libc.so.1
#3  0xd1162c7d in abort () from /lib/libc.so.1
#4  0x0808c900 in ?? ()
#5  0x001a in ?? ()
#6  0x0826115c in ?? ()
#7  0x082629ac in ?? ()
#8  0xd1268ac0 in _uberdata () from /lib/libc.so.1
#9  0x in ?? ()
(gdb)

>If it crashes or not it depends a lot of what functionalities
>(modules) you are using (nobody can claim he tested all the modules
>in all possible combinations).
>
This time I don't see where the crash could have happened, maybe
the in the OpenSIPS 1.6.0 core? Here's the last message in the
sip trace before the crash (not sure if it's representative.)

INVITE:477:tls:1.2.3.4:5061:tls:4.3.2.1:1234:ck1b40kwzn:out
7070:1267304859:3c2e8013a0e7-x8fz99gffcy0::SIP/2.0 477 Send failed (477/TM)
Via: SIP/2.0/TLS 
192.168.130.130:1234;branch=z9hG4bK-cuia8rmsu1z3;rport=1234;received=4.3.2.1
From: "User-Me" ;tag=ck1b40kwzn
To: 
;tag=c3f9bc8b6c0d893b80d355b0f89fbe37-0bbd
Call-ID: 3c2e8013a0e7-x8fz99gffcy0
CSeq: 1 INVITE
Server: OpenSIPS (1.6.0-tls (i386/solaris))
Content-Length: 0
Warning: 392 name.host.tld:5061 "Noisy feedback tells:  pid=2000 
req_src_ip=4.3.2.1 req_src_port=1234 
in_uri=sip:+123454...@name.host.tld;user=phone 
out_uri=sips:nik...@name.host.tld via_cnt==1"

Here are the last few lines from the log before hundreds of memory
debug lines appear (because I have memory debugging on.)

Feb 27 21:44:25 name.host.tld  opensips[3996]: INVITE: Noncancelled 
fail route [408]
Feb 27 21:44:25 name.host.tld  opensips[3996]: 
ERROR:core:warning_builder: buffer size exceeded
Feb 27 21:44:25 name.host.tld  opensips[3996]: 
WARNING:core:build_res_buf_from_sip_req: warning skipped -- too big
Feb 27 22:07:39 name.host.tld  opensips[4001]: 
CRITICAL:core:receive_fd: EOF on 20
Feb 27 22:07:39 name.host.tld  opensips[3994]: Memory status (pkg):
Feb 27 22:07:39 name.host.tld  opensips[3994]: qm_status (8311c20):

If you like I can send more of the memory debug log lines, but
please tell me just what to send (so I can avoid sending hundreds
of lines of log text.)

>For example I'm running opensips.org SIP service with SVN trunk
>and I do not get any core dumps... and it is an almost 3K lines
>config...
>
This time OpenSIPS crashed after only one day, which is unusual for
the 1.6.0 release which usually lasts longer.

>So, again, if you get crashes, please report them.
>
Okay, I'll keep doing that.

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 lun., févr 22, 2010, Anca Vamanu schrieb:
>You are right, the if RURI is changed the auth response calculation
>will get a different result at the media server.  As a solution, I
>will add a scenario parameter that tells B2B logic not to change
>the RURI, but keep the original one.
>
Thanks, that will help a lot. Let us know how this addition goes.

>However, I must warn you again that if you use the complete prepaid 
>scenario and the media server will request authorization when the caller 
>is connected the second time to it, then it will not work. Because to 
>connect the caller to the media server the second time, a reinvite is 
>sent to the caller and am initial Invite to the media server after the 
>caller's phone replies with 200 OK. There is no way to do authorization 
>here.
>
I do vaguely understand what you are saying here. My goal doesn't
require the last INVITE to the media server, only the first one
is needed. It's still possible that a re-INVITE is sent by B2B
which causes authorization problems for my client, but I'm not
certain about that yet.

Even in the worst case there is good value in being able to connect
even a single dialog to a media server while using authorization,
so your plan to add the scenario parameter is justified.

>But you can use only the first part, connecting the user to the media 
>server only once at the beginning.
>
Hopefully that will work out. I'll test it once you're finished.

Regards,
Brian

___
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 lun., févr 22, 2010, Bogdan-Andrei Iancu schrieb:
>Asking as the trace you previously sent me was showing a crash in the 
>uac_replace_xxx() function, because of a bogus "display" pointer. I 
>wanted to see how you call the functions to see if they try to change 
>the display part or not. And it looks it doesn't, so the "display" param 
>should be NULL.
>
>Is the crash reproducible ?
>
I'll see if I can reproduce it, but it will take some time. Thanks
for the interest.

Regards,
Brian

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

Re: [OpenSIPS-Users] Core Dump

[opensipslist]

Hello Bogdan,

An lun., févr 22, 2010, Bogdan-Andrei Iancu schrieb:
>Maybe you should consider reporting the crashing you are mentioning
>(if they are so many as you say), so somebody could fix them - in
>this case everybody will be happier , I guess.
>
Here's a backtrace of the OpenSIPS 1.6.1 sometime after REGISTER
request comes in:

# gdb /pfx/sbin/opensips opensips.16452.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)
...
Loaded symbols for /lib/ld.so.1

Core was generated by `/pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid -m 
64'.
Program terminated with signal 11, Segmentation fault.
[New process 83290]
#0  0x0810d931 in qm_malloc ()
(gdb) bt
#0  0x0810d931 in qm_malloc ()
#1  0x0835b5a8 in mem_pool ()
#2  0x0835bf9c in mem_pool ()
#3  0x08046670 in ?? ()
#4  0xd0d55fd0 in ?? () from /pfx/lib/opensips/modules/auth_aaa.so
#5  0x0835d9b8 in mem_pool ()
#6  0x08313240 in ?? ()
#7  0x08046658 in ?? ()
#8  0xd0d51bb9 in authorize (_msg=0x20, _realm=,
_uri_user=, _hftype=0) at authorize.c:126
#9  0x in ?? ()
(gdb)

>If it crashes or not it depends a lot of what functionalities
>(modules) you are using (nobody can claim he tested all the modules
>in all possible combinations).
>
Seems to me that the crash from the core dump above relates to flaws
in the AAA authorization logic. Here's the last message in the sip
trace before the crash (not sure if it's representative.)

125:1267207762:3c2d04c4da9c-95w1oc5r17eu::SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 
192.168.130.35:2291;branch=z9hG4bK-kv7jq7chf8p1;rport=2291;received=1.2.3.4
From: "My Name" ;tag=xlrkkswd5y
To: "My Name" 
;tag=d170206e0ec14c1ccd1967a0f5e85cb9.9210
Call-ID: 3c2d04c4da9c-95w1oc5r17eu
CSeq: 515 REGISTER
WWW-Authenticate: Digest realm="name.host.tld", 
nonce="4b880e705d5b5fafcb33b4df08f7689d6850ac25", qop="auth"
Server: OpenSIPS (1.6.1-tls (i386/solaris))
Content-Length: 0
Warning: 392 name.host.tld:5061 "Noisy feedback tells:  pid=17754 
req_src_ip=1.2.3.4 req_src_port=2291 in_uri=sip:name.host.tld 
out_uri=sip:name.host.tld via_cnt==1"

Here are the last few lines from the log before hundreds of memory
debug lines appear (because I have memory debugging on.)

 opensips[12744]: WARNING:core:init_tls: disabling compression due 
ZLIB problems
 opensips[12744]: WARNING:core:init_ssl_ctx_behavior: client 
verification activated. Client certificates are mandatory.
 opensips[12744]: WARNING:core:init_ssl_ctx_behavior: server 
verification activated.
 opensips[12756]: CRITICAL:core:receive_fd: EOF on 20
 opensips[12748]: Memory status (pkg):
 opensips[12748]: qm_status (8313260):

If you like I can send more of the memory debug log lines, but
please tell me just what to send (so I can avoid sending hundreds
of lines of log text.)

>For example I'm running opensips.org SIP service with SVN trunk
>and I do not get any core dumps... and it is an almost 3K lines
>config...
>
Building OpenSIPS 1.6.0 with the same radiusclient-ng installation
(which is up to date) results in a more stable runtime. It's usually
good for several days before crashing.

>So, again, if you get crashes, please report them.
>
Okay, but I've noticed that some crashes do not produce core dumps.

>PS: if the build is bogus (like in Nathaniel), the runtime will be 
>unstable also - OpenSIPS has a lot of asm code that really depends on 
>arch, so messing the build params may lead to bogus code.
>
My build is correct.

Regards,
Brian

___
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 11, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> I should tell you that I've recompiled OpenSIPS since the crash.
>> The changes are unrelated to the core or uac module so there's no
>> problem, however it might be that the core you've asked to study
>> reports memory locations that don't match the new running OpenSIPS.
>>
>> Also, I've changed the route script to use subst() from textops
>> instead of uac_replace_(from|to) to avoid getting this crash. I'm
>> still not convinced 100% that it's in replace.c, because it seemed
>> to me that uac_replace_(from|to) sometimes worked fine.
>>
>How do you invoke the uac_replace_xxx() which crashes?
>
I had:

  uac_replace_to("sip:$...@$avp(s:realm)");
  uac_replace_from("sip:$avp(s:user)@$fd");

Now I'm using:

  subst('/^(To:[^:]+:)[...@]+@[^>;]+/\1...@$avp(s:realm)/');
  subst('/^(From:[^:]+):[...@]+@[^>;]+/\1:$avp(s:user)@$avp(s:realm)/');

...but I can't remember anymore the reason that made me think the
uac_replace_*** functions were at fault for crashes. If you're
interested then I can diagnose this further. In that case please
suggest a course of testing, how you recommend I figure this out.

Regards,
Brian

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

Re: [OpenSIPS-Users] Core Dump

[opensipslist]

Hello Bogdan,

An ven., févr 19, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An jeu., févr 18, 2010, Nathaniel L Keeling schrieb:
>>> I have compiled opensips 1.6.1 on Solaris Sparc 10. I was able to
>>> compile successfully by adding the parameter "-mcpu=ultrasparc" to
>>> the "DEFS" compile time options in Makefile.defs, but when I
>>> execute opensips, it will die with a core dump. It does thru the
>>> loading of the modules ok but dies later.
>>>
>> Both Solaris 10 Sparc or Solaris 11 x86 do core dump when trying
>> to use OpenSIPS 1.6.1. Nobody has seem to be able to diagnose this
>> correctly much less repair the problem.
>>
>How comes ? I know people using 1.6 on sparc + Solaris  :P
>
I don't know either, but I'm sure that some builds work better
than others. This would particularly be the case if the problem
code was in a certain module or component which some builds are
missing. My build contains almost everything.

>> If you try the same build parameters to compile 1.6.0 you will
>> probably find that it not only compiles correctly but runs without
>> core dumping as well. So much for the
>>
>> 'it is recommended to upgrade, as it provides important
>>  stability improvements'
>>
>> that they write about the 1.6.1 release on the website.
>>
>hmmm... if you see the compiling as stability, maybe you are right
>
The buildtime is not as problematic as the runtime, which only
rarely coredumps on 1.6.0 but quite often on 1.6.1. I can get
1.6.0 to coredump as well by forcing OpenSIPS to try writing
to TCP connections which don't exist. Being careful with 1.6.0
then it is possible to get a few weeks worth of usage with no
core dump, maybe more.

>Now, getting serious... the problem is that since SF trashed the 
>compiled farm, we (or at least I) do not have any sparc / solaris 
>platform were to test the makefile options or the code...
>
You can do a lot with a single good machine and Xen, but that
is maybe food for another thread. It's sad indeed that no Solaris
platforms are available for testing.

Regards,
Brian

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

Re: [OpenSIPS-Users] Core Dump

[opensipslist]

Hello Nathaniel,

An jeu., févr 18, 2010, Nathaniel L Keeling schrieb:
>I have compiled opensips 1.6.1 on Solaris Sparc 10. I was able to
>compile successfully by adding the parameter "-mcpu=ultrasparc" to
>the "DEFS" compile time options in Makefile.defs, but when I
>execute opensips, it will die with a core dump. It does thru the
>loading of the modules ok but dies later.
>
Both Solaris 10 Sparc or Solaris 11 x86 do core dump when trying
to use OpenSIPS 1.6.1. Nobody has seem to be able to diagnose this
correctly much less repair the problem.

If you try the same build parameters to compile 1.6.0 you will
probably find that it not only compiles correctly but runs without
core dumping as well. So much for the

'it is recommended to upgrade, as it provides important
 stability improvements'

that they write about the 1.6.1 release on the website.

Regards,
Brian

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

Re: [OpenSIPS-Users] Quick Regex Question.

[opensipslist]

Hello Alan,

An ven., févr 19, 2010, Alan Frisch schrieb:
>What I am trying to do is prefix a value if the inbound number
>comes in with an E164 format. I tried the following, but it seems
>to throw OpenSIPS.
>
>if(uri =~ "^sip:[2-9][0-9]+@") {
>whatever
>}
>
There's no problem with that. It is a correct regex, and should
work fine. Why are you starting [2-9] with 2 instead of 1?

>Can a kind soul suggest the proper regex to match first number
>as [2-9] and then any (unlimited number of) second numbers.
>
Since you've gotten the regex right, it might be that you are
expeciting logic from the RURI to affect your routing when it
is another header (maybe To?) that you need to focus on. Some
commercial gateways take their forwarding values from the To
header as far as I know.

By the way it would surely be interesting for you to research
the 'is_uri_user_e164' function of OpenSIPS if you are indeed
trying to match E.164 numbers in the RURI.

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., févr 12, 2010, opensipsl...@encambio.com schrieb:
>An ven., févr 12, 2010, Anca Vamanu schrieb:
>>It is ok to have cseq 2 on the other side if the received Invite
>>has cseq 1. The implementation uses cseq +1 on the other side :).
>>It should not be an issue.
>>
>You're right.
>
>>Only if for the authorized Invite the cseq is not 3... You
>>observed this?
>>
>[...]
>
>But it's still not working...
>
>Problem
>
>The UAC receives the 401 response from the B2B logic and produces
>the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
>the original (not B2B rewritten) RURI to calculate the MD5 string.
>
>The B2B logic then takes the new INVITE with the 'Authorization'
>header and rewrites the RURI before forwarding it to the media
>server. This rewriting procedure is the same for both the RURI
>and 'To' URI. Both are set to the  parameter of the
>B2B XML file.
>
>When the client entity (media server) gets the new INVITE message
>it rejects it because the RURI has changed thus invalidating the
>'Authorization' string. Do you understand?
>
>Solution
>
>My idea to solve this problem is when specifying a client
>destination in the B2B XML file, a client entity will be created.
>As before, the 'To' tag will be rewritten to match the 
>but the RURI should not be changed. When B2B forwards the INVITE
>message to the media server it will be accepted because the
>'Authorization' header will be correct.
>
>Do you agree, and if so what is the best way to achieve this?
>Maybe it's best to add this new logic as an option to the
> tag? That way the default behaviour would be
>to still rewrite the RURI as B2B was doing before.
>
I've looked at the code and searched for the place where the 'To'
header and RURI are independently set. It seems that some dialog
creation function of the TM module is being used, but I don't see
how to set the 'To' and RURI independently.

Have you thought about the problem I mentioned and the possible
solutions to it? I'm still stuck without a functioning B2BUA,
because the B2B logic is changing the RURI from the original
message.

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., févr 12, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> An jeu., févr 11, 2010, Anca Vamanu schrieb:
>>> I have just committed the fix for this. Please update and test.
>>>
>> At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. [...]
>> Unfortunately, the INVITE arriving at the media server has a
>> CSEQ of 2 so I assume that there is some defect with your
>> changes in SVN 6596.
>>
>It is ok to have cseq 2 on the other side if the received Invite
>has cseq 1. The implementation uses cseq +1 on the other side :).
>It should not be an issue.
>
You're right.

>Only if for the authorized Invite the cseq is not 3... You
>observed this?
>
My observation was wrong, and now it is clear that the B2B logic
is reading INVITE CSEQ 1 and rewriting to INVITE CSEQ 2. When it
retransmits the INVITE a second time with the 'Authorization'
header it does indeed increment the new INVITE CSEQ to 3 which
is correct. Thanks.

But it's still not working...

Problem

The UAC receives the 401 response from the B2B logic and produces
the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
the original (not B2B rewritten) RURI to calculate the MD5 string.

The B2B logic then takes the new INVITE with the 'Authorization'
header and rewrites the RURI before forwarding it to the media
server. This rewriting procedure is the same for both the RURI
and 'To' URI. Both are set to the  parameter of the
B2B XML file.

When the client entity (media server) gets the new INVITE message
it rejects it because the RURI has changed thus invalidating the
'Authorization' string. Do you understand?

Solution

My idea to solve this problem is when specifying a client
destination in the B2B XML file, a client entity will be created.
As before, the 'To' tag will be rewritten to match the 
but the RURI should not be changed. When B2B forwards the INVITE
message to the media server it will be accepted because the
'Authorization' header will be correct.

Do you agree, and if so what is the best way to achieve this?
Maybe it's best to add this new logic as an option to the
 tag? That way the default behaviour would be
to still rewrite the RURI as B2B was doing before.

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 jeu., févr 11, 2010, Anca Vamanu schrieb:
>I have just committed the fix for this. Please update and test.
>
I see that you made the changes in SVN revision 6596, however
when I build OpenSIPS 1.6.0 (after copying the entire b2b_entity
and b2b_logic modules from SVN 6596) the same problem is there.

At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. The b2b_init
prepaid scenario then reads the message and makes a new one that
it forwards to parameter 1 of the XML script. Unfortunately, the
INVITE arriving at the media server has a CSEQ of 2 so I assume
that there is some defect with your changes in SVN 6596.

By the way, I'm not processing the INVITE in the route script
before b2b_init() begins. What do you think could be the problem?

Regards,
Brian

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

Re: [OpenSIPS-Users] issue with my XML script, b2bua

[opensipslist]

Hello Anca,

An jeu., févr 11, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> An ven., févr 05, 2010, Anca Vamanu schrieb:
>>> On the other hand, I suggest for you to start playing with the
>>> simple topology hiding scenario and the go to more complicated
>>> scripts.
>>> 
>> ...but the topology hiding scenario has no associated XML file
>> which makes learning more difficult.
>>
>> What I mean is, could you please post an example XML scenario
>> file topohide.xml:
>>
>> [...]
>>
>Ok, I can write a sample scenario for the topology hiding case.
>It will have no rules, because only the default pass through rule
>is applied. It will only have an init section:
>
>
>
> 
> 
>
>server1
>
>
>client1
>message
>
>server1
>
>
> 
> 
>
>
>This scenario specifies that two entities must be created, a server
>on to deal with the received INVITE and a client one to start the
>dialog on the other side. The destination for this client entity
>is exactly the one from the received INVITE, so we have - value
>type="initial" and to be taken from entity server1.
>
>Hope this helps.
>
Yes it does. Thanks alot. I noticed that there is a wiki-like 'Edit'
button on the B2BUA tutorial. Should we consider building a cookbook
of scenarios with their associated XML files there? Can anyone edit
the B2BUA totorial?

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 jeu., févr 11, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> I'm approaching the problem from a different perspective now,
>> and making progress with your help. Please note the 'CSEQ'...
>>
>>   Caller OpenSIPS B2B  Mediaserver
>> | | |
>>   INVITE CSEQ 1 ->| INVITE CSEQ 2 ->|
>> | | |
>> |<-- 401 WWW-Authenticate |< 401 WWW-Authenticate
>> | | |
>>   INVITE CSEQ 2 ->| INVITE CSEQ 2 ->|
>> | |!!   |
>> | | |
>> |<-- 401 WWW-Authenticate |< 401 WWW-Authenticate
>> | | |
>>
>> As you can see, the above scenario will not work. The B2B logic
>> is not increasing the CSEQ of the second incoming INVITE. This
>> is the real one that should actually start the dialog.
>>
>I have thought about this problem and discussed with Bogdan and
>he come up with the simplest solution - take the Cseq from the
>received Invite. And your scenario should be solved. I will
>make this change and let you know when to update from svn.
>
That's good news. After trying a lot of things nothing worked.
I'll be patient for your updtate to come in and then integrate
the new code from SVN and test it. Thanks.

Regards,
Brian

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

Re: [OpenSIPS-Users] issue with my XML script, b2bua

[opensipslist]

Hello Anca,

An ven., févr 05, 2010, Anca Vamanu schrieb:
>On the other hand, I suggest for you to start playing with the
>simple topology hiding scenario and the go to more complicated
>scripts.
>
...but the topology hiding scenario has no associated XML file
which makes learning more difficult.

What I mean is, could you please post an example XML scenario
file topohide.xml:




<...>

...which if called with:

  modparam("b2b_logic", "script_scenario", "/pfx/topohide.xml")
  b2b_init_request("topohide");

...would have the same effect as b2b_init_request("top hiding")

That would greatly help us learn to write new scenarios.

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,

I'm approaching the problem from a different perspective now,
and making progress with your help. Please note the 'CSEQ'...

  Caller OpenSIPS B2B  Mediaserver
| | |
  INVITE CSEQ 1 ->| INVITE CSEQ 2 ->|
| | |
|<-- 401 WWW-Authenticate |< 401 WWW-Authenticate
| | |
  INVITE CSEQ 2 ->| INVITE CSEQ 2 ->|
| |!!   |
| | |
|<-- 401 WWW-Authenticate |< 401 WWW-Authenticate
| | |

As you can see, the above scenario will not work. The B2B logic is
not increasing the CSEQ of the second incoming INVITE. This is the
real one that should actually start the dialog.

How do you recommend to correct this. Can I simply adjust your
prepaid.xml file?

My best guess is that I can insert a 'delete_entity' to try to
indicate to the B2b logic that a new dialog begins at the second
INVITE, but I don't know how to do that. Is this right?

  
  
  
  
  
  
  1
  
  server
  server1
  
  

  
  
  
  
  server1
  
  
  client1
  
  server1
  
  
  
  2
  
  

Alternatively I could try changing the routing script to only call
the B2B logic at the second INVITE, but that would be very hacky.

# initial requests
if (is_method("INVITE") && src_ip != myself) {  # rewrite block
if (!t_newtran()) { # to ignore any
sl_reply_error();   # INVITE request
exit;   # without a Auth
}   # header
b2b_init_request("prepaid", 
"sip:t...@medsrv.host.tld:5080;transport=tcp", 
"sip:t...@medsrv.host.tld:5080;transport=tcp");
exit;
}

I prefer doing it correctly, by adjusting your prepaid.xml scenario.

Regards,
Brian

___
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,

I should tell you that I've recompiled OpenSIPS since the crash.
The changes are unrelated to the core or uac module so there's no
problem, however it might be that the core you've asked to study
reports memory locations that don't match the new running OpenSIPS.

Also, I've changed the route script to use subst() from textops
instead of uac_replace_(from|to) to avoid getting this crash. I'm
still not convinced 100% that it's in replace.c, because it seemed
to me that uac_replace_(from|to) sometimes worked fine.

An lun., févr 08, 2010, Bogdan-Andrei Iancu schrieb:
>In frame 0, could you print "*display" and "buf.s" ?
>
Program terminated with signal 11, Segmentation fault.
[New process 95015]
#0  0xd0e19f23 in replace_uri (msg=0x8355f48, display=0x8046f48, uri=0x8046f50, 
hdr=0x8356658, rr_param=0xd0e1fa68) at replace.c:271
271  memcpy( buf.s, display->s, display->len);
(gdb) bt
#0  0xd0e19f23 in replace_uri (msg=0x8355f48, display=0x8046f48, uri=0x8046f50, 
hdr=0x8356658, rr_param=0xd0e1fa68) at replace.c:271
#1  0xd0e1c701 in w_replace_to (msg=0x8355f48, p1=0x8348a88
"\030?3\b\004", p2=0x0)
at uac.c:408
#2  0x08076000 in do_action ()
#3  0x0807961b in run_action_list ()
#4  0x08077574 in do_action ()
#5  0x0807961b in run_action_list ()
#6  0x08078177 in do_action ()
#7  0x0807961b in run_action_list ()
#8  0x080799f0 in run_top_route ()
#9  0x080be52a in receive_msg ()
#10 0x080f4c74 in tcp_read_req ()
(gdb) print *display
$1 = {s = 0x1 , len = 18}
(gdb) print buf.s
Attempt to extract a component of a value that is not a structure.
(gdb) print *buf.s
Attempt to extract a component of a value that is not a structure.
(gdb)

Regards,
Brian

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

Re: [OpenSIPS-Users] Bug in dialog db logic

[opensipslist]

Hello,

An lun., févr 08, 2010, opensipsl...@encambio.com schrieb:
>In the log:
>
>  Feb 07 16:25:32  opensips[14512]: ERROR:db_text:dbt_insert: cannot 
> insert the new row!!
>  Feb 07 16:25:32  opensips[14512]: ERROR:dialog:update_dialog_dbinfo: 
> could not add another dialog to db
>
> [...]
>
>  id(int,auto) hash_entry(int) hash_id(int) callid(string) from_uri(string) 
> from_tag(string) to_uri(string) to_tag(string) caller_cseq(string) 
> callee_cseq(string) caller_route_set(string,null) 
> callee_route_set(string,null) caller_contact(string) callee_contact(string) 
> caller_sock(string) callee_sock(string) state(int) start_time(int) 
> timeout(int)
>
>Any ideas why OpenSIPS can't write to the dialog table?
>
I figured it out. There's a bug in the dbtext scripts which
create the table 'dialog'. The column script_flags(int) should
be script_flags(int,null). Sadly there seem to be so many of
these kinds of bugs, that one can hardly be confident that the
dialog table is correct now. There just as well may be more
problems with it than only this one column.

Regards,
Brian

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

Re: [OpenSIPS-Users] BLA pickup issue

[opensipslist]

Hello Steven,

An lun., févr 08, 2010, Steven C. Blair schrieb:
>We have been experiencing a few problems with bridged line
>appearance (BLA) using Polycom phones and I wonder if anyone on
>this list can help?
>
You are not alone, I'm trying to get BLA to work as well although
on Snom phones.

>The first problem we have is with tracking the line status. If a
>subscribe message is sent from a phone in the BLA group while two
>incoming calls to the BLA group are answered on two different sets
>then all sets in the BLA group lose the status indicators for both
>calls.  The only sets which still communicate with the callers are
>the sets which originally answered the call.
>
>This behavior seems to be a well know issue with earlier versions
>of OpenSER. We built an OpenSIPS v1.6.1-notls server but still see
>the same behavior. Is anyone else working through issues with BLA?
>Does anyone have any thoughts on what might be happening?
>
Yes, but I've not seen your problems yet. The subscribe messages
being sent from one of the presence modules are not cooperating
with NAT. Some module is ignoring the 'received' tag on the AOR
and trying to send SUBSCRIBE to a private IP. I'm still trying
to debug this, but I thought you might like to know. Maybe you
aren't affected by NAT, in which case you should be happy.

Our UAs exchange messages only over TCP connections. Maybe that
is a clue.

Regards,
Brian

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

Re: [OpenSIPS-Users] TCP AORs and db_mode 1/2/3

[opensipslist]

Hello Bogdan,

An lun., févr 08, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> Thinking today about why my messages are sometimes routed to
>> nonexistent TCP endpoints, I came upon the following idea:
>>
>>   It seems that if the usrloc db_mode is anything but 0,
>>   then TCP AORs could be read from the database after a
>>   crash. This can't work because once OpenSIPS stops,
>>   the TCP connections are destroyed. They aren't reusable
>>   again, because routers and firewalls would block the
>>   connections that OpenSIPS tries to reestablish.
>>
>> First of all, is that right?
>>
>That is correct.
>
>> If so, then for what reason are the db_modes 1, 2, and 3
>> even useful at all? For UDP-only systems, right?
>>
>not really. Even if the TCP conn is lost while the registration
>still valid, the conn can be re-established from the client side
>(like the client placing a call).
>
I tested this and at least with my routers when a TCP connection
to OpenSIPS is lost the NAT binding is destroyed. Should the UAC
place a call once OpenSIPS is started again, a new TCP connection
is created with a new NAT binding and a different outgoing TCP port.

That means that should OpenSIPS reuse the old TCP port from the
registration in usrloc, then it could send for example a NOTIFY
to the wrong place, right?

By the way, I set db_mode to 0 to avoid this problem. The location
table in db_text is still being populated when save() is called.
Doesn't the db_mode '0' parameter of usrloc mean that nothing will
be written to the database when save() is called?

Regards,
Brian

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

Re: [OpenSIPS-Users] Bug in b2b code

[opensipslist]

Hello Anca,

An lun., févr 08, 2010, Anca Vamanu schrieb:
>Can you print here the INVITE generated by the B2B just to
>see the ruri?
>
How do you recommend to do that? The incoming INVITE is encrypted
over a TLS connection. Trying to capture the message which B2B
forwards (incorrectly over TLS) using the standard tools like
socat(1), snoop(1), or tcpdump(1) is difficult or impossible.

I'm specifying

  sip:mediap...@media.europalab.com:5080;transport=tcp

as the parameters of the prepaid scenario, which worked in the B2B
implementation of OpenSIPS 1.6.0. A change from SVN revision 6567 or
a previous one introduced the bug which seemingly ignores the
transport as specified above.

Are you able to connect a UAC which sends a INVITE over TLS and
which the B2B logic forwards according to your chosen transport?
If so, which version of OpenSIPS are you using?

Regards,
Brian

___
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 ven., févr 05, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> 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?
>>
>That is the right one - use the compile instructions from there and
>run use memlog=10 (to avoid extra debugs from memory) and memdump=1
>(to get mem dump at shutdown)
>
>If a mem issue is found, your opensips will automatically coredump
>and dump mem stats.
>
Okay I finally got everything compiled, configured, running, and...

  ...dumping. Here's the backtrace:

Core was generated by `/pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid -m 
64'.
Program terminated with signal 11, Segmentation fault.
[New process 12345]
#0  0xd0e19f23 in replace_uri (msg=0x8355f48, display=0x8046f48, uri=0x8046f50, 
hdr=0x8356658, rr_param=0xd0e1fa68) at replace.c:271
271 replace.c: No such file or directory.
in replace.c
(gdb) bt
#0  0xd0e19f23 in replace_uri (msg=0x8355f48, display=0x8046f48, uri=0x8046f50, 
hdr=0x8356658, rr_param=0xd0e1fa68) at replace.c:271
#1  0xd0e1c701 in w_replace_to (msg=0x8355f48, p1=0x8348a88
"\030?3\b\004", p2=0x0)
at uac.c:408
#2  0x08076000 in do_action ()
#3  0x0807961b in run_action_list ()
#4  0x08077574 in do_action ()
#5  0x0807961b in run_action_list ()
#6  0x08078177 in do_action ()
#7  0x0807961b in run_action_list ()
#8  0x080799f0 in run_top_route ()
#9  0x080be52a in receive_msg ()
#10 0x080f4c74 in tcp_read_req ()
#11 0x080f67fd in ?? ()
#12 0xcc78ebe8 in ?? ()
(gdb) 

It seems to me that the crash came just after trying memcpy(3),
but looking at modules/uac/replace.c:271 I still don't see the
reason. I am using uac_replace_from and uac_replace_to in the
route script but there is no mention of 'no more pkg mem' in
the logs at all (from replace.c:268.)

There is a lot in the log (I used debug=4) as well as sip_trace
so I don't know what to post. It will be a nightmare sanitizing
the post to hide private information. What do you recommend?

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 lun., févr 08, 2010, Anca VAMANU schrieb:
>The scenario that you want - authorizing the user at the media
>server in a bridging scenario will not work. You can not call
>b2b_init twice for the same dialog. The B2B implementation does not
>include the authorization requirements. And in fact I believe that
>you are complicating things by wanting the user to authorize to the
>media server. The normal approach will be for the user to authorize
>to the proxy and only after it has been authorize to call b2b_init
>function.  And for the media server not to ask for authorization
>because the proxy should be in a trusted source list and the
>requests coming from it should not be challenged.
>
Okay now it's clear, thanks for the help. But the problem is not
solved, because there are situations in which the INVITE from your
B2B logic should be challenged. In my case, the media server is
serving voicemail as well. It must challenge incoming INVITEs
because sometimes the 'From' URI describes a voicemail user that
will be authorized to listen to their messages by way of the
standard WWW-Authenticate.

At the same time, I'm sure there's no problem in passing the 
'Authorization' header if I make a new B2B module or simply patch
the existing one. Is it true that calling b2b_init a second time
will be no problem, because as b2b_logic sees the 401
WWW-AUthenticate it will close the dialog started by the INVITE?

Can you please advise me whether the needed change to pass the
'Authorization' header is in b2b_entities or b2b_logic? Do you
see any problem in doing this?

I have some other ideas of implementing B2B modules ontop of
b2b_entities, so this would be a good way to become introduced
to the code.

Regards,
Brian

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

[OpenSIPS-Users] Bug in dialog db logic

[opensipslist]

Hello list,

In the log:

  Feb 07 16:25:32  opensips[14512]: ERROR:db_text:dbt_insert: cannot 
insert the new row!!
  Feb 07 16:25:32  opensips[14512]: ERROR:dialog:update_dialog_dbinfo: 
could not add another dialog to db

The system is running:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS

I checked to see if there were changes in SVN related to dialog db
handling or the db_text module, and there aren't. I also tried
increasing the debug level to find out if the dialog table has
some problem, but it seems there is very little debug log code
in the dialog module to support debugging.

  id(int,auto) hash_entry(int) hash_id(int) callid(string) from_uri(string) 
from_tag(string) to_uri(string) to_tag(string) caller_cseq(string) 
callee_cseq(string) caller_route_set(string,null) callee_route_set(string,null) 
caller_contact(string) callee_contact(string) caller_sock(string) 
callee_sock(string) state(int) start_time(int) timeout(int)

Any ideas why OpenSIPS can't write to the dialog table?

Regards,
Brian

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

[OpenSIPS-Users] TCP AORs and db_mode 1/2/3

[opensipslist]

Hello list,

Thinking today about why my messages are sometimes routed to
nonexistent TCP endpoints, I came upon the following idea:

  It seems that if the usrloc db_mode is anything but 0,
  then TCP AORs could be read from the database after a
  crash. This can't work because once OpenSIPS stops,
  the TCP connections are destroyed. They aren't reusable
  again, because routers and firewalls would block the
  connections that OpenSIPS tries to reestablish.

First of all, is that right?

If so, then for what reason are the db_modes 1, 2, and 3
even useful at all? For UDP-only systems, right?

Regards,
Brian

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

[OpenSIPS-Users] Bug in b2b code

[opensipslist]

Hello list,

Observed in revision 6567, bridging a client while explicitly
setting the transport in the client URI will not work. The transport
is ignored. In version 1.6.0 using the prepaid.xml as an example,
setting the client URIs with:

  b2b_init_request("prepaid", "sip:tar...@name.host.tld:1234;transport=tcp", 
"sip:tar...@name.host.tldl5678;transport=tcp");

...caused a bridge to start over the TCP transport. When integrating
the changes of revision 6567 (the newest b2b_entities and b2b_logic
to date) a bridge is created over the same transport as the initial
message, ignoring any explicitly set transport.

Does this make sense? WHile not knowing exaclty where the problem
lies, I suspect it is modules/b2b_entities/client.c or client.h.

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., févr 05, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> Unfortunately, b2b_logic doesn't pass on the Authorization header
>> from the client to the server so authorization is failing. The
>> module parameters of my script are:
>>
>>   modparam("b2b_logic", "custom_headers", 
>> "WWW-Authenticate;Proxy-Authenticate;Authorization;Subject")
>>
>> The page 'B2buaTutorial' says:
>>
>>   If type node with message value is present, it means that the
>>   client will be created using the info from received SIP message:
>>   the body, the caller URI, some SIP headers(Accept, Supported,
>>   Content-Type).
>>
>> It seems as if custom_headers are only passed from the server to the
>> client, or maybe b2b_logic only recognizes them in dialog (after the
>> first INVITE is accepted?)
>>
>No, these are not the cases. The Authorization header should be passed 
>from the first Invite(it's the same processing function as for the 200OK 
>reply - b2b_logic_notify). Do you see something in the log? Any Error?
>
The log has no entries at all with debug=1. When changed to debug=10
I see a ton of stuff but still no errors. I tried to find anything,
and only found the INVITE and 401 WWW-Auth that b2b_logic is
handling. All seems normal.

>However, there will be a problem in the second call setup if
>authorization will be requested again, because there is no way to
>get that authorization information from the caller in the middle of
>the call..
>
I don't understand. So far there is only one UA challenging and that
is the media server (looking at your diagram called ppaid.jpeg) By
the way, b2b_init_request("top hiding"); is working correctly.

Here is a shorthand transcription of what is happening:

Caller  OpenSIPS B2B  Mediaserver
  |  | |
INVITE ->| INVITE >|
  |  | |
  |<--- 401 WWW-Authenticate |< 401 WWW-Authenticate
  |  | |
INVITE + Authorization ->| INVITE (no auth) -->|
  |  |!|
  |  | |
  |<--- 401 WWW-Authenticate |< 401 WWW-Authenticate
  |  | |

I've left out ACKs of course. As you see from the line marked ''
the b2b_logic is dropping the 'Authorization' header from the INVITE.

Here's the b2b_logic config:

modparam("b2b_logic", "custom_headers", 
"Proxy-Authenticate;Proxy-Authorization;WWW-Authenticate;Authorization;Subject")

Here's the route script piece:

# sequential requests
if (has_totag()) {
if (loose_route()) {
#[...]
}
#[...]
}

# initial requests
if (is_method("INVITE") && src_ip != myself) {
if (!t_newtran()) {
sl_reply_error();
exit;
}
b2b_init_request("prepaid", 
"sip:t...@medsrv.host.tld:5080;transport=tcp", 
"sip:t...@medsrv.host.tld:5080;transport=tcp");
#b2b_init_request("top hiding");
exit;
}

If I print the message body from the route script (xlog...$mb) then
I can see that the Authorization header is there before calling
'b2b_init_request.' Is it a problem that b2b_init_request is being
called twice, once for the first INVITE (with no auth) and then
again for the second INVITE (with the Authorization header.)?

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., févr 05, 2010, opensipsl...@encambio.com schrieb:
>An ven., févr 05, 2010, Anca Vamanu schrieb:
>>If you use the trunk svn branch, you have a parameter in b2b_logic
>>module - "custom_headers". You can set it to "WWW-Authenticate,
>>Authorization" and the content of these headers will be passed on
>>the other side.
>>
>That's great, thanks Anca. I'll try out the new 'custom_headers'
>parameter.
>
I integrated your changes from revision 6291:

  'new feature - possibility to define costum headers to be
  passed from the dialog of one side to the other'

...and finally the WWW-Authenticate header arrived at my UAC (which
sent the first INVITE.) It sucessfully builds a Authorization string
and sends a second INVITE.

Unfortunately, b2b_logic doesn't pass on the Authorization header
from the client to the server so authorization is failing. The
module parameters of my script are:

  modparam("b2b_logic", "custom_headers", 
"WWW-Authenticate;Proxy-Authenticate;Authorization;Subject")

The page 'B2buaTutorial' says:

  If type node with message value is present, it means that the
  client will be created using the info from received SIP message:
  the body, the caller URI, some SIP headers(Accept, Supported,
  Content-Type).

It seems as if custom_headers are only passed from the server to the
client, or maybe b2b_logic only recognizes them in dialog (after the
first INVITE is accepted?)

Is it possible that the custom headers code from revision 6291 is
incomplete and that I should integrate SVN code from another
revision as well? Am I doing something else wrong when testing your
prepaid.xml scenario?

By the way your suggestion to separate headers with a comma probably
does not work because:

  p = strchr(custom_headers.s, ';');

...is what you wrote in b2b_logic.c.

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., févr 05, 2010, Anca Vamanu schrieb:
>opensipsl...@encambio.com wrote:
>> 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?
>>
>No, unfortunately there is no other way to tell b2b to use other
>protocol.
>
It's probably enough to do it the way I described, but it seems like
there must be a more elegant/consistent way to do transport changes.

>> 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?
>>
>If you use the trunk svn branch, you have a parameter in b2b_logic
>module - "custom_headers". You can set it to "WWW-Authenticate,
>Authorization" and the content of these headers will be passed on
>the other side.
>
That's great, thanks Anca. I'll try out the new 'custom_headers'
parameter.

Regards,
Brian

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

Re: [OpenSIPS-Users] Building Presences and PUA for OpenSIPS 1.6.1

[opensipslist]

Hello Steven,

An ven., févr 05, 2010, Steven C. Blair schrieb:
> Neither the presence or PUA modules want to build under 1.6.1.
> make says it cannot find libxml2 even though the package is
> installed. Are there any known issues building these modules?
>
There are no problems building the modules of the 1.6.1 release,
however the difficulty you describe is already known. To date no
correction has been made to the defective build configuration.

Take a look at the Makefile of a number of modules using libxml,
for example the one in modules/presence specifies:

DEFS+=-I$(SYSBASE)/include/libxml2 -I$(LOCALBASE)/include/libxml2 \
  -I$(LOCALBASE)/include
LIBS=-L$(SYSBASE)/include/lib  -L$(LOCALBASE)/lib -lxml2

...but hardcoding such values into the build configuration is risky
and often leads to runtime security problems or build failures like
the one you're describing. Do this instead:

DEFS+=`/pfx/bin/pkg-config --cflags-only-I libxml-2.0`
LIBS=`/pfx/bin/pkg-config --libs libxml-2.0`

The 'pfx' is the path root in which you have libxml. In
'/pfx/lib/pkgconfig' you'll find 'libxml-2.0.pc' which can
be queried with the program 'pkg-config'.

Testing this on my system I see:

  $ /pfx/bin/pkg-config --cflags-only-I libxml-2.0
  -I/pfx/include/libxml2 -I/pfx/include
  $ /pfx/bin/pkg-config --libs libxml-2.0
  -R/pfx/lib -L/pfx/lib -lxml2 -lz -liconv -lm -lsocket -lnsl

...and that is what the OpenSIPS build configuration should be
using. By the way, this defect is not specific to the build
configuration of the presence modules. It is in others as well.
Good luck.

Regards,
Brian

___
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] What is protocol/port mismatch?

[opensipslist]

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
>outbound interfaces... only if you do it manually from the script.
>
I've configured OpenSIPS to listen on only one interface, so I guess
that I'm not affected by this breakage. Next I'll try to solve the
problem another way without disabling double Record-Route headers.

>To me, the solution looks like a dirty hack, but if makes Asterisk
>happy... what can I say :)
>
Now that I know more I'll try to solve it another way.

Regards,
Brian

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

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

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?

Regards,
Brian

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

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

Hello,

An mar., févr 02, 2010, opensipsl...@encambio.com schrieb:
>An mer., déc  23, 2009, Bogdan-Andrei Iancu schrieb:
>>opens...@encambio.com wrote:
>>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>> My gut feeling is that having four UDP listening processes and four
>>> TCP listening processes is about right for us, because we only have
>>> a handful of UACs participating infrequently (5 calls per day.)
>>>   
>>Actually that is more than needed - during some performance tests (only 
>>simply call relaying) we managed to put 6K cps in a single process.
>>
>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)
>
>Because you mentioned that you benchmarked 6K CPS with a single
>process (was it TCP?), I'd like to know if you got as many warnings
>as well. One question is:
>
>  What does 'free tcp receiver' mean? I assumed that listening
>  TCP ports were free to accept as many connections as needed.
>
> [...]
>
>Is OpenSIPS expecting there to be at least one TCP listener process
>which is not encumbered by the tcp_persistent_flag?
>
At risk of answering my own question and questioning my own answer,
I'd like to suggest the following change:

--- tcp_main.c.orig 2010-01-18 12:33:49.151095000 +0100
+++ tcp_main.c  2010-02-02 20:07:15.263065567 +0100
@@ -911,7 +911,7 @@
tcp_children[idx].busy++;
tcp_children[idx].n_reqs++;
if (min_busy){
-   LM_WARN("no free tcp receiver, connection passed to the least"
+   LM_INFO("no free tcp receiver, connection passed to the least "
"busy one (%d)\n", min_busy);
}
LM_DBG("to tcp child %d %d(%d), %p\n", idx, tcp_children[idx].proc_no,

That would correct the defective english spelling 'leastbusy' as
well as ridding the log of a properly running OpenSIPS server of
false warnings. I'm assuming of course, that it's perfectly okay
for TCP listener processes to keep a TCP connection open by using
the tcp_persistent_flag and accept new SIP requests at the same
time.

Regards,
Brian

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

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

Hello Bogdan,

An mer., déc  23, 2009, Bogdan-Andrei Iancu schrieb:
>opens...@encambio.com wrote:
>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>> To see what processes you have and what they are doing, do:
>>>
>>> opensipsctl fifo ps
>>>
>>   # opensipsctl fifo ps
>>   Process::  ID=0 PID=24975 Type=attendant
>>   Process::  ID=1 PID=24977 Type=SIP receiver udp:123.234.210.1:5060
>>   Process::  ID=2 PID=24978 Type=time_keeper
>>   Process::  ID=3 PID=24979 Type=timer
>>   Process::  ID=4 PID=24980 Type=MI FIFO
>>
>> [...]
>>
>> My gut feeling is that having four UDP listening processes and four
>> TCP listening processes is about right for us, because we only have
>> a handful of UACs participating infrequently (5 calls per day.)
>>   
>Actually that is more than needed - during some performance tests (only 
>simply call relaying) we managed to put 6K cps in a single process.
>
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)

Because you mentioned that you benchmarked 6K CPS with a single
process (was it TCP?), I'd like to know if you got as many warnings
as well. One question is:

  What does 'free tcp receiver' mean? I assumed that listening
  TCP ports were free to accept as many connections as needed.

By the way, each of the 16 UACs registered to the 8 TCP listener
processes is avoiding NAT problems by keeping the TCP connection
open by setting the tcp_persistent_flag.

Is OpenSIPS expecting there to be at least one TCP listener process
which is not encumbered by the tcp_persistent_flag?

Regards,
Brian

___
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 list,

The problem was that the voicemail server was respecting the host
and port of the routeset which OpenSIPS was rewriting to acommodate
the transport change from TLS to TCP. The voicemail server was
configured to send over TLS to the outbound proxy however, so
traffic was arriving at OpenSIPS on the port 5060 using TLS.

It's clear now why the warnings were appearing in the logs, but
even more it seems that OpenSIPS sometimes crashes when sending
TLS traffic to a TCP port which it is expecting clear text from.

To know about the solution to this problem, read below.

An ven., janv 29, 2010, opensipsl...@encambio.com schrieb:
>An ven., janv 29, 2010, Bogdan-Andrei Iancu schrieb:
>>opensipsl...@encambio.com wrote:
>>> ...and I see this in the log:
>>>
>>>opensips[2717]: WARNING:core:get_send_socket: protocol/port 
>>> mismatch
>>>
>>> some hundreds of times per day (about once every 20 minutes
>>> per registered UAC.)
>>>
>>> I have this in the route script:
>>>
>>>   listen = tls:name.host.tld:5061
>>>   [...]
>>>   t_relay("name.host.tld:5080");
>>>
First, although all UAs were exchanging SIP traffic with OpenSIPS
over TLS, t_relay was relaying the messages over UDP. I assume that
t_relay is either hardcoded to use UDP or OpenSIPS was routing the
messages to itself internally over UDP (to recursively resolve
aliases.) In this case maybe t_relay implicitly uses the transport
over which the message was last received (even internally.)

In any case, the call to t_relay should look like this if relaying
over the TCP transport is desired:

  t_relay("tcp:name.host.tld:5080");

The problem then is that the rr module will add two Record-Route
headers, expecting a symetrical fashion of SIP traffic. I turned
this off with modparam("rr", "enable_double_rr", 0) because the
voicemail server (Asterisk) is very tricky (maybe even buggy) to
configure to use TLS and outbound proxies.

At this point I saw that traffic was arriving at OpenSIPS port 5061
over TLS as expected, and as indicated by the routeset. The problem
is solved.

>Is the basic idea of this warning message that OpenSIPS
>exchanges a SIP message with a UA over a certain transport
>(TLS in this case) and port number (5061 in this case), but
>a t_relay in the route script forwards the message over a
>different transport or to a different port number?
>
The basic idea of this warning message is that OpenSIPS expects
a certain type (TLS or not TLS) of traffic at a certain TCP port
as configured by the 'listen' directives. If a UAC sends TLS
traffic to a port only configured to listen to plain text traffic
then this warning will appear. What happens to the mismatched
traffic is not clear, but I assume that it is ignored by OpenSIPS.

>If so, what is being compared and how is it compared?
>
The TCP port on which OpenSIPS listens to and the type of traffic,
either TLS encrypted or plain text.

Regards,
Brian

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

Re: [OpenSIPS-Users] Matching problem in dialog module

[opensipslist]

Hi Bogdan,

An lun., févr 01, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An mer., janv 27, 2010, Bogdan-Andrei Iancu schrieb:
>>> opensipsl...@encambio.com wrote:
 An sam., janv 23, 2010, opensipsl...@encambio.com schrieb:
> I send a INVITE over TLS and it is routed properly (I can call
> normally.) The validate_dialog() is failing to match routesets.
>
 By the way, I've tried all three possible dlg_match_mode modes,
 and I've tried using create_dialog() instead of set_flag(dlg_flag).
 Every time I see the error that the route check failed.

>>> Let me run some tests on this scenario (with proto changing).
>>>
>> I see from revision 6550 that you found some problem with dialog
>> matching and routeset comparisons. Do you recommend that we test
>> your changes, or is there some reason you've not written about it
>> on the mailing list?
>>
>I'm still running some tests on it to be sure everything is ok.
>
Oh, that's why. I'll wait until you give the go ahead.

>> Also, the two comments of revision 6550 don't indicate if the
>> correction to routeset comparison is dependent on the new RR API
>> extension (reporting the number of lr removed routes.)
>>
>both are related to the fix - dialog module needed some more info
>from RR in order to do a correct Route checking.
>
>> Is it safe to build OpenSIPS with only the dialog routeset checking
>> correction and not the RR API extension?
>>
>no - dialog will not compile anymore - update both.
>
Okay.

>> If these two comments describe independent changes, it might have
>> been a better idea to make two different SCN revisions. I can't
>> figure out which changes to test for the dialog routeset checking.
>>
>not the case one commit, one fix :)
>
That's good, I should have known better. Thanks for the correction,
related RR API addition, and testing as well. Good luck with that.

Regards,
Brian

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

Re: [OpenSIPS-Users] Matching problem in dialog module

[opensipslist]

Hello Bogdan,

An mer., janv 27, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An sam., janv 23, 2010, opensipsl...@encambio.com schrieb:
>>> I send a INVITE over TLS and it is routed properly (I can call
>>> normally.) The validate_dialog() is failing to match routesets.
>>>
>> By the way, I've tried all three possible dlg_match_mode modes,
>> and I've tried using create_dialog() instead of set_flag(dlg_flag).
>> Every time I see the error that the route check failed.
>>
>Let me run some tests on this scenario (with proto changing).
>
I see from revision 6550 that you found some problem with dialog
matching and routeset comparisons. Do you recommend that we test
your changes, or is there some reason you've not written about it
on the mailing list?

Also, the two comments of revision 6550 don't indicate if the
correction to routeset comparison is dependent on the new RR API
extension (reporting the number of lr removed routes.)

Is it safe to build OpenSIPS with only the dialog routeset checking
correction and not the RR API extension?

If these two comments describe independent changes, it might have
been a better idea to make two different SCN revisions. I can't
figure out which changes to test for the dialog routeset checking.

Regards,
Brian

___
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 ven., janv 29, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> ...and I see this in the log:
>>
>>opensips[2717]: WARNING:core:get_send_socket: protocol/port 
>> mismatch
>>
>> some hundreds of times per day (about once every 20 minutes
>> per registered UAC.)
>>
>> I have this in the route script:
>>
>>   listen = tls:name.host.tld:5061
>>   [...]
>>   t_relay("name.host.tld:5080");
>>
>Do you use "force_send_socket()" functions in your script,
>before the t_relay ?
>
No, I have 'force_rport()' in the script, but neither
'force_send_socket()' nor 'force_tcp_alias()' is there at
all. Are you suggesting that I use it before t_relay to the
server with a different transport?

Is the basic idea of this warning message that OpenSIPS
exchanges a SIP message with a UA over a certain transport
(TLS in this case) and port number (5061 in this case), but
a t_relay in the route script forwards the message over a
different transport or to a different port number?

If so, what is being compared and how is it compared?

  Port1 == Port2
  Transport1 == Transport2
  Transport1 & Port1 == Transport2 & Port2
  ...?

Thanks,
Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello Bogdan,

An ven., janv 29, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>>> 1) the BLA part is sending the SUBSCRIBEs based on user location
>>> and it is using the "received" field if present, so it should be
>>> ok. Unless you set in the bla module the "outbound" param - this
>>> will override the received info.
>>>
>> My module parameters for presence and BLA are:
>>
>> modparam("presence", "server_address", "sip:p...@name.host.tld")
>> modparam("presence_xml", "force_active", 1)
>> modparam("pua_bla", "server_address", "sip:p...@name.host.tld")
>> modparam("pua_bla", "default_domain", "name.host.tld")
>> modparam("pua_bla", "header_name", "Sender")
>>
>> ...so I'm not setting the 'outbound' parameter it seems, right?
>>
>In such a case, check in usrloc if the registrations for the user
>the SUBSCRIBE belongs to, do has the received field - maybe the
>error is when saving the contacts and not when using them.
>
That would be nice, but I don't think so:

  # /pfx/sbin/opensipsctl ul show
  AOR:: user1
Contact:: sip:us...@192.168.0.31:3618;transport=tls;line=9hm7f0ua Q=1
  Expires:: 352
  Callid:: 703c26357076-zmjcebpdyaey
  Cseq:: 1058
  User-agent:: Unimportant
  Received:: sip:82.90.12.232:2108;transport=TLS
  State:: CS_SYNC
  Flags:: 0
  Cflag:: 64
  Socket:: tls:62.124.111.222:5061
  Methods:: 7999

 After running a socket listener on 192.168.0.31 on the OpenSIPS host:

$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
SUBSCRIBE 
 sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm SIP/2.0
Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
To: ;tag=ty6sjh9iz9
From: ;tag=6c9d4319c74d756e6b696-baa1
CSeq: 11 SUBSCRIBE
Call-ID: b1c04118-8...@86.90.39.44
Content-Length: 0
User-Agent: OpenSIPS (1.6.1-tls)
Max-Forwards: 70
Event: dialog;sla
Contact: 
Expires: 610

>> Any ideas?
>>   
>If you could try to get a capture of the whole flow - starting with
>REGISTER, etc.plus the logs...  But first check the usrloc (see
>1))
>
I'll do that next, when I have time over the weekend. Capturing is
actually quite difficult because everything is TLS, and there are
more than one phone, as well as a voicemail server...

Thanks for helping so far, and if you think of anything based on
your suggestion 1) and my answer, then please advise.

Thanks,
Brian

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

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

[opensipslist]

Hello list,

I'm using:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS

...and I see this in the log:

   opensips[2717]: WARNING:core:get_send_socket: protocol/port mismatch

some hundreds of times per day (about once every 20 minutes
per registered UAC.)

I have this in the route script:

  listen = tls:name.host.tld:5061
  [...]
  t_relay("name.host.tld:5080");

There is a voicemail server (not OpenSIPS) listening on TCP (not
TLS) port 5080 on the same host. OpenSIPS and the other server
exchange traffic such as SUBSCRIBE and NOTIFY for MWI and INVITEs
to voicemail. The voicemail server sends SIP messages to OpenSIPS
port 5061 over TLS (I think.)

Question:
What exactly is the meaning of these warnings in the log, and does
it seem that I'm doing something wrong in the route script?

Thanks,
Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello Bogdan and Anca,

An mar., janv 26, 2010, Bogdan-Andrei Iancu schrieb:
>Just consulted with Anca (she is the presence guru) and 2 questions
>for you:
>
Thanks to Anca very much for such good work with the presence
modules. I'm excited to be able to use them correctly (thus my
troubleshooting and questions.)

>1) the BLA part is sending the SUBSCRIBEs based on user location
>and it is using the "received" field if present, so it should be
>ok. Unless you set in the bla module the "outbound" param - this
>will override the received info.
>
I know that at least some part of the BLA logic or presence logic
is indeed using the 'received' field, because OpenSIPS is sending
to the correct UAS 1/2 the time. It is equially clear that some
other part of BLA or presence is ignoring the 'received' field.
For each UAS which registers tcpdump shows two SUBSCRIBE messages.
One with the 'received' IP and one with the private IP.

My module parameters for presence and BLA are:

modparam("presence", "server_address", "sip:p...@name.host.tld")
modparam("presence_xml", "force_active", 1)
modparam("pua_bla", "server_address", "sip:p...@name.host.tld")
modparam("pua_bla", "default_domain", "name.host.tld")
modparam("pua_bla", "header_name", "Sender")

...so I'm not setting the 'outbound' parameter it seems, right?

I'm using:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS

>2) the subscribe you posted - as you captured it, I supposed it
>exists on network. But I see that the transport in TLS (so TCP
>based), but how come you see the message if opensips is not able to
>open the TCP conn to the private IP..
>
Good question, but I showed you just how I was capturing traffic
to the private IP. You probably missed it, so here it is again:

>> After running a socket listener on 192.168.0.31 on the OpenSIPS host:
>>
>>$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
>>SUBSCRIBE sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm 
>> SIP/2.0
>>Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
>>To: ;tag=ty6sjh9iz9
>>From: ;tag=6c9d4319c74d756e6b696-baa1
>>CSeq: 11 SUBSCRIBE
>>Call-ID: b1c04118-8...@86.90.39.44
>>Content-Length: 0
>>User-Agent: OpenSIPS (1.6.1-tls)
>>Max-Forwards: 70
>>Event: dialog;sla
>>Contact: 
>>Expires: 610
>>
It's plain old TCP/IP networking. First do a ifconfig to create
a virtual interface with IP 192.168.0.31, then set a static route,
and finally run software to listen on the TCP socket on the address.
This works as long as I do it on the same machine that OpenSIPS (the
presence modules) are running on.

Any ideas?

Thanks,
Brian

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

Re: [OpenSIPS-Users] B2BUA not passing ACKs

[opensipslist]

Hello Anca,

Sorry for the delay.

An lun., janv 04, 2010, Anca Vamanu schrieb:
>There is a misunderstanding from your side in what the b2b scenario
>documents are concerned ( please read carefully the documentation -
>http://www.opensips.org/Resources/B2buaTutorial ).
>
It's hard to figure out which document to read, as the documents are
so unclear that they need documentation themselves. What I mean is:

Why are there two documents listed on the website for the same
thing. One called 'B2buaTutorial' and the other 'B2buaTutorial16'?
Is the second a older document only useful for OpenSIPS 1.6.0, or
is it a newer version of the document B2buaTutorial?

There are also no links to plain text config files, and everything
is HTML. A complete working route script is not available.

>The important thing is that there should only be rules in the
>scenario for requests that need a special handling. In the prepaid
>scenario - when the BYE from the media server is received the
>caller must be connected to a human operator, so we have a rule for
>this. All the other requests need only simple pass forward - so if
>an ACK is received from one side it only need to be forwarded to
>the other. 'pass forward' is the implicit action and it will be
>applied to all requests that don't match a rule.
>
Thanks for clearing that up (about the implicit action.) I think
I understand better now, but still I would like to start from the
beginning and use the supplied prepaid.xml (which I assume is
correctly written.)

>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...@123.123.123.123:5080", 
"sip:playso...@123.123.123.123: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? What about the parameters
'123.123.123.123'? Is 't_newtran' necessary?

Regards,
Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello Bogdan,

An ven., janv 22, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An jeu., janv 21, 2010, opensipsl...@encambio.com schrieb:
>>> An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb:
 opensipsl...@encambio.com wrote:
>>> After running a socket listener on 192.168.0.31 on the OpenSIPS host:
>>>
>>>$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
>>>SUBSCRIBE 
>>> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm SIP/2.0
>>>Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
>>>To: ;tag=ty6sjh9iz9
>>>From: ;tag=6c9d4319c74d756e6b696-baa1
>>>CSeq: 11 SUBSCRIBE
>>>Call-ID: b1c04118-8...@86.90.39.44
>>>Content-Length: 0
>>>User-Agent: OpenSIPS (1.6.1-tls)
>>>Max-Forwards: 70
>>>Event: dialog;sla
>>>Contact: 
>>>Expires: 610
>>>
>>> I'm trying to implement presence by using the presence,
>>> presence_xml, pua, and pua_bla modules.
>>>
>>> So it seems that one of these modules (see event dialog;sla) is
>>> getting the contact from the locations table (in AAA on our server)
>>> and ignoring the Received header.
>>>
>>> OpenSIPS replies to messages from UACs such as INVITE and CANCEL
>>> properly, and opens connections to the IP in Received. This problem
>>> is limited to the SUBSCRIBES sent from one of the presence modules.
>>> 
>> ...and similar SUBSCRIBE messages (sent from one of the presence
>> modules) are not having this problem. They are almost the same as
>> the one above, but simply don't have a to tag.
>>
>So you have problems with a SUBSCRIBE that is internally generated
>by one of the presence modules? It is not a proxied request, right?
>
Problem
I know I have a problem because tcpdump shows that OpenSIPS is
trying to reach a private IP address across the Internet.

Workaround
It seems that one of the presence modules is responsible for that,
because when I remove bla_handle_notify() and bla_set_flag() from
the route script, then the attempted private IP connections stop.

Proxied request
...and because I see no SUBSCRIBE (event dialog;sla) messages coming
from all the connected UAs (in their logs), it is quite clear that
some presence module of OpenSIPS is creating the SUBSCRIBEs.

Guesses
At first I was sure it was the pua_bla, but after looking at the
code I see that pua_bla uses other presence modules (pua, presence,
presence_xml?) So it could be that another one is constructing or
sending the SUBSCRIBE without observing the 'Received' header, and
thus using a private IP instead.

Greetings,
Brian

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

Re: [OpenSIPS-Users] Matching problem in dialog module

[opensipslist]

Hello again,

An sam., janv 23, 2010, opensipsl...@encambio.com schrieb:
>I send a INVITE over TLS and it is routed properly (I can call
>normally.) The validate_dialog() is failing to match routesets.
>
By the way, I've tried all three possible dlg_match_mode modes,
and I've tried using create_dialog() instead of set_flag(dlg_flag).
Every time I see the error that the route check failed.

Regards,
Brian

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

[OpenSIPS-Users] Matching problem in dialog module

[opensipslist]

Hello list,

I send a INVITE over TLS and it is routed properly (I can call
normally.) The validate_dialog() is failing to match routesets.

I use the function like this:

if ($DLG_status != NULL) {
if (!validate_dialog()) {
xlog("L_WARN", "$rm: In dialog bogus request\n");
}
}

My UA -> OpenSIPS -> Callee  ...all TLS:5061 except Callee UDP:5060
INVITE ->|>|
  |<-|<--- OK
 ACK --->|>|   ...ACK is failed by validate_dialog()
  |<-|<--- BYE ...BYE is failed by validate_dialog()

The call to validate_dialog() fails to match the ACK (and BYE) with
their associated dialog. The log shows:

debug> opensips[2815]: DBG:dialog:dlg_validate_dialog: route check failed 
req=[] 
dlg=[,]

Here's a simplification of the log entry.

Request route identifier:
  128.111.222.333;r2=on;lr=on;ftag=qpii9b4zsg;did=bbc.9ae7

Dialog route identifier:
  128.111.222.333:5061;transport=tls;r2=on;lr=on;ftag=qpii9b4zsg;did=bbc.9ae7

SIP route identifier:
  128.111.222.333;r2=on;lr=on;ftag=qpii9b4zsg;did=bbc.9ae7

...so you see that really they are equivalent, only the dialog route
identifier has the port and transport appended. Here's the route set
that I read from my UAS after sending the INVITE:

SIP/2.0 200 OK
Via: SIP/2.0/TLS 
192.168.130.131:3651;received=86.81.28.62;branch=4bKz9hG-i7nhmjfdnqmf;rport=3651
Record-Route: 
Record-Route: 

From: "User Me" ;tag=qpii9b4zsg

Can it be that the dialog module is not correctly matching the route
set? Or is it wrong that one of the entries in the route set doesn't
have the TLS port and transport appended?

Why is the matching not working?

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send to UDP UACs

[opensipslist]

Hello Bogdan,

An mar., déc  22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
 But this is maybe a clue. It would seem that something in TLS
 writing has changed between these two versions, maybe fundementally?

>>> 1.3 was doing infinite loop (for write and read), leading sometime to 
>>> blocking.
>>>
>> That was a painful part of 1.3, so good that the counter is there
>> now. I guess you're saying that the same TLS problems existed in
>> 1.3 as well, but they were masked by retries (maybe thousands.)
>>
>yes, that is correct.
>
Can it be that when the internal OpenSIPS TCP lifetime counter is
set to the registration interval using the tcp_persistent_flag that
this counter is used even when the registration forcefully expires?

What I mean by forcefully is:

  Some IP phones don't wait for a registration period to time out.
  Instead they wait for 1/2 of the expiry period and then send a
  new REGISTER with a header 'Expires: 0' to force the registration
  to timeout. Then they immediately send a new REGISTER with a
  normal expiry value to obtain a new registration.

...so if an expiry time is 10 minutes, after only 5 minutes the UAC
invalidates the registration and makes a new one.

I'm wondering if OpenSIPS tries opening TCP connections using the
value of 10 minutes with a UAC which is no longer in the location
table because the AOR was removed (due to the principle described
above.)

Possible?

Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello list,

An jeu., janv 21, 2010, opensipsl...@encambio.com schrieb:
>An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb:
>>opensipsl...@encambio.com wrote:
>>> Here's a record I see when I run 'opensipsctl ul show':
>>>
>>> AOR:: mylogin-osips
>>> Contact:: 
>>> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1
>>> Expires:: 560
>>> Callid:: 2b21cdfae784-av13rj1txbsq
>>> Cseq:: 2
>>> User-agent:: Bigphone123
>>> Received:: sip:85.182.68.45:2240;transport=TLS
>>> State:: CS_SYNC
>>> Flags:: 0
>>> Cflag:: 64
>>> Socket:: tls:80.200.123.45:5061
>>> Methods:: 7999
>>>
>>> OpenSIPS is trying to reach the private IP number above from time
>>> to time, and I see this in the logs:
>>>
>>>   Jan 19 17:57:20 name.host.tld  opensips[23432]: ERROR:tm:t_uac: 
>>> attempt to send to 
>>> 'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed
>>>
>>the problem is not the private IP in the contact, as opensips
>>properly saved the source IP (of the REGISTER) too -> see the
>>Received field. So the Received field will be used over the Contact
>>for sending the requests to UAC.
>>
>>Now, what probably goes wrong in your case is that when using
>>TLS/TCP (connection oriented protos), after the REGISTER, the
>>connection is dropped and opensips cannot open later a TCP
>>connection behind a NAT :(By default opensips closes the
>>inactive TCP connections.
>>
>After running a socket listener on 192.168.0.31 on the OpenSIPS host:
>
>$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
>SUBSCRIBE sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm 
> SIP/2.0
>Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
>To: ;tag=ty6sjh9iz9
>From: ;tag=6c9d4319c74d756e6b696-baa1
>CSeq: 11 SUBSCRIBE
>Call-ID: b1c04118-8...@86.90.39.44
>Content-Length: 0
>User-Agent: OpenSIPS (1.6.1-tls)
>Max-Forwards: 70
>Event: dialog;sla
>Contact: 
>Expires: 610
>
>I'm trying to implement presence by using the presence,
>presence_xml, pua, and pua_bla modules.
>
>So it seems that one of these modules (see event dialog;sla) is
>getting the contact from the locations table (in AAA on our server)
>and ignoring the Received header.
>
>OpenSIPS replies to messages from UACs such as INVITE and CANCEL
>properly, and opens connections to the IP in Received. This problem
>is limited to the SUBSCRIBES sent from one of the presence modules.
>
...and similar SUBSCRIBE messages (sent from one of the presence
modules) are not having this problem. They are almost the same as
the one above, but simply don't have a to tag.

Greetings,
Brian

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

Re: [OpenSIPS-Users] Music On Hold Opensips

[opensipslist]

Hello,

An jeu., janv 21, 2010, Alex Balashov schrieb:
>On 01/21/2010 12:00 PM, Mehdi Bouchefra wrote:
>> I'd like to implement the function Music on hold on Opensips.
>>
>OpenSIPS is a SIP proxy, not a media endpoint.  So, it doesn't do
>that.
>
If while OpenSIPS routes a call a person presses 'hold' on a
telephone, often it will send a INVITE (I think it's called a
REINVITE.) What about detecting this 'hold' REINVITE in the
route script and redirecting the message to the media server?

In the end, another software will have to do the job of the media
server (as Alex points out), but it would seem a logical role for
OpenSIPS to play in some redirection for phones and their 'hold'
buttons.

Regards,
Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello again,

An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> Here's a record I see when I run 'opensipsctl ul show':
>>
>> AOR:: mylogin-osips
>> Contact:: 
>> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1
>> Expires:: 560
>> Callid:: 2b21cdfae784-av13rj1txbsq
>> Cseq:: 2
>> User-agent:: Bigphone123
>> Received:: sip:85.182.68.45:2240;transport=TLS
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 64
>> Socket:: tls:80.200.123.45:5061
>> Methods:: 7999
>>
>> OpenSIPS is trying to reach the private IP number above from time
>> to time, and I see this in the logs:
>>
>>   Jan 19 17:57:20 name.host.tld  opensips[23432]: ERROR:tm:t_uac: 
>> attempt to send to 
>> 'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed
>>
>the problem is not the private IP in the contact, as opensips
>properly saved the source IP (of the REGISTER) too -> see the
>Received field. So the Received field will be used over the Contact
>for sending the requests to UAC.
>
>Now, what probably goes wrong in your case is that when using
>TLS/TCP (connection oriented protos), after the REGISTER, the
>connection is dropped and opensips cannot open later a TCP
>connection behind a NAT :(By default opensips closes the
>inactive TCP connections.
>
After running a socket listener on 192.168.0.31 on the OpenSIPS host:

$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr -
SUBSCRIBE sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm 
SIP/2.0
Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0
To: ;tag=ty6sjh9iz9
From: ;tag=6c9d4319c74d756e6b696-baa1
CSeq: 11 SUBSCRIBE
Call-ID: b1c04118-8...@86.90.39.44
Content-Length: 0
User-Agent: OpenSIPS (1.6.1-tls)
Max-Forwards: 70
Event: dialog;sla
Contact: 
Expires: 610

I'm trying to implement presence by using the presence,
presence_xml, pua, and pua_bla modules.

So it seems that one of these modules (see event dialog;sla) is
getting the contact from the locations table (in AAA on our server)
and ignoring the Received header.

OpenSIPS replies to messages from UACs such as INVITE and CANCEL
properly, and opens connections to the IP in Received. This problem
is limited to the SUBSCRIBES sent from one of the presence modules.

...but I'm still not sure how to fix the problem. Any ideas?

Greetings,
Brian

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

Re: [OpenSIPS-Users] Nat_traversal version of fix_nated_sdp()

[opensipslist]

Hello Bogdan,

An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> Because nat_traversal is newer and seems to be where most of the NAT
>> logic will be developed in the future, it seems the natural choice.
>> If I'm right about that, 
>That's not really true.
>
>nathelper is used together with rtpproxy (as media rely), while 
>nat_traversal in used together with mediaproxy. Both are to be developed 
>as alternative solutions to the same problem (at least for the moment)
>
Thanks for clearing that up. It seems strange that so many features
of both modules indent to do the same thing.

>>   How do I stop using the fix_nated_sdp() function from nathelper?
>>   Is there such a function in the nat_traversal module, or is there
>> another way to achieve the same thing without using nathelper?
>>
>nat_traversal module provides support only for signalling part (afaik) 
>and not for media/SDP part.  If you need the functionality of 
>fix_nated_sdp(), you need nathelper module.
>
Okay, I'll go back to using the nathelper module. The mediaproxy and
rtpproxy components don't interest me at all, though.

Greetings,
Brian

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

Re: [OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello Bogdan,

An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> Here's a record I see when I run 'opensipsctl ul show':
>>
>> AOR:: mylogin-osips
>> Contact:: 
>> sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1
>> Expires:: 560
>> Callid:: 2b21cdfae784-av13rj1txbsq
>> Cseq:: 2
>> User-agent:: Bigphone123
>> Received:: sip:85.182.68.45:2240;transport=TLS
>> State:: CS_SYNC
>> Flags:: 0
>> Cflag:: 64
>> Socket:: tls:80.200.123.45:5061
>> Methods:: 7999
>>
>> OpenSIPS is trying to reach the private IP number above from time
>> to time, and I see this in the logs:
>>
>>   Jan 19 17:57:20 name.host.tld  opensips[23432]: ERROR:tm:t_uac: 
>> attempt to send to 
>> 'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed
>>
>> Thanks for any advice on correcting the failed private IP attempts.
>>
>the problem is not the private IP in the contact, as opensips properly 
>saved the source IP (of the REGISTER) too -> see the Received field. So 
>the Received field will be used over the Contact for sending the 
>requests to UAC.
>
Yes, that's what was confusing me, that the Received header was
correct and the TCP connection still failed.

>Now, what probably goes wrong in your case is that when using TLS/TCP 
>(connection oriented protos), after the REGISTER, the connection is 
>dropped and opensips cannot open later a TCP connection behind a NAT 
>:(By default opensips closes the inactive TCP connections.
>
>To make opensips to keep the connection (even with no traffic going on), 
>see the tcp_persistent_flag:
>
>http://www.opensips.org/html/docs/modules/devel/registrar.html#id228181
>
Good guess, but sadly your're wrong. I'm well informed of
manipulating the TCP connection using the tcp_persistent_flag. It
just wasn't where you expected it (and didn't appear in my email.)
The tcp_persistent_flag is being set on all registrations just
before save().

When I use tcpdump to see which address OpenSIPS is trying to
connect to before reporting the failure above, I see that it
really is trying to connect to 192.168.0.31 (over the Internet.)

If I write fix_contact() just before save() then this behaviour
and the failure goes away. It would seem that a lookup("location")
does not always use the AOR's Received header, or what do you think
could be the problem?

It doesn't seem right changing the AOR's contact string to hack this
problem away.

Greetings,
Brian

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

Re: [OpenSIPS-Users] do_routing() sending several invites per call

[opensipslist]

Hello Magnus,

An mer., janv 20, 2010, Magnus Burman schrieb:
>What happend was that do_routing in secret makes a call to route[1]
>before overwriting RURI. I changed all references to route[1] to
>route[111] instead (%s/route(1)/route(111)/g) and modified route[1]
>to do in essence nothing.  Below is the new code as well as the
>syslog. Calls are now forwarded correctly, but it worries me that
>route[1] is still called somehow, without *any* references to it
>anywhere in the config file.
>
That's crazy. You mean calling do_routing() really has a hardcoded
call to route[1]? That pretty much means, either you have a route[1]
or use the drouting module, but not both -> lest the routing script
be somewhat undefined.

This seems like a bug. If do_routing needs to set up a temporary
route block and call into it, then it should at least first check
if one of that name exists in the admin's routing script.

Regards,
Brian

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

Re: [OpenSIPS-Users] Which SIP messages to challange for authentication

[opensipslist]

Hello Iñaki,

An mer., janv 20, 2010, Iñaki Baz Castillo schrieb:
>El Miércoles, 20 de Enero de 2010, opensipsl...@encambio.com escribió:
>> An mer., janv 20, 2010, Iñaki Baz Castillo schrieb:
>>>El Miércoles, 20 de Enero de 2010, opensipsl...@encambio.com escribió:
 I know that strategies differ according to security needs but...

   Which SIP messages are typically challenged for authentication?

>>>In the case of dialogs (INVITE, SUBSCRIBE) it's typically just
>>>required to chanllenge the initial request forming such dialog
>>>(initial INVITE, initial SUBSCRIBE). The rest of requests in-dialog
>>>contain to_tag so usually it's not
>>>needed to authenticate them.
>>
>> Good point. I think I'll change the route script to only challange
>> initial requests. I guess a simple
>>
>> if (!has_totag()) {
>> if (!aaa_proxy_authorize("")) {
>> proxy_challenge("", "1");
>> exit;
>> }
>> if (!db_check_from()) {
>> xlog("L_WARN", "$rm: Cheating attempt\n");
>> send_reply("403", "Forbidden");
>> exit;
>> }
>> consume_credentials();
>> # caller authenticated
>> }
>>
>> ...near the top of the route script would do the job nicely. Is
>> this what you mean in your advice?
>
>Yes, but take into account that REGISTER doesn't use
>proxy_authorize but www_authorize.
>
Thanks for the reminder and for the generally good advice.

Regards,
Brian

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

Re: [OpenSIPS-Users] Which SIP messages to challange for authentication?

[opensipslist]

An mer., janv 20, 2010, Iñaki Baz Castillo schrieb:
>El Miércoles, 20 de Enero de 2010, opensipsl...@encambio.com escribió:
>> I know that strategies differ according to security needs but...
>>
>>   Which SIP messages are typically challenged for authentication?
>>
>> Right now we're challenging INVITE, SUBSCRIBE, and NOTIFY, although
>> it's not clear to me if challenging SUBSCRIBE or NOTIFY is useful.
>>
>> Of course ACK and BYE are not challenged, but then there are others
>> like MESSAGE, INFO, OPTION... whatever. This falls in the gray zone
>> as far as my understanding of SIP and security go.
>
>If you don't challange an *initial* request for authentication then
>the identity could be spoofed.
>
>In the case of dialogs (INVITE, SUBSCRIBE) it's typically just
>required to chanllenge the initial request forming such dialog
>(initial INVITE, initial SUBSCRIBE). The rest of requests in-dialog
>contain to_tag so usually it's not 
>needed to authenticate them.
>
Good point. I think I'll change the route script to only challange
initial requests. I guess a simple

if (!has_totag()) {
if (!aaa_proxy_authorize("")) {
proxy_challenge("", "1");
exit;
}
if (!db_check_from()) {
xlog("L_WARN", "$rm: Cheating attempt\n");
send_reply("403", "Forbidden");
exit;
}
consume_credentials();
# caller authenticated
}

...near the top of the route script would do the job nicely. Is
this what you mean in your advice?

Brian

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

[OpenSIPS-Users] Which SIP messages to challange for authentication?

[opensipslist]

Hello list,

I know that strategies differ according to security needs but...

  Which SIP messages are typically challenged for authentication?

Right now we're challenging INVITE, SUBSCRIBE, and NOTIFY, although
it's not clear to me if challenging SUBSCRIBE or NOTIFY is useful.

Of course ACK and BYE are not challenged, but then there are others
like MESSAGE, INFO, OPTION... whatever. This falls in the gray zone
as far as my understanding of SIP and security go.

Regards,
Brian

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

[OpenSIPS-Users] Nat_traversal version of fix_nated_sdp()

[opensipslist]

Hello list,

It's confusing that there are two nat traversal modules, and I don't
know which one to use. I'd rather use one or the other but not both.

Because nat_traversal is newer and seems to be where most of the NAT
logic will be developed in the future, it seems the natural choice.
If I'm right about that, then my question is:

  How do I stop using the fix_nated_sdp() function from nathelper?
  Is there such a function in the nat_traversal module, or is there
another way to achieve the same thing without using nathelper?

Greetings,
Brian

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

[OpenSIPS-Users] Private IP in registered AOR causing failure

[opensipslist]

Hello list,

Here's a record I see when I run 'opensipsctl ul show':

AOR:: mylogin-osips
Contact:: 
sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1
Expires:: 560
Callid:: 2b21cdfae784-av13rj1txbsq
Cseq:: 2
User-agent:: Bigphone123
Received:: sip:85.182.68.45:2240;transport=TLS
State:: CS_SYNC
Flags:: 0
Cflag:: 64
Socket:: tls:80.200.123.45:5061
Methods:: 7999

As you see it is quite normal, but I'm wondering about the private
IP 192.168.0.31. That's indeed the address of the phone.

OpenSIPS is trying to reach the private IP number above from time
to time, and I see this in the logs:

  Jan 19 17:57:20 name.host.tld  opensips[23432]: ERROR:tm:t_uac: 
attempt to send to 
'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed

The part of my config which could be causing this problem is:

# configure NAT keepalives
if (client_nat_test("3")) {
if (method=="SUBSCRIBE") {
nat_keepalive();
}
if (!has_totag()) {
if (method=="REGISTER") {
$avp(s:regrcv) = $source_uri;
fix_nated_register();  # add Received header
if (proto==UDP) {
nat_keepalive();
}
}
else if (!is_present_hf("Record-Route")) {
#fix_nated_contact();
fix_contact();
force_rport();
if (is_method("INVITE")) {
fix_nated_sdp("3");
}
}
}
setbflag(6);# mark message as NATed
}

Thanks for any advice on correcting the failed private IP attempts.

Greetings,
Brian

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

Re: [OpenSIPS-Users] Dialog module and uac_auth

[opensipslist]

Hello Bogdan,

An jeu., déc 24, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> A while ago it was clear that uac_auth is of limited utility,
>> due to the SIP RFC which requires that each message has a unique
>> cseq. Calling uac_auth from failure_route produced a new INVITE
>> with a proxy-auth header that didn't have a new cseq however.
>>
>> Since the dialog module appeared, I'm wondering how if scripts
>> can be tweaked to use uac_auth in a SIP RFC compliant way.
>>
>> ...or is it still true that doing uac_auth() in failure_route
>> fills in the proxy-auth header of a INVITE message that has
>> already expired its cseq (no longer valid in the dialog)?
>>
>The limitation is still true - even with the dialog support, the
>dialog can be monitored, but not changed - changing the CSEQ will
>affect the dialog for its whole lifetime , requiring opensips to
>constantly update the cseq in all sequential requeststhis is
>more than the dialog module was designed for :)
>
So I suppose you're saying that the only way to use uac_auth is
to send two INVITEs, one without auth credentials followed by
on with the proper auth credentials... but without an increased
cseq number.

For what is that valuable at all (I thought that OpenSIPS tries
to be as RFC compliant as possible?) I have the feeling that I'm
not 'getting it' or using uac_correctly, in a way that the cseq
numbers are not relevant.

I'm trying to authenticate a UAC phone with a third party SIP to
PSTN gateway, while having OpenSIPS in between. The gateway rejects
repeated INVITEs with the same cseq number. The situation is quite
typical, so I'm sure that OpenSIPS provides a way to solve this
problem, no?

>> How can uac_auth be used with INVITE messages in a SIP RFC
>> compliant way?
>>
Any ideas or is this frequent situation really impossible to handle?

Regards,
Brian

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

[OpenSIPS-Users] Help with the dialog module please

[opensipslist]

Hello list,

Does the dialog module define a dialog as from the:

  First INVITE that appears with Call-ID '1234'

...or

  Second INVITE that appears with Call-ID '1234'

I'm asking because if a unauthenticated INVITE arrives the sending
UAC will be forced to send a second INVITE (with a new cseq) that
includes authentication credentials. If the second INVITE with its
auth credentials is accepted, then I assume that the dialog begins.
It therefore follows that the first INVITE will not be included in
the dialog modules table of dialogs, and will be ignored in the
dialog context. Is that right?

What I'm trying to do is set_dlg_flag("20") in the first INVITE and
then read is_dlg_flag_set("20") in the next one. It would be
convenient if the first INVITE began the dialog and the second
INVITE was considered part of the dialog as well. Is this possible?

Can I change some SIP header of the second INVITE to match the
first, so that the dialog module believes them both to be in the
same dialog?

Another question, is there any difference between:

modparam("dialog", "dlg_flag", 4)
route {
setflag(4);
}

...and

route {
create_dialog();
}

Are they completely interchangeable? Does this make sense:

modparam("dialog", "dlg_flag", 4)
route {
setflag(4);
create_dialog();
}

Thanks,
Brian

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

Re: [OpenSIPS-Users] Opensips 1.6.1 dos not start on Ubuntu 9.1 64bits

[opensipslist]

Hello Antonio,

An mer., déc 23, 2009, Antonio Anderson M. de Souza schrieb:
>I've installed the Opensips 1.6.1 on my Ubuntu 9.10 64bits form the
>source, the installation was done without any problem.
>
>Opensips abnormally stops during the initialization of Dialplan
>module (follows logs bellow)
>
>Dec 23 13:38:30 asouza-laptop opensips[7233]: NOTICE:core:main: version: 
>opensips 1.6.0-notls (x86_64/linux)
>[...]
>Dec 23 13:38:30 asouza-laptop opensips[7233]: 
>WARNING:permissions:parse_config_file: file not found: 
>/usr/local/etc/opensips/permissions.allow
>[...]
>*Dec 23 13:38:30 asouza-laptop opensips[7233]: INFO:dialplan:mod_init: 
>initializing module...*
>
>The bold line is the last line before the process terminates, but
>there are no error in the initialization process.
>
>Does somebody has some clue about thie problem?
>
What happens if you don't use the dialplan, does the process still
terminate in the same place?

And is the string '1.6.0' an error in your logs or are you sure that
you've compiled the latest release (1.6.1)? I seem to remember that
the debian unstable repository had a problem with version numbers
for a day or so, maybe you really are using the latest release.

Lastly (but probably unimportant) you might first get rid of the
warning message. If you are using the permissions module then
configure it correctly by placing the file 'permissions.allow'
where OpenSIPS expects it.

Regards,
Brian

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

Re: [OpenSIPS-Users] Disabling TCP or UDP (RFC forbidden)

[opensipslist]

Hello Samuel,

An mer., déc 23, 2009, samuel schrieb:
>TCP is very resource demanding and for those situations where the
>server is not required to work with TCP is very usefull to have the
>option of disabling TCP part.
>
>There are examples, such as embedded platforms with controlled SIP
>UA connecting to it where there's no need for TCP stuff and lots of
>resources are available for other processes.
>
>Not much related to RFCs...
>
Normally the RFC standardization process considers such topics as
'how practical a protocol will be in the network landscape.' No idea
why they wrote 'MUST' and not 'SHOULD' for the parts of implementing
the SIP protocol over both UDP and TCP.

Anyway, I'm guessing that the core OpenSIPS developers (are you
one?) have chosen their policy based on your logic. I don't see
the reason however, that if they're willing to forego the RFC
recommendation for TCP that they shouldn't do the same for UDP.
That would at least be more intuitive.

Regards,
Brian

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

[OpenSIPS-Users] Dialog module and uac_auth

[opensipslist]

Hello list,

A while ago it was clear that uac_auth is of limited utility,
due to the SIP RFC which requires that each message has a unique
cseq. Calling uac_auth from failure_route produced a new INVITE
with a proxy-auth header that didn't have a new cseq however.

Since the dialog module appeared, I'm wondering how if scripts
can be tweaked to use uac_auth in a SIP RFC compliant way.

...or is it still true that doing uac_auth() in failure_route fills
in the proxy-auth header of a INVITE message that has already
expired its cseq (no longer valid in the dialog)?

How can uac_auth be used with INVITE messages in a SIP RFC compliant
way?

Regards,
Brian

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

Re: [OpenSIPS-Users] Reducing INVITE delay until UAC sees 180 RINGING

[opensipslist]

Hello osiris123d,

An mar., déc 22, 2009, osiris123d schrieb:
>If you are using TLS and you would like to sniff capture data you
>can use Wireshark.  With Wireshark you can import your TLS
>certificate and the encrypted data will be decrypted.
>
>Hope that helps one of your problems.
>
Yes, I didn't know that since I usually use tcpdump alone. Thanks.

Brian

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

Re: [OpenSIPS-Users] Gw module or dispatch authentication?

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> Has anyone had this problem of wanting to forward a INVITE to
>> a PSTN gateway, and not being able to authenticate?
>>
>> Is carrierroute really what should be used in this case, or some
>> combination of modules... maybe uac for the authentication?
>>
>Take a look at the UAC module - it can do user auth -
>http://www.opensips.org/html/docs/modules/devel/uac.html
>
>you can use the attr field in the drouting module to store the
>username and password required by that GW and dynamically inject
>them into UAC.
>
Neiter online nor distribution documents mention this 'attr' field:
 
  http://www.opensips.org/html/docs/modules/devel/drouting.html
  opensips-1.6.1-tls.orig/modules/drouting/README

...but I believe you that it is just what is needed.

Another problem is that unlike the gw table, the dr_gateways table
doesn't provide a column for the host port number. Before you say
'just tack it on the address field with a : between them', please
note that this would not be compatible with db_text tables which
interpret the ':' as a field separator. This means the 'Table 1.2.
Sample dr_gateways records' in the docs mentioned above are flawed.

With 'dynamically inject them into UAC' I suppose you mean something
similar to:

  modparam("uac","auth_realm_avp","$avp(s:realm)")
  modparam("uac","auth_username_avp","$avp(s:user)")
  modparam("uac","auth_password_avp","$avp(s:pass)")
  modparam("drouting", "attrs_avp", "$avp(dr_attrs)")
  route {
  do_routing();
  $avp(s:user) = $avp(dr_attrs);  # avp parsing needed
  $avp(s:pass) = $avp(dr_attrs);  # avp parsing needed
  uac_auth();
  }

Is that the general idea?

Regards,
Brian

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

Re: [OpenSIPS-Users] Reducing INVITE delay until UAC sees 180 RINGING

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>First of all you should really try to see where the delay comes from: 
>make a trace with time stamps and see if the delay is because of INVITE 
>processing (time diff between inbound and outbound INVITE), because of 
>the callee reply (time diff between outbound INVITE and inbound 180 
>reply)...etc...
>
Yes that is my plan. There are just a few problems:

  - A tcpdump reveals no plaintext, as TLS is used
  * The sip_trace is not written because db_text only writes UDP
  Time stamps among all UACs and the OpenSIPS proxy must match

...so I'm trying to solve these things one by one before doing the
fine grained time delay analysis.

* Not sure why db_text is not writing files. A truss dump (with
OpenSIPS running unforked) shows that the table files are being
opened read only. I think this is normal because on startup their
table headers are read in. However, the truss dump never includes
another open (neither RO nor RW.) Still trying to debug this.

>Once we find the delay point, we can see why.
>
Thanks.

Regards,
Brian

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

Re: [OpenSIPS-Users] Reducing INVITE delay until UAC sees 180 RINGING

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An ven., déc 18, 2009, opensipsl...@encambio.com schrieb:
>>> I'm assuming that a delay of 1 second is reachable through config
>>> tuning, and wondering as well what kind of result (in terms of delay
>>> time) the maximum tuning yields. Already I've looked at things like:
>>>
>>>  disable_dns_blacklist
>>>  disable_dns_failover
>>>
>>> ...because DNS resolutions is a logical place to start reducing.
>>>
>>> Any ideas? Is there documentation about this?
>>>
>> The OpenSIPS documentation is excellent of course, but sadly lacking
>> information about such core parameters as those above and 'rev_dns'
>> relating to when and how often they effect performance. For example,
>> does 'rev_dns = yes' mean that a reverse lookup takes place once at
>> startup, every time the route script is entered, once a new
>> transaction begins, dialog...
>>
>rev_dns affects two scenarios:
>- comparisons with domains in script ( like src_ip=="foo.bar") -
>reverse DNS will be done on foo.bar
>- internal checks of IPs against SIP uri / SIP hosts (like checking
>for VIA matching, for src IP nat, etc)
>
>Shortly, if when doing IP versus IP/domain checks, if reverse DNS
>should be done if "domain"
>
That seems rather expensive, resolving all but what is necessary as
the script is running for each incoming message. I guess that's why
it is disactivated by default.

I'll keep trying to find the sticking points leading to several
seconds of delay before 180 ringing. The alias table is db_text,
so maybe that is what is so slow. No enum is looked up.

Regards,
Brian

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

Re: [OpenSIPS-Users] Trying to learn how to use siptrace

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An jeu., déc 17, 2009, Bogdan-Andrei Iancu schrieb:
>> Then if I have one UAC (PhoneA) and the proxy (OsipsA) and want
>> to trace all messages between them, it seems that the best way is:
>>
>>   # Example 1
>>   route{
>> sip_trace();
>> [...]
>>   }
>>
>> But to to avoid REGISTER, SUBSCRIBE, and ACK messages, then it seems
>> best to set the trace flag. How do you do this appropriately, and
>> how to avoid calling setflag more than once per transaction? Maybe
>> something like:
>>
>>   # Example 2
>>   route{
>> [...]
>> if (loose_route())  # Not sure here ?!?
>>   setflag(22);
>> [...]
>>   }
>>
>> It seems in the context described above it makes no difference
>> if I use setflag, setbflag, or setsflag, right?
>>
>> Lastly, it seems that one can get a similar result as example 2
>> above by doing:
>>
>>   # Example 3
>>   route{
>> [...]
>> if (is_method("INVITE") && !has_totag())
>>   trace_dialog();
>> [...]
>>   }
>>
>> ...just that in this case I will see the ACK messages as well.
>>
>The siptrace module require you to set a message/transaction
>flag (for forcing the siptracing for a transaction) (see 
>http://www.opensips.org/Resources/DocsCoreFlags16)
>
Okay the setflag(trace) is required for transactions. I understand
that it is not required to trace a single message, where sip_trace()
will do the job just fine on its own.

>In the route{} which is a request route, you get only requests,
>so you cannot trace replies there - the simple solution is to do
>sip_trace + setflag(trace) and (using t_relay()) you should get
>traced all traffic.
>
In comparison with sip_trace + setflag(trace), what would be missing
for the trace log if only setflag(trace) is used? I'm using t_relay.

And if both sip_trace + setflag(trace) are used, will some messages
appear twice in the trace log?

Sadly, right now I can't test these things because my db_text is not
working correctly (it only writes on UDP connections.)

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>> opensipsl...@encambio.com wrote:
>> You may try to increase the number of tries to something higher -
>> 3200, just to see if that is the problem:
>>
>>see tls/tls_server.c , line 689
>>   #define MAX_SSL_RETRIES 320
>>   
>> By the way, even when MAX_SSL_RETRIES is set to almost infinity, the
>> same errors reappear when lowering the number of child processes.
>> This could be a clue for whoever decides to look into this bug.
>>
>> In the current state of development, it seems the workaround is:
>>
>>   Increase MAX_SSL_RETRIES to almost infinity
>>   Increase tcp_children to the number of UACs (not scalable)
>>   Log how many SSL retries are really needed until success
>>   Lower MAX_SSL_RETRIES from almost infinity to what is needed
>>
>> Does that sound right? Is this acceptable as far as scalability goes?
>>
>This is something interesting - can you open a bug report on the tracker 
>- just to keep a history of the report and of the troubleshooting:
>
>  http://www.opensips.org/Development/Tracker
>
>What is strange is that we are using also TLS and never bumped into this 
>problem.
>
Okay, let me just make sure I can reproduce the same errors under
1.6.1, and then I'll write the bug report.

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send to UDP UACs

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>>> the t_relay() function does server location discovery via DNS (for
>>> domain voip.host.tld ).
>>>
>>> Based on NAPTR and SRV records, a TLS destination is chosen (this
>>> selection also depends on the RURI - like if a specific SIP schema
>>> is required, etc).
>>>
>>> So, your problem is why TLS was chosen or why TLS write failed ?
>>> 
>> Your explanation sounds reasonable. The problem is that TLS writes
>> and sometimes even reads are failing. I wrote about the NAPTR and
>> SRV records, because I suspected that OpenSIPS was sending TCP
>> (unencrypted) commands to a TLS connection or vise versa.
>>   
>I doubt it - you can check via tcpdump to see if traffic in
>encrypted or not.
>
A tcpdump is running right now, but I think you're right that
there is no mismatch. Maybe the dump will show something else.

>> You mentioned in another email that this could be NAT related and
>> I agree. It seems that you don't think there is some mismatch
>> between TCP and TLS, maybe involving the NAPTR and SRV records.
>>
>That is correct.
>
Okay then I'll forget about NAPTR and SRV and focus on debugging
NAT instead, thanks.

 The same config worked well with OpenSER 1.3.X. Only when migrating
 to 1.6.0 do we see these errors. What could have changed?

>> But this is maybe a clue. It would seem that something in TLS
>> writing has changed between these two versions, maybe fundementally?
>>   
>1.3 was doing infinite loop (for write and read), leading sometime to 
>blocking.
>
That was a painful part of 1.3, so good that the counter is there
now. I guess you're saying that the same TLS problems existed in
1.3 as well, but they were masked by retries (maybe thousands.)

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>> opensipsl...@encambio.com wrote:
> One solution fixed both errors (assuming there really were two
> different erros) as you see below.
> 
 Whoops I spoke too soon. It seems that patching MAX_SSL_RETRIES only
 fixed the 'tls_blocking_write' error. Now I still have in the log:

ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
ERROR:core:tcpconn_connect: tcp_blocking_connect failed
ERROR:core:tcp_send: connect failed
ERROR:tm:msg_send: tcp_send failed
ERROR:tm:t_forward_nonack: sending request failed
   
>>> I guess you are trying to connect to some destination which is not
>>> listening - check with tcpdump where opensips tries to open the TCP
>>> connection and see if there is a really app listening there.
>>> 
>> Seems reasonable, so I'll take your advise and start debugging with
>> tcpdump. My guess is that there is some NAT problem and/or faulty IP
>> number substitution in SDP (a config error basically.) The strange
>> thing is that the same config was being used with OpenSER 1.3.X and
>> these errors did not appear.
>>
>> I'll start tcpdump and report what I find.
>>   
>For sure it is after the lookup() and opensips tries to open a 
>connection somwhere behind a NAT (where a TLS phone is located).
>
That would seem right, but in my case I'm handling NAT correctly:

if (client_nat_test("3")) {
if (method=="SUBSCRIBE")
nat_keepalive();
if (!has_totag()) {
if (method=="REGISTER") {
if (proto==UDP)
nat_keepalive();
else
setflag(7);  # tcp_persistent
#Try as well force_tcp_alias();  # reuse port
$avp(s:regrcv) = $source_uri;
fix_nated_register();  # add Received header
}
else if (method=="INVITE") {
nat_keepalive();
fix_nated_sdp("3");
}
}
}

...which means that lookup is most likely reporting a valid TLS/TCP
connection which is both open and still in the NAT table of the IP
router. Have I missed something there?

Another idea is that SUBSCRIBEs or NOTIFYs are causing the TLS
errors. I don't know if 'nat_keepalive' works on TCP/TLS or if
OpenSIPS is able to reuse the TLS connection stored in usrloc for
non INVITE messages.

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send to UDP UACs

[opensipslist]

Hello Bogdan,

An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> PROBLEM
>> ---
>>
>> Registrations work well, but when sending IVITEs I see this in log:
>>
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: 
>> ERROR:core:tls_blocking_write: too many retries with no operation
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:core:tcp_send: 
>> after write: c= ceb903f0 n=-1 fd=18
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:core:tcp_send: 
>> buf=
>>   INVITE sips:per...@voip.host.tld SIP/2.0^M
>>   Record-Route: 
>> ^M
>>   Via: SIP/2.0/TLS 211.123.22.12:5061;branch=z9hG4bK4d6.913.0;i=2^M
>>   Via: SIP/2.0/TLS 
>> 192.168.1.12:3352;received=125.81.6.152;branch=z9hG4bK-pt7eil3u8qci;rport=3352^M
>>   [...]
>>   Content-Type: application/sdp^M
>>   ^...@dec 10 15:55:18 name.host.tld  opensips[10848]: 
>> ERROR:core:tcp_send: failed to send
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: ERROR:tm:msg_send: 
>> tcp_send failed
>>   Dec 10 15:55:18 name.host.tld  opensips[10850]: 
>> DBG:core:handle_ser_child: read response= ceb903f0, -2, fd -1 from 6 (10848)
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: 
>> ERROR:tm:t_forward_nonack: sending request failed
>>   Dec 10 15:55:18 name.host.tld  opensips[10850]: 
>> DBG:core:io_watch_del: io_watch_del (82d10c0, 21, -1, 0x10) fd_no=11 called
>>   Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:tm:t_relay_to: 
>> t_forward_nonack returned error
>>
>> The forward (I assume by t_relay()) is failing. Is it because a SRV
>> lookup is being done and finding that raw SIP over TCP is being sent
>> to the OpenSIPS TLS listener? Should I be using something other than
>> t_relay() in the config?
>>
>the t_relay() function does server location discovery via DNS (for
>domain voip.host.tld ).
>
>Based on NAPTR and SRV records, a TLS destination is chosen (this
>selection also depends on the RURI - like if a specific SIP schema
>is required, etc).
>
>So, your problem is why TLS was chosen or why TLS write failed ?
>
Your explanation sounds reasonable. The problem is that TLS writes
and sometimes even reads are failing. I wrote about the NAPTR and
SRV records, because I suspected that OpenSIPS was sending TCP
(unencrypted) commands to a TLS connection or vise versa.

You mentioned in another email that this could be NAT related and
I agree. It seems that you don't think there is some mismatch
between TCP and TLS, maybe involving the NAPTR and SRV records.

>> The same config worked well with OpenSER 1.3.X. Only when migrating
>> to 1.6.0 do we see these errors. What could have changed?
>>
But this is maybe a clue. It would seem that something in TLS
writing has changed between these two versions, maybe fundementally?

Thanks,
Brian

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

[OpenSIPS-Users] Gw module or dispatch authentication?

[opensipslist]

Hello list,

Has anyone had this problem of wanting to forward a INVITE to a PSTN
gateway, and not being able to authenticate?

The UAC (A) sends the INVITE to a OpenSIPS proxy (B) who replies 401
Unauthorized. A sends B a new INVITE with A's credentials and B's
realm and nonce.

B forwards this INVITE to a gateway (C) who replies 401 Unauthorized.
At this point the OpenSIPS proxy must somehow (like a B2BUA?)
provide the gateway with authentication credentials.

The gw module is useful for this but fails to provide any means of
authenticating with the new gateway C.

I believe the dispatch module does something similar, but it's
unclear just what the docs mean by 'hashing' in this case. Where
is the dispatcher module taking the username and password from?

Is carrierroute really what should be used in this case, or some
combination of modules... maybe uac for the authentication?

Regards,
Brian

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

[OpenSIPS-Users] B2BUA not passing ACKs

[opensipslist]

Hello list,

It seems that in August 2008 as OpenSER forked, Bogdan announced a
priority list of next steps. It included:

  TCP+TLS rework of: blocking, scalability, nat traversal, performance

Does anybody know if work proceeded on the TLS blocking problems?

   opensips[7950]: ERROR:core:tcp_blocking_connect: timeout 10 s elapsed 
from 10 s
   opensips[7950]: ERROR:core:tcpconn_connect: tcp_blocking_connect 
failed
   opensips[7950]: ERROR:core:tcp_send: connect failed
   opensips[7950]: ERROR:tm:msg_send: tcp_send failed
   opensips[7950]: ERROR:tm:t_forward_nonack: sending request failed

Do these errors (in 1.6.0) reflect the priority as described by
Bogdan?

Regards,
Brian

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

[OpenSIPS-Users] B2BUA not passing ACKs

[opensipslist]

Hello list,

According to the example:

  http://www.opensips.org/Resources/B2buaTutorial#toc13

...implementing the prepaid service should handle INVITE, ACK, and
BYE. Strangely the XML file includes only the BYE scenario:

  
  
  

I don't know enough about the B2BUA modules to say for sure, but it
would seem that the online example is missing 'ACK' at least.

When I copy the XML code and config code 1:1, my B2BUA
implementation of the prepaid service sends the initial INVITE,
receives the OK, but as the UAC (caller in the diagram) sends the
ACK the B2B (green line in the diagram) does not pass it onto the
media server.

Is there a bug in the online XML code for the prepaid scenario?

Regards,
Brian

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

Re: [OpenSIPS-Users] shared memory

[opensipslist]

An dim., déc 20, 2009, Stanisław Pitucha schrieb:
>On 20.12.2009 03:22, Josip Djuricic wrote:
>> I am wondering about shared memory and childs...when you dedicate for
>> example 128mb shared memory to opensips on startup does that mean this 128mb
>> is shared between all of the childs or does it mean that every child gets
>> 128? Since it is not private I believe it's shared betwwen all of them?
>>
>There are two memory pools - shared and private (called 'shm' and 'pkg' 
>in the logs and code). On startup you can set only the shared memory - 
>and yes - it will get allocated only once, not per child.
>More info: http://www.opensips.org/Resources/DocsTsInm
>
How does one usually decide what to set the runtime shared memory
value to, and if one should even manipulate this value at all? What
are the typical cases, UDP listening versus UDP, TCP, and TLS
listening?

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello,

An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
 You may try to increase the number of tries to something higher -
 3200, just to see if that is the problem:

see tls/tls_server.c , line 689
   #define MAX_SSL_RETRIES 320

>>> This doesn't make sense to me. If 320 retries are attempted with no
>>> write op success, then trying 3200 can't be the solution. Rather, it
>>> must be that I have an error in the config script or some permission
>>> problem no?
>>>
>> Sadly, the only thing I could do to solve the problem was to
>> increase 320 as Bogdan suggested. I raised it to 3200, but
>> surely there is a lower 'cieling' that would work. It leaves
>> me with a somewhat sick feeling however, because this seems
>> very hacky and probably only masks the symptom and leaves
>> the real problem intact (which could surface again in some
>> other form.)
>>
>It is not really a hack :)  i tend to think this number vary from OS 
>to OS, from server to server .like how slow the write ops take place 
>- on some system is faster, on other is not.
>
By the way, even when MAX_SSL_RETRIES is set to almost infinity, the
same errors reappear when lowering the number of child processes.
This could be a clue for whoever decides to look into this bug.

In the current state of development, it seems the workaround is:

  Increase MAX_SSL_RETRIES to almost infinity
  Increase tcp_children to the number of UACs (not scalable)
  Log how many SSL retries are really needed until success
  Lower MAX_SSL_RETRIES from almost infinity to what is needed

Does that sound right? Is this acceptable as far as scalability goes?

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

[OpenSIPS-Users] Error 'tls_verify' in documentation

[opensipslist]

Hello list,

There is a documentation error, namely setting 'tls_verify' in the
config file leads to the following error:

  # /pfx/sbin/opensips
  CRITICAL:core:yyerror: parse error in config file, line 103, column 1-11: 
syntax error
  ERROR:core:main: bad config file

It seems that tls_verify is not a valid core parameter. The valid
TLS core parameters are 'tls_verify_client' and 'tls_verify_server'.
These errors appear in both the online documentation:

  http://www.opensips.org/Resources/DocsCoreFcn16#toc85

...as well as the most recent stable release 1.6.0 distribution:

  $ find opensips-1.6.0-tls.orig -exec grep 'tls_verify[^a-zA-Z_]' {} \; -print
  only if tls_verify is turned on)
  tls_verify=on
  opensips-1.6.0-tls.orig/tls/doc/tls_user.sgml
  if tls_verify is turned on)
  tls_verify=on
  opensips-1.6.0-tls.orig/tls/README

It might be an idea to correct that before the next release on Monday.

Regards,
Brian

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

Re: [OpenSIPS-Users] Reducing INVITE delay until UAC sees 180 RINGING

[opensipslist]

Hello list,

An ven., déc 18, 2009, opensipsl...@encambio.com schrieb:
>I'm assuming that a delay of 1 second is reachable through config
>tuning, and wondering as well what kind of result (in terms of delay
>time) the maximum tuning yields. Already I've looked at things like:
>
>  disable_dns_blacklist
>  disable_dns_failover
>
>...because DNS resolutions is a logical place to start reducing.
>
>Any ideas? Is there documentation about this?
>
The OpenSIPS documentation is excellent of course, but sadly lacking
information about such core parameters as those above and 'rev_dns'
relating to when and how often they effect performance. For example,
does 'rev_dns = yes' mean that a reverse lookup takes place once at
startup, every time the route script is entered, once a new
transaction begins, dialog...

There are a lot of parameters where it's not clear when and how
often they effect performance, or am I missing something?

Regards,
Brian

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

[OpenSIPS-Users] Reducing INVITE delay until UAC sees 180 RINGING

[opensipslist]

Hello list,

PROBLEM

With OpenSER 1.3.X we've always had a delay of a few seconds (at
least) between INVITE and RINGING on a quiet network and host with
good performance.

QUESTION

What are possible places in the config to tweak in order to minimize
such a delay, and how many seconds of delay do most of you experience
in your networks?

I'm assuming that a delay of 1 second is reachable through config
tuning, and wondering as well what kind of result (in terms of delay
time) the maximum tuning yields. Already I've looked at things like:

  disable_dns_blacklist
  disable_dns_failover

...because DNS resolutions is a logical place to start reducing.

Any ideas? Is there documentation about this?

Thanks,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

An ven., déc 18, 2009, opensipsl...@encambio.com schrieb:
>An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>maybe we should simply increase the default number to cover also
>>the slow cases.
>>
>I disagree. You said yourself that 'this number varies' so lets do
>what we always do with such variables, and put it in the config.
>
>PSEUDOCODE
>
>  disable_tls   = 0
>  tls_method= TLSv1
>  [...]
>  tls_maxretries= 3200  # New variable
>
>Its not nice of course always stuffing up the config and OpenSIPS
>architecture with new variables, but if there's no design based
>solution to this then it seems better that way than hard coding
>such runtime variable deep into the core.
>
...or in the configure script './configure --with-tlsmaxretries=3200'
if it really must continue to be a build time variable.

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello Bogdan,

An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>>> One solution fixed both errors (assuming there really were two
>>> different erros) as you see below.
>>>
>> Whoops I spoke too soon. It seems that patching MAX_SSL_RETRIES only
>> fixed the 'tls_blocking_write' error. Now I still have in the log:
>>
>>ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
>>ERROR:core:tcpconn_connect: tcp_blocking_connect failed
>>ERROR:core:tcp_send: connect failed
>>ERROR:tm:msg_send: tcp_send failed
>>ERROR:tm:t_forward_nonack: sending request failed
>>
>I guess you are trying to connect to some destination which is not
>listening - check with tcpdump where opensips tries to open the TCP
>connection and see if there is a really app listening there.
>
Seems reasonable, so I'll take your advise and start debugging with
tcpdump. My guess is that there is some NAT problem and/or faulty IP
number substitution in SDP (a config error basically.) The strange
thing is that the same config was being used with OpenSER 1.3.X and
these errors did not appear.

I'll start tcpdump and report what I find.

Thanks,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello Bogdan,

An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>It is not really a hack :)  i tend to think this number vary
>from OS to OS, from server to server .like how slow the write
>ops take place - on some system is faster, on other is not.
>
What I'm not understanding is the basic principle, why even a single
retry is needed. I can imagine that with a slightly different design
the topic of 'guessing' the right retry ceiling is completely
unnecessary. Do you understand more about these TLS retries,
and does it have to do with TCP primarily or code in the OpenSSL
libraries?

>maybe we should simply increase the default number to cover also
>the slow cases.
>
I disagree. You said yourself that 'this number varies' so lets do
what we always do with such variables, and put it in the config.

PSEUDOCODE

  disable_tls   = 0
  tls_method= TLSv1
  [...]
  tls_maxretries= 3200  # New variable

Its not nice of course always stuffing up the config and OpenSIPS
architecture with new variables, but if there's no design based
solution to this then it seems better that way than hard coding
such runtime variable deep into the core.

Regards,
Michael

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello,

An ven., déc  18, 2009, opensipsl...@encambio.com schrieb:
>An jeu., déc 17, 2009, opensipsl...@encambio.com schrieb:
>>An jeu., déc 17, 2009, Bogdan-Andrei Iancu schrieb:
>>>opensipsl...@encambio.com wrote:
 REGISTER messages seem to be handled correctly, but I'm still having
 troubles with INVITEs:

   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
 ERROR:core:tls_blocking_write: too many retries with no operation
   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
 ERROR:core:tcp_send: failed to send
   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
 ERROR:tm:msg_send: tcp_send failed
   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
 ERROR:tm:t_forward_nonack: sending request failed
   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
 ERROR:core:tls_accept: some error in SSL (ret=0, err=5, errno=0/Error 0):

>>>Actually you have two errors there - one on a write op and another
>>>one on an accept op.
>>>
>One solution fixed both errors (assuming there really were two
>different erros) as you see below.
>
Whoops I spoke too soon. It seems that patching MAX_SSL_RETRIES only
fixed the 'tls_blocking_write' error. Now I still have in the log:

   ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
   ERROR:core:tcpconn_connect: tcp_blocking_connect failed
   ERROR:core:tcp_send: connect failed
   ERROR:tm:msg_send: tcp_send failed
   ERROR:tm:t_forward_nonack: sending request failed

Is there something I should try in order to get rid of the new
errors, maybe setting:

  tcp_send_timeout
  tcp_connect_timeout
  tcp_connection_lifetime
  tcp_max_connections
  tcp_poll_method
  tls_handshake_timeout
  tls_send_timeout

...just asking before I go on a wild goose chase to find some
solution (even if it is a hack.)

Thanks,
Brian

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

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

Hello,

An ven., déc 18, 2009, opensipsl...@encambio.com schrieb:
>An lun., déc 14, 2009, Stanisław PITUCHA schrieb:
>>2009/12/14 Jeff Pyle :
>>> I'm trying to determine the "proper" number of opensips children for my
>>> setup.
>>
>Me too.
>
>>Unless you supply telephony to everyone in a small city, it will be
>>below 32 ;)
>>
>Okay, I've decided to start low and increase the children as soon as
>I notice performance problems. Is this a good strategy to learn how
>many children you need?
>
>I turn off TCP completly and set children to the lowest value:
>
>  listen=udp:name.host.tld:5060
>  #listen=tls:name.host.tld:5061
>  #disable_tls = 1
>  children = 1
>  #tcp_children = 1
>  fork = yes
>
>...look at this:
>
>  # ps -ef | grep opensips
>  osuser 17127 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17131 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17128 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17132 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17125 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17130 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  osuser 17129 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>
>Okay I understand that one of them is the master process and that I
>should expect an additional process due to the forking (fork=yes),
>but why are there 7 (!) processes being spawned? I do have SRV and
>NAPTR records in DNS, can it be due to them?
>
I don't have any IP address aliases in the config, and the platform:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS

Thanks,
Brian

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

Re: [OpenSIPS-Users] number of opensips children

[opensipslist]

Hello,

An lun., déc 14, 2009, Stanisław PITUCHA schrieb:
>2009/12/14 Jeff Pyle :
>> I'm trying to determine the "proper" number of opensips children for my
>> setup.
>
Me too.

>Unless you supply telephony to everyone in a small city, it will be
>below 32 ;)
>
Okay, I've decided to start low and increase the children as soon as
I notice performance problems. Is this a good strategy to learn how
many children you need?

I turn off TCP completly and set children to the lowest value:

  listen=udp:name.host.tld:5060
  #listen=tls:name.host.tld:5061
  #disable_tls = 1
  children = 1
  #tcp_children = 1
  fork = yes

...look at this:

  # ps -ef | grep opensips
  osuser 17127 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17131 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17128 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17132 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17125 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17130 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
  osuser 17129 0:00 /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid

Okay I understand that one of them is the master process and that I
should expect an additional process due to the forking (fork=yes),
but why are there 7 (!) processes being spawned? I do have SRV and
NAPTR records in DNS, can it be due to them?

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello again,

An jeu., déc 17, 2009, opensipsl...@encambio.com schrieb:
>An jeu., déc 17, 2009, Bogdan-Andrei Iancu schrieb:
>>opensipsl...@encambio.com wrote:
>>> REGISTER messages seem to be handled correctly, but I'm still having
>>> troubles with INVITEs:
>>>
>>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>>> ERROR:core:tls_blocking_write: too many retries with no operation
>>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>>> ERROR:core:tcp_send: failed to send
>>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:tm:msg_send: 
>>> tcp_send failed
>>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>>> ERROR:tm:t_forward_nonack: sending request failed
>>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>>> ERROR:core:tls_accept: some error in SSL (ret=0, err=5, errno=0/Error 0):
>>>
>>Actually you have two errors there - one on a write op and another
>>one on an accept op.
>>
One solution fixed both errors (assuming there really were two
different erros) as you see below.

>>You may try to increase the number of tries to something higher -
>>3200, just to see if that is the problem:
>>
>>see tls/tls_server.c , line 689
>>   #define MAX_SSL_RETRIES 320
>>
>This doesn't make sense to me. If 320 retries are attempted with no
>write op success, then trying 3200 can't be the solution. Rather, it
>must be that I have an error in the config script or some permission
>problem no?
>
Sadly, the only thing I could do to solve the problem was to
increase 320 as Bogdan suggested. I raised it to 3200, but
surely there is a lower 'cieling' that would work. It leaves
me with a somewhat sick feeling however, because this seems
very hacky and probably only masks the symptom and leaves
the real problem intact (which could surface again in some
other form.)

Others have reported problems with the same tls_blocking_write
code, but as far as I know the problem has not been looked into.

Regards,
Michael

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

Re: [OpenSIPS-Users] Trying to learn how to use siptrace

[opensipslist]

Hello Bogdan,

An jeu., déc 17, 2009, Bogdan-Andrei Iancu schrieb:
>sip_trace() function will siptrace the current SIP message
>
>   + setting the trace flag (like setflag(22) ) will trace all the
>messages related to the transaction created by the current request you
>process
>
>trace_dialog() works only for call - use it for initials INVITEs and it
>will trace the whole dialog.
>
Then if I have one UAC (PhoneA) and the proxy (OsipsA) and want
to trace all messages between them, it seems that the best way is:

  # Example 1
  route{
sip_trace();
[...]
  }

But to to avoid REGISTER, SUBSCRIBE, and ACK messages, then it seems
best to set the trace flag. How do you do this appropriately, and
how to avoid calling setflag more than once per transaction? Maybe
something like:

  # Example 2
  route{
[...]
if (loose_route())  # Not sure here ?!?
  setflag(22);
[...]
  }

It seems in the context described above it makes no difference
if I use setflag, setbflag, or setsflag, right?

Lastly, it seems that one can get a similar result as example 2
above by doing:

  # Example 3
  route{
[...]
if (is_method("INVITE") && !has_totag())
  trace_dialog();
[...]
  }

...just that in this case I will see the ACK messages as well.

Did I get that right? I'll be tracing all messages now, because
of needing to debug until OpenSIPS is running well. Later I'll
probably reduce the traces to just the dialogs.

By the way these diagrams helped me understand the difference
between transactions (setflag(22)) and dialogs (trace_dialog()):

  http://www.iptel.org/sip_dialog
  http://www.iptel.org/sip_transaction

Regards,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello Bogdan,

An jeu., déc 17, 2009, Bogdan-Andrei Iancu schrieb:
>opensipsl...@encambio.com wrote:
>> REGISTER messages seem to be handled correctly, but I'm still having
>> troubles with INVITEs:
>>
>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>> ERROR:core:tls_blocking_write: too many retries with no operation
>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>> ERROR:core:tcp_send: failed to send
>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:tm:msg_send: 
>> tcp_send failed
>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>> ERROR:tm:t_forward_nonack: sending request failed
>>   Dec 16 19:03:05 name.host.tld  opensips[10237]: 
>> ERROR:core:tls_accept: some error in SSL (ret=0, err=5, errno=0/Error 0):
>>
>Actually you have two errors there - one on a write op and another
>one on an accept op.
>
Not sure how you see that, maybe because one pair of 'ERROR' text is
written by 'core' (= write op) and one pair by 'tm' (= accept op)?

>So, for the write op, opensips complains that the  write() was
>tried several time (320 times) without doing anythingit is
>gives up in order to avoid blocking.
>
Okay I understand that.

>You may try to increase the number of tries to something higher -
>3200, just to see if that is the problem:
>
>see tls/tls_server.c , line 689
>   #define MAX_SSL_RETRIES 320
>
This doesn't make sense to me. If 320 retries are attempted with no
write op success, then trying 3200 can't be the solution. Rather, it
must be that I have an error in the config script or some permission
problem no?

I'll keep looking and check the CN names of all certs and
permissions as well (again.) Maybe OpenSIPS 1.6.X allows a
smaller margin of error with things like TLS or certificates.

Regards,
Brian

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

Re: [OpenSIPS-Users] Trying to learn how to use siptrace

[opensipslist]

An jeu., déc 17, 2009, opensipsl...@encambio.com schrieb:
>According to the online siptrace module docs:
>
>  'Only messages processed with TM/SL are logged.'
>
>First, I assume that is why when I do:
>
>  modparam("siptrace", "trace_flag", 22)
>  route{
>setflag(22);
>setbflag(22);
>[...]
>  }
>
>...that no REGISTERs are being traced. I assume that all other
>messages will be traced by the above code.
>
>Also, I see that I have the option of:
>
>  if (is_method("INVITE") && !has_totag())
>trace_dialog();
>
>...which seems to have the same effect (no REGISTERs traced.)
>But if I do:
>
>  route{
>sip_trace();
>[...]
>  }
>
>...then REGISTERs and INVITEs will be traced, right?
>
>QUESTION
>
>How do most people choose which of these three siptrace logging
>methods to use? Is there ever a reason to definitely not use one
>of them, and is it common to combine any of these three methods?
>
Sorry, I forgot to tell my platform information:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS

Thanks,
Brian

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

Re: [OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

An jeu., déc 17, 2009, opensipsl...@encambio.com schrieb:
>REGISTER messages seem to be handled correctly, but I'm still having
>troubles with INVITEs:
>
>  Dec 16 19:03:05 name.host.tld  opensips[10237]: 
> ERROR:core:tls_blocking_write: too many retries with no operation
>  Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:core:tcp_send: 
> failed to send
>  Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:tm:msg_send: 
> tcp_send failed
>  Dec 16 19:03:05 name.host.tld  opensips[10237]: 
> ERROR:tm:t_forward_nonack: sending request failed
>  Dec 16 19:03:05 name.host.tld  opensips[10237]: 
> ERROR:core:tls_accept: some error in SSL (ret=0, err=5, errno=0/Error 0):
>
>Where can I find out what 'err=5' means regarding SSL, and what does
>this typically mean? I'm pretty sure that my certs are in order,
>because this opensips.cfg was working in OpenSER 1.3.X as is.
>
Sorry, I forgot to tell my platform information:

  Solaris 11 x86 (nv-b91)
  OpenSIPS 1.6.0 with TLS
  OpenSSL 0.9.8k

Thanks,
Brian

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

[OpenSIPS-Users] Trying to learn how to use siptrace

[opensipslist]

Hello list,

According to the online siptrace module docs:

  'Only messages processed with TM/SL are logged.'

First, I assume that is why when I do:

  modparam("siptrace", "trace_flag", 22)
  route{
setflag(22);
setbflag(22);
[...]
  }

...that no REGISTERs are being traced. I assume that all other
messages will be traced by the above code.

Also, I see that I have the option of:

  if (is_method("INVITE") && !has_totag())
trace_dialog();

...which seems to have the same effect (no REGISTERs traced.)
But if I do:

  route{
sip_trace();
[...]
  }

...then REGISTERs and INVITEs will be traced, right?

QUESTION

How do most people choose which of these three siptrace logging
methods to use? Is there ever a reason to definitely not use one
of them, and is it common to combine any of these three methods?

Thanks,
Brian

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

[OpenSIPS-Users] Failed INVITE tcp_send

[opensipslist]

Hello list,

REGISTER messages seem to be handled correctly, but I'm still having
troubles with INVITEs:

  Dec 16 19:03:05 name.host.tld  opensips[10237]: 
ERROR:core:tls_blocking_write: too many retries with no operation
  Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:core:tcp_send: 
failed to send
  Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:tm:msg_send: 
tcp_send failed
  Dec 16 19:03:05 name.host.tld  opensips[10237]: 
ERROR:tm:t_forward_nonack: sending request failed
  Dec 16 19:03:05 name.host.tld  opensips[10237]: ERROR:core:tls_accept: 
some error in SSL (ret=0, err=5, errno=0/Error 0):

Where can I find out what 'err=5' means regarding SSL, and what does
this typically mean? I'm pretty sure that my certs are in order,
because this opensips.cfg was working in OpenSER 1.3.X as is.

Thanks,
Brian

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

[OpenSIPS-Users] Failed INVITE tcp_send to UDP UACs

[opensipslist]

Hello list,

PROBLEM
---

Registrations work well, but when sending IVITEs I see this in log:

  Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:core:mk_proxy: 
doing DNS lookup...
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:filter_and_sort_naptr: skipping SIP+D2U -> _sip._udp.voip.host.tld
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:filter_and_sort_naptr: found valid SIPS+D2T -> _sips._tcp.voip.host.tld
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:filter_and_sort_naptr: skipping SIP+D2T -> _sip._tcp.voip.host.tld
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:do_srv_lookup: SRV(_sips._tcp.voip.host.tld) = voip.host.tld:5061
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
DBG:core:sip_resolvehost: valid SRV found!
  [...]
  Dec 10 15:55:18 name.host.tld  opensips[10850]: DBG:core:send2child: 
to tcp child 0 0(10848), ceba0508
  Dec 10 15:55:18 name.host.tld  opensips[10850]: 
DBG:core:handle_ser_child: read response= ceb903f0, 2, fd 21 from 6 (10848)
  Dec 10 15:55:18 name.host.tld  opensips[10850]: DBG:core:tcpconn_add: 
hashes: 405, 3
  Dec 10 15:55:18 name.host.tld  opensips[10850]: DBG:core:io_watch_add: 
io_watch_add(82d10c0, 21, 2, ceb903f0), fd_no=10
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
ERROR:core:tls_blocking_write: too many retries with no operation
  Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:core:tcp_send: 
after write: c= ceb903f0 n=-1 fd=18
  Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:core:tcp_send: buf=
  INVITE sips:per...@voip.host.tld SIP/2.0^M
  Record-Route: ^M
  Via: SIP/2.0/TLS 211.123.22.12:5061;branch=z9hG4bK4d6.913.0;i=2^M
  Via: SIP/2.0/TLS 
192.168.1.12:3352;received=125.81.6.152;branch=z9hG4bK-pt7eil3u8qci;rport=3352^M
  [...]
  Content-Type: application/sdp^M
  ^...@dec 10 15:55:18 name.host.tld  opensips[10848]: 
ERROR:core:tcp_send: failed to send
  Dec 10 15:55:18 name.host.tld  opensips[10848]: ERROR:tm:msg_send: 
tcp_send failed
  Dec 10 15:55:18 name.host.tld  opensips[10850]: 
DBG:core:handle_ser_child: read response= ceb903f0, -2, fd -1 from 6 (10848)
  Dec 10 15:55:18 name.host.tld  opensips[10848]: 
ERROR:tm:t_forward_nonack: sending request failed
  Dec 10 15:55:18 name.host.tld  opensips[10850]: DBG:core:io_watch_del: 
io_watch_del (82d10c0, 21, -1, 0x10) fd_no=11 called
  Dec 10 15:55:18 name.host.tld  opensips[10848]: DBG:tm:t_relay_to: 
t_forward_nonack returned error

The forward (I assume by t_relay()) is failing. Is it because a SRV
lookup is being done and finding that raw SIP over TCP is being sent
to the OpenSIPS TLS listener? Should I be using something other than
t_relay() in the config?

The same config worked well with OpenSER 1.3.X. Only when migrating
to 1.6.0 do we see these errors. What could have changed?

Thanks,
Brian

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

Re: [OpenSIPS-Users] Problem with mi_fifo replies

[opensipslist]

Hello Iulia,

An jeu., déc 10, 2009, Iulia Bublea schrieb:
> No, I meant that OSISP_FIFO is not used in osipsconsolerc.
> Indeed it is used in osispconsole, but it is just a parameter and it's  
> value comes from splitting MI_CONNECTOR by ":". That is all. For param  
> configuring just use osipsconsolerc or opensispctlrc.
>
Okay I understand now but if OSIPS_FIFO is used both in osipsconsole(1)
and opensipsctl(1), then surely they both refer to the same concept
right? And if so, then when each of these two scripts resolves those
variables they should resolve to the same path, right?

I'm asking this to try to get a grip on what the values OSIPS_FIFO,
OSER_FIRE, and MI_CONNECTOR should be set to.

Is it correct to assume that OSIPS_FIFO and MI_CONNECTOR should both
be set and both resolve to the same path in opensipsctlrc?

Thanks,
Brian

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

Re: [OpenSIPS-Users] Problem with mi_fifo replies

[opensipslist]

Hello Iulia,

An jeu., déc 10, 2009, Iulia Bublea schrieb:
> To my knowledge OSIPS_FIFO is not used in osispsconsolerc, the only  
> parameter used is MI_FIFO.
>
I think you mean 'OSIPS_FIFO is not used in osipsconsol' but that
is be a wrong impression, see grep(1) output below. Both MI_FIFO
and OSIPS_FIFO are indeed used by osipsconsole. The question is if
both should be set to the same path value, or where the
documentation is to describe choosing a path for the various
(how many?) FIFOs being used.

 Cut 

[host]/tmp/opensips-1.6.0-tls.orig$ grep OSIPS_FIFO scripts/osipsconsole
my $OSIPS_FIFO = "";
$OSIPS_FIFO = $list[1];
$OSIPS_FIFO = "/tmp/opensips_fifo";
&write_read_fifo($OSIPS_FIFO,$path,$cmd_fifo);
&write_read_fifo($OSIPS_FIFO,$path,$cmd_fifo);
&write_read_fifo($OSIPS_FIFO,$path,$cmd_fifo);

&write_read_fifo($OSIPS_FIFO,$path,":get_statistics:$name\nUAS_transactions\nUAC_transactions\ninuse_transactions\n\n");

&write_read_fifo($OSIPS_FIFO,$path,":get_statistics:$name\nsent_replies\nsent_err_replies\nreceived_ACKs\n\n");

&write_read_fifo($OSIPS_FIFO,$path,":get_statistics:$name\nusrloc:\n\n");
$OSIPS_FIFO = $_[0];
if (!-e $OSIPS_FIFO){
print "File $OSIPS_FIFO does not exist!";
if ( !-w $OSIPS_FIFO ) {
print "Error opening OpenSIPS's FIFO " . $OSIPS_FIFO . "\n" . 
  "Make sure you have the line 'modparam(\"mi_fifo\", 
\"fifo_name\", \" " . $OSIPS_FIFO . "\")' in your config\n" .
open(ANS,">$OSIPS_FIFO") or die "Could not open $OSIPS_FIFO for 
writing: $!\n";

Regards,
Brian

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

Re: [OpenSIPS-Users] Problem with mi_fifo replies

[opensipslist]

Hello Iulia,

An jeu., déc 10, 2009, Iulia Bublea schrieb:
>> What exactly does 'MI_CONNECTOR' do, is the following config correct?
>>
>>   # config file opensipsctlrc:
>>   CTLENGINE=FIFO
>>   OSIPS_FIFO=/pfx/var/opensips/opensips.fifo
>>   OSER_FIRET=/pfx/var/opensips
>>   MI_CONNECTOR=FIFO:/pfx/var/opensips/opensips.fifo
>>
>> ...and should it be the same in osipsconsolrc?
>>
> For the osipsconsole just uncomment the MI_CONNECTOR in the osipsconsolerc
>
okay, but what should its value be? Should MI_CONNECTOR and
OSIPS_FIFO always be set to the same path as in my example above?

Regards,
Brian

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

Re: [OpenSIPS-Users] Help with sip trace errors please

[opensipslist]

Hello Ha,

An jeu., déc 10, 2009, ha do schrieb:
>i found the problem here when we using the db_text, i dont know how
>the opensips will write the log to the text file(sip_trace) i just
>stop then start opensips again and then i see all logs in the text
>file(sip_trace)
>
>the problem here when i start the second time -- opensips doesnt
>accept the old sip_trace text file, i need to create new sip_trace
>text file
>
>my question how long opensips will write the log to text file ??
>why opensips doesnt accept the old sip_trace text file? is there
>any enhancement to use the old text file
>
Are you saying that when no /tmp/opensipsdb/sip_trace exists, and
you start opensips fresh, then no error appears in the log and the
sip_trace file is created normally?

And are you saying that when a /tmp/opensipsdb/sip_trace exists,
and you start opensips fresh, then a error appears in the log and
the sip_trace file is not written to with new transactions? Please
show the errors in the log file if this is the case.

Also, please tell us the results of:

  [r...@localhost ~]# ls -ld /tmp/opensipsdb
  [r...@localhost ~]# ls -ld /tmp/opensipsdb/sip_trace
  [r...@localhost ~]# ps aux | grep opensips

...in order to determine if you have a permissions problem easily
solved in the opensips.cfg.

Regards,
Brian

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