Hi everyone,
Hi!
Just installed WeSIP beta-0.1.4 and openser 1.2.0 in the same machine,
configuration looks alright because some SIP Servlets receive messages. Now
I am getting an exception in the SEAS module when I receive MESSAGE, I think
this problem is similar to a previous one in the mailing list (Sat Apr 28
16:07:34 CEST 2007, [WeSIP with openser 1.2.0 again]). Does someone know
anything about it?
This is the exception:
Thanks for helping.
java.lang.ArrayIndexOutOfBoundsException: 5942
at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40)
at com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144)
at
com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29)
at
com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266
)
at
com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230)
at
com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225)
at
com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338)
at
com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser
.java:357)
at
com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136)
at
com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav
a:70)
at
com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301)
at java.lang.Thread.run(Thread.java:595)
Exception in thread "ExpressMChannel[1]" java.lang.NullPointerException
at
com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143)
at
com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav
a:70)
at
com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301)
at java.lang.Thread.run(Thread.java:595)
java.lang.ArrayIndexOutOfBoundsException: 5942
at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40)
at com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144)
at
com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29)
at
com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266
)
at
com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230)
at
com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225)
at
com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338)
at
com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser
.java:357)
at
com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136)
at
com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav
a:70)
at
com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301)
at java.lang.Thread.run(Thread.java:595)
Exception in thread "ExpressMChannel[2]" java.lang.NullPointerException
at
com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143)
at
com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav
a:70)
at
com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301)
at java.lang.Thread.run(Thread.java:595)
Peoplefone AG offers Voice over IP(VoIP) services with exceptional rates.
Peoplefone is a certified partner of
Siemens<http://www.siemens.ch/index.jsp?sdc_p=c175fi1012637lmno1012637psuz1&sdc_sid…>and
AVM/FRITZ!Box <http://www.fritz-shop.ch/>. Due to our rapid growth, for our
new Polish subsidiary we are currently seeking for:
VOIP SPECIALIST
Place of work: Warsaw
*Requirements:*
- Graduation from college or university with a Bachelor's degree
(preferably IT)
- Experience with PHP
- Practical knowledge of C and C++
- Practical knowledge of Mysql and Postgresql
- Linux experience
- Knowledge of IP Networks, UDP, TCP
- Experience with tools for Network analysis like Ethereal
- VoIP basic knowledge, VoIP servers, configuration of devices
- Fluency in English
- Ability to interact with individuals and groups at all levels
- Detail oriented and analytical
- Strong verbal and written communication skills
Knowledge of Perl, Java, Asterisk / SER / OPENSER, ability to configure
routers, Cisco or Patton gateways, knowledge of SIP and STUN protocol,
knowledge of NAT problems, of outbandProxy, knowledge of monitoring tools
like Cactus, Nagios, MRTG or high availability tools like DRBD, Hearthbeat
would be an additional asset.
Interested individuals are requested to send their resume to:
ewa.ciesla(a)peoplefone.com
In your application please put the following statement:
I hereby agree for processing the following personal information strictly
for recruitment purposes in accordance with the regulation regarding the
protection of personal data passed on the following date: 29.08.97r. Dz.U nr
133 poz. 883.
Hello,
I have problems calling from my phones connected to openser to grandstream
phones on another university to ser. Problem is, that my openser generates
a "CANCEL" SIP packet sent to grandstream phone, but no CANCEL received
from my phone. Wireshark shows something like this:
1189587144.843962 158.195.15.100 -> 158.197.16.77 SIP/SDP Status: 200 OK,
with session description
1189587144.845528 158.197.16.77 -> 158.195.15.100 SIP Request: CANCEL
sip:+421xxxx44903@domain.sk
1189587144.853654 158.195.15.100 -> 158.197.16.77 SIP Status: 200 canceling
Communication before is OK. 158.197.16.77 is my openser server and
158.195.15.100 is peers phone.
Any idea, why openser can generate this packet? Can openser generate a
SIP packet not received from client?
Calling from my phone to another phone on same university works well.
Thank you.
SAL
I downloaded ser 2.0.0-rc1 source code from
http://www.iptel.org/ser_2_0_0_release_candidate_1 and install on my Linux
step by step according the tutorial on the WEB.
When I running SER, I got follow messages:
[root@sipmcu ser]# ../../sbin/ser -f ser.cfg
Listening on
udp: 10.0.0.21 [10.0.0.21]:5060
tcp: 10.0.0.21 [10.0.0.21]:5060
Aliases:
tcp: sipmcu.leadtek.com.cn:5060
udp: sipmcu.leadtek.com.cn:5060
*: mytestser.org:*
WARNING: no fork mode
0(3078) init_tcp: using epoll_lt as the io watch method (auto detected)
0(3078) Maxfwd module- initializing
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used
0(3078) ERROR: init_tcpudp_sock: bind: Address already in use [98]
0(3078) ERROR: ctl: mod_init: init ctrl. sockets failed
0(3078) init_mod(): Error while initializing module ctl
ERROR: error while initializing modules
could anybody tell me how about it? Thanks a lot.
Regards,
Frank
---------- Forwarded message ----------
From: Brandon Armstead <brandon.armstead(a)gmail.com>
Date: Sep 7, 2007 12:06 PM
Subject: Re: [OpenSER-Users] Transaction Deletion
To: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
Hello Bodgan,
There is no noticable delay however the only thing I see is that one of
the RR'ed proxy's responds sends out 200 OK rather than the original. You
can see an example sipcap of this at this url: http://pastebin.ca/685897 .
If you could let me know if you see anything that looks rather, odd, towards
the end you can see the last few transactions and where there is no response
to 216.82.224.203's 200 OK, where it flips from 216.82.224.202 to
216.82.224.203 from the RR. Also then later the PSTN follows with a BYE,
due to no response, once again thanks for your help!
Regards,
Brandon
On 9/7/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
>
> Hi Brandon,
>
> Is there any noticeable delay between the 200OK and ACK ?
>
> regards,
> bogdan
>
> Brandon Armstead wrote:
> > Hello Users,
> >
> > I have a weird scenario where the PSTN is responding with 200 OK,
> > however Openser Never forwards on the ACK, after several
> > retransmissions of 200OK to Openser, PSTN responds with BYE, anyone
> > know what might be going on? I've played with the timers to no avail,
> > any help is appreciated, thank you! The log below is as follows:
> >
> > 375 Sep 6 12:18:10 openser /usr/local/sbin/openser[17385]: DEBUG:
> > timer routine:1,tl=0x2b78e4e73588 next=(nil), timeout=261
> > 376 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG:
> > timer routine:2,tl=0x2b78e4e733b8 next=(nil), timeout=262
> > 377 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG:
> > wait_handler : removing 0x2b78e4e73338 from table
> > 378 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG:
> > delete transaction 0x2b78e4e73338
> > 379 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG:
> > wait_handler : done
> > 380 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]:
> > DEBUG:parse_to:end of header reached, state=10
> > 381 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG:
> > get_hdr_field: <To> [26]; uri=[sip:openser]
> > 382 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG: to
> > body [<sip:openser> ]
> > 383 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG:
> > get_hdr_body : content_length=0
> > 384 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]:
> > DEBUG:destroy_avp_list: destroying list (nil)
> > 385 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]:
> > DEBUG:forward_reply: found module tm, passing reply to it
> > 386 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > t_check: start=0xffffffffffffffff
> > 387 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > add_param: tag=gK0288a919
> > 388 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]:
> > DEBUG:parse_to:end of header reached, state=29
> > 389 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > get_hdr_field: <To> [53]; uri=[ sip:17144828306@openser]
> > 390 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: to
> > body [<sip:17144828306@openser>]
> > 391 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > t_reply_matching: hash 53903 label 1526431020 branch 0
> > 392 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > t_reply_matching: no matching transaction exists
> > 393 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > t_reply_matching: failure to match a transaction
> > 394 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG:
> > t_check: end=(nil)
> >
> > It seems like its not matching the transaction, because a timer is
> > removing the transaction? Any ideas? Thanks!
> > --
> > Brandon Armstead
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
--
Brandon Armstead
--
Brandon Armstead
Arya,
it means you have a routing error in the script - you need to debug your
script to see where the routing logic is broken - try using xlog()
messages to see the execution path of your script.
I cannot help you with more than this.
regards,
bogdan
Arya wrote:
> any idea how I can fix the problem?
>
> On 9/11/07, *Arya* <arya6000(a)gmail.com <mailto:arya6000@gmail.com>>
> wrote:
>
> I used ngrep but it just shows that the massage keeps bouncing
> server to client, and eventually it says massage too big
>
>
> On 9/11/07, * Bogdan-Andrei Iancu* < bogdan(a)voice-system.ro
> <mailto:bogdan@voice-system.ro>> wrote:
>
> Hi,
>
> use ngrep or tcpdump to get a network trace from the proxy
> server, on
> the loopback interface.
>
> Regards,
> Bogdan
>
> Arya wrote:
> > Can you tell me how I can trace it? could this be an issue
> with my
> > router? its the Linksys Wr54G and its set on DMZ to the server
> >
> > On 9/10/07, *Bogdan-Andrei Iancu * <bogdan(a)voice-system.ro
> <mailto:bogdan@voice-system.ro>
> > <mailto: bogdan(a)voice-system.ro
> <mailto:bogdan@voice-system.ro>>> wrote:
> >
> > Hi Arya,
> >
> > I suspect you have a routing problem that cause the
> request to loop on
> > openser (via loopback interface) - openser keeps sending the
> > request to
> > itself. That's why you get a "Message to big" or "too
> many hops"....
> >
> > run a trace on lo to see if this is what's happening.
> >
> > regards,
> > bogdan
> >
> > Arya wrote:
> > > Hello everyone
> > >
> > > I have a problem connecting to OpenSER from my public IP.
> > >
> > > I can connect and make calls to OpenSER inside my LAN
> but when I
> > > connect from outside LAN I get the 513 Massage too big
> massage.
> > I than
> > > changed the openSER default config's section that
> checks a message
> > > size to a bigger number and I got the I get the "483 -
> too many
> > Hops"
> > > error.
> > >
> > > I changed the config back to default and tested it with
> ngrep and I
> > > tried connecting to the server from a server in another
> state.
> > >
> > > The SIP server is on 192.168.1.109
> <http://192.168.1.109> <http://192.168.1.109
> <http://192.168.1.109>>
> > <http://192.168.1.109> and the
> > > computer trying to connect is on 192.168.1.100
> <http://192.168.1.100>
> > < http://192.168.1.100> <http://192.168.1.100 <
> http://192.168.1.100>>
> > >
> > > And ngrep gave me these massages:
>
Hello,
although is more part of devel, the decision will affect users of future
stable releases, so I posted on both lists.
Maybe some of you noticed that in the ongoing process of improving the
pseudo-variables system, the AVPs and HDRs can be accessed with dynamic
index. That means next lines are correct in the config file.
$var(i) = 1;
xlog("$(avp(i:20)[$var(i)])");
if($(avp(i:20)[$var(i)]) == 3) {
}
In the past, the index was static, as a number.
The question I want to address is whether makes sense to add 'while'
statements to iterate through avps or hdrs. More or less, the cycles can
be done via recursive routes.
The block:
$var(i) = 0;
while($(avp(i:20)[$var(i)]) != null) {
.....
$var(i) = $var(i) +1;
}
is equivalent with:
$var(i) = 0;
route(1);
....
route[1] {
if(($(avp(i:20)[$var(i)]) == null)
return;
...
$var(i) = $var(i) +1;
route(1);
}
'while' may look more attractive, but could open the pandora box, people
asking for more and more, that will turn config language is something
very complex (not saying that is simple now :-) ).
The drawback with recursive routes is the fixed number of routes that
can be defined with the standard openser: 40 (number can be increased if
openser is recompiled), because for each cycle another route has to be used.
Waiting for your opinions...
Cheers,
Daniel
Hello,
I have a problem trying to remove a header using remove_hf() after an
append_branch(). I am using 1.2 version of OpenSer. The scenario with
the problem is as described in the folowing lines.
When I receive an INVITE I try a parallel fork (one leg towards PSTN,
the other towards IP), at which time I append a "Redirection" header.
The PSTN leg will be answered with a 486 response, due to the presence
of the "Redirection" header. When the IP leg expires, I receive a 408
response, at which time I do a serial fork, and resend the message
towards the PSTN destination, this time without the "Redirection"
header.
The problem is that I cannot seem to be able to remove (or find) the
header. I tried everywhere (before appending the new branch, after, in
branch_route, before relaying), as you will see below.
I tried searching the mailing lists but nothing turned up. I would
greatly appreciate any help, for I am running out of ideas.
Here is a simplified version of my configuration script, containing
only the significant bits of the routing blocks:
#---------------------------------------------------
# main routing logic
#---------------------------------------------------
route {
# check maxfwd and message lenght
# do loose routing
if (method=="INVITE") {
# rewrite ruri
rewriteuri(<PSTN destination>);
# signal forking
append_hf("Redirection: count=5\r\n");
append_branch();
revert_uri();
t_on_failure("1");
if (!t_relay()){
xlog("acc_info", " ERROR");
sl_reply_error();
}
} else if (method=="ACK" || method=="BYE" || method=="CANCEL") {
# default message handler
} else {
# forbidden message handler
}
}
#---------------------------------------------------
# Failure route relay
#---------------------------------------------------
route[1] {
xlog("acc_info", " Failure route relay");
# try removing it before t_relay
if(is_present_hf("Redirection")){
xlog("acc_info", " Remove before t_relay");
remove_hf("Redirection");
}
if (!t_relay()){
xlog("acc_info", " ERROR");
sl_reply_error();
}
}
#---------------------------------------------------
# Failure route handling
#---------------------------------------------------
failure_route[1] {
xlog("acc_info", " failure route handler");
if(t_check_status("408")) {
t_on_branch("1");
rewriteuri(<PSTN destination>);
# try removing it before append branch
if(is_present_hf("Redirection")){
xlog("acc_info", " Remove before append branch");
remove_hf("Redirection");
}
append_branch();
# try removing it after append branch
if(is_present_hf("Redirection")){
xlog("acc_info", " Remove after append branch");
remove_hf("Redirection");
}
route(1);
}
}
Hello all,
I'm having some trouble with failure routes and custom SIP headers.
In FAILURE_ROUTE I set the ruri to a new destination. This destination needs a
custom SIP header. When I add a SIP header with append_hf() (from within the
failure_route), this header is correctly sent to the first IP of the
destination on t_relay().
However, when this destination fails with 503 or timeout, the built-in DNS
based failover doesn't add the custom SIP header to the new requests for
subsequent IP's.
When the SIP header is added from REQUEST_ROUTE the header is sent to all
destinations by the DNS based failover mechanism.
How do I get the DNS based failover to send my SIP headers all the time?
(The same problem is present with uac_auth())
--
Greetings,
Alex Hermann
First of all sorry for this post not being in the thread it belongs to (I've
not the initial mail).
> But, I don't want to use the Asterisk dtmf features,
> I want to use the SIP INVITE/REFER features from the
> UAC (actually polycom and snom phones).
>
> Can someboy shed me some light on this?
You receive a call from Asterisk UAC and want to transfer (blind or attender)
to other UACregistered in OpenSer.
Of course you don't need Asterisk native transfer, SIP allows blind and
attended transfer. The only you need is that your SIP devices allow both of
them (unfortunatelly many SIP devices just allow blind transfer, but in most
cases reading the device manual you'll find how to do a attended transfer).
The point here is that Asterisk allows receiving a REFER, so don't worry for
that (I use your same escenary with no problem and SIP transfers).
Maybe you find useful this links:
http://tech-invite.com/Ti-sip-service-4.htmlhttp://tech-invite.com/Ti-sip-service-5.htmlhttp://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/SipTransfer
Regards.
--
Iñaki Baz Castillo