Hello all,
I see that one can set timeout variables per user in Ottendorf.
Is it possible to avoid this and set them on a global or domain basis? My users aren't so particular and I'd like to avoid the effort of having to set the timers for every user.
By the way, the default ser.cfg in Ottendorf is fantastic. Thanks for producing a well thought out config that demonstrates a good range of functionality. I've been using SER (+Asterisk) since 0.8.11 in my corporate environment (130 employees) so I'm not new, but I appreciate not having to take the time to sift though the code to figure out how the basics work.
I'm eagerly awaiting more documentation on Ottendorf!!
Thanks,
Mahatma
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hello,All
I'm having problems running OpenSER(openser-1.2.0-notls_src.tar.gz) with WeSIP(wesip-02-04-07-beta-0.1.4.tar.gz) AS.
SeasMessageEvent [SeasRouter] - New message received, from 192.168.0.119:3639 to 192.168.0.119:5060 over UDP
SeasTransactionEvent [SeasRouter] - hash_index = 57932,label=1021493454 flags=0
ExpressMessageChannel [ExpressMChannel[0]] - peerAddress = 192.168.0.119/3639
ExpressMessageChannel [ExpressMChannel[0]] - About to process INVITE sip:2001@192.168.0.200 SIP/2.0
SipConnector [ExpressMChannel[0]] - createProcessor: Reusing existing processor
SipProcessor [ExpressMChannel[0]] - An incoming message is being assigned
ExpressMessageChannel [ExpressMChannel[0]] - Done processing INVITE sip:2001@192.168.0.200 SIP/2.0
SipProcessor [SipProcessor[4]] - <<<<<<<<< Request Received <<<<<<<<<
INVITE sip:2001@192.168.0.200 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.119:15524
Max-Forwards: 69
From: "GP.Coder" <sip:5006@192.168.0.229>;tag=e495a30ed682466dad6c6fe809870efe;epid=1403e45675
To: <sip:2001@192.168.0.200>
Call-ID: dec886aa3e954c6492b92fc8adef9de8(a)192.168.0.119
CSeq: 1 INVITE
Contact: <sip:192.168.0.119:15524>
User-Agent: RTC/1.2
Content-Type: application/sdp
Content-Length: 479
SeasHashTable [SipProcessor[4]] - Inserting hashIdx:57932 label:1021493454 into hashTable
SipProcessor [SipProcessor[4]] - Transaction [null] is new Transaction?? --> true
EngineSipMapper [SipProcessor[4]] - Request from 192.168.0.229 mapped to: ConvergedEngine[Standalone].StandardHttpHost[localhost]
ConvergedEngineValve [SipProcessor[4]] - Invoking Host:localhost
SipProcessor [SipProcessor[4]] - error processing event...
java.lang.NullPointerException
at java.util.Hashtable.get(Hashtable.java:334)
at com.voztele.sipservlet.sessions.StandardSipManager.findUncomplete(StandardSipManager.java:570)
at com.voztele.sipservlet.valves.ConvergedHostValve.invokeSipRequest(ConvergedHostValve.java:218)
at com.voztele.sipservlet.valves.ConvergedHostValve.invokeSIP(ConvergedHostValve.java:126)
at com.voztele.sipservlet.valves.ConvergedHostValve.invoke(ConvergedHostValve.java:104)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:124)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:946)
at com.voztele.sipservlet.valves.ConvergedEngineValve.invoke(ConvergedEngineValve.java:114)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:946)
at com.voztele.sipservlet.processor.SipProcessor.invokeContainer(SipProcessor.java:198)
at com.voztele.sipservlet.processor.SipProcessor.processRequest(SipProcessor.java:142)
at com.voztele.sipservlet.processor.SipProcessor.process(SipProcessor.java:272)
at com.voztele.sipservlet.processor.SipProcessor.run(SipProcessor.java:253)
at java.lang.Thread.run(Thread.java:619)
SipConnector [SipProcessor[4]] - recycle: Recycling processor SipProcessor[4]
GP.Coder
2007-04-26
Is it possible to get rtpproxy/nathelper to start a totally new rtpproxy
session on re-invite and not use the previous pair of ports on the rtp
proxy?
In this case:
A calls B behind nat. Sdp are rewritten to go though rtpproxy on two ports.
X & Y.
Some time goes by with conversation. Then the call chages codec, line or
something (not important). In this case B ua changes rtp port locally also
(incremented by 2). This is no problem. The re-invite is sent with new port.
But problem now is that rtpproxy sees this and updates the sdp as always and
it uses the previous X & Y port that was used on the rtpproxy before
re-invite.
The problem now is this. Packets from B to A goes correctly since A's local
rtp port was same both before and after re-invite. But packets from A to B
is arrivind on B's local port for the first sdp session, not the second. It
seems that rtpproxy wont change this..
I assume this is a security measure for rtpproxy. But it should have some
function to force new session ports on rtpproxy by parameters to
force_rtpproxy() or something.
As far as I can tell this is only a problem if the sip-ua is changing local
port.. I thought maby calling unforce_rtp_proxy() before forcing rtp_proxy
again would help, but don't work. Probably because of some internal working
of nathelper.
Anyone got an idea how to solve this? I would really appreciate any input on
this..
-
Thomas
I apologize for the noise/rant of this post, but I feel something needs
to be said.
"By now support will be made trough the USERS openser mailing list"
Source: http://www.wesip.com/mediawiki/index.php/SupportMailingList
1) I don't object to you making a commercial product, but please do not
direct your users to this list.
2) I'm no license expert and won't confirm this by downloading your
software, but seems you are in violation of the GPL by linking into
openser and not releasing your software under a compatible license.
3) "WeSIP is patent pending technology"
Source: http://www.wesip.com/mediawiki/index.php/Main_Page
Where exactly is this technology pending patent? Do you have a
reference number by some chance?
4) I'm going to be a bit of a jerk and say you probably don't have the
capital to successfully litigate any international licensing violations
of your software. So why was this license chosen exactly?
To point of this is to not waste more of everyone's time, but to
encourage the company behind this seemingly fine product to GPL their
source so others can contribute.
Thanks
C.
Hi,
Are there any generally used methods for sending SIP NOTIFY messages
to a phone that is registered through openser?
I.e. for sending events to sip phones?
For example, I imagine a script that would register to the
mydomain.org openser server as an administrative user and send a
NOTIFY packet to user(a)mydomain.org.
I'm hoping not to reinvent the wheel here.
Mark Price
Hi,
I am testing simple(vs clean, per Jiri) t_replicate(server 2) on
"REGISTER" from server 1 to another ser server 2. Server 2 logs
"ERROR:registrar:update_contacts: invalid cseq for aor...".
ngrep shows that server 1 send "REGISTER" twice. May be the
re-transmitted request causes the incalid cseq?
Can anyone tell me how to fix this problem?
John Chahn Kim
Hi,
We have openser (currently 1.1.1) deployed in our iptel-solution and almost
everything seems to work ok but one strange thing has come up.
A user has a few Dlink DVG-2001S (behind a net-hide firewall) that tries to
register but doesn't succeed and my guess is that openser sends the reply to
the incorrect port and there firewall blocks this. A small ngrep-dump of the
session:
U 2007/04/24 11:40:12.620330 xx.xx.243.11:3710 -> xx.xxx.248.10:5060
REGISTER sip:sip.domain.tld SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.164:5060;branch=z9hG4bK8294fce7242e1605.
Max-Forwards: 70.
From: xx55551904 <sip:xx55551904@sip.domain.tld>;tag=1c2bcb8b48c89388.
To: xx55551904 <sip:xx55551904@sip.domain.tld>.
Call-ID: fec625fb04d0f004(a)192.168.0.164.
CSeq: 1 REGISTER.
Contact: *.
Expires: 0.
Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, INFO.
Content-Length: 0.
.
U 2007/04/24 11:40:12.620555 xx.xxx.248.10:5060 -> xx.xxx.243.11:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
192.168.0.164:5060;branch=z9hG4bK8294fce7242e1605;received=xx.xxx.243.11.
From: xx55551904 <sip:xx55551904@sip.domain.tld>;tag=1c2bcb8b48c89388.
To: xx55551904 <sip:xx55551904@sip.domain.tld>.
Call-ID: fec625fb04d0f004(a)192.168.0.164.
CSeq: 1 REGISTER.
Server: OpenSer (1.1.1-tls (i386/linux)).
Content-Length: 0.
Warning: 392 xx.xxx.248.10:5060 "Noisy feedback tells: pid=23636
req_src_ip=xx.xxx.243.11 req_src_port=3710 in_uri=sip:sip.domain.tld
out_uri=sip
:sip.domain.tld via_cnt==1".
Does anyone have a guess what might be causing openser to send the reply to
the wrong port ?
The openser-box has a live internet-ip and and isn't behind any type of
firewall or nat-device.
I think all client nat-stuff is correct since it seems to work with other
customers that are behind net-hide firewalls (broadband-routers).
/Thanks in advance - Ronnie Flink
Hello!
Thanks for your answer again, and I'm sorry for the delayed answer, but I was out of office.
My biggest problem is, that I don't know, what I should see :-(.
I have an eyeBeam window, that contains the "Calls & Conntats" parameters.
In this window I can see my (user) contact list, but I didn't see the global one.
For example (the PC is my user contact list):
-PC
-105
-12345
-barta
and it is working fine, but I can not see here (in this window) the global one:
sip:~# cat /var/www/xcap-root/rls-services/global/index
<?xml version="1.0" encoding="UTF-8"?>
<rls-services>
<service uri="sip:bartaj-list@test.intra">
<list name="Human resources">
<entry uri="sip:test1@test.intra">
<display-name>bartaj</display-name>
</entry>
<entry uri="sip:test2@test.intra">
<display-name>12345</display-name>
</entry>
</list>
<packages>
<package>presence</package>
</packages>
</service>
<service uri="sip:hr2@test.intra">
<list name="Human resources">
<entry uri="sip:test1@test.intra">
<display-name>bartaj</display-name>
</entry>
<entry uri="sip:test2@test.intra">
<display-name>12345</display-name>
</entry>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
I think in that case I should see the next tree:
-PC
-105
-12345
-barta
-Human resources
-bartaj
-12345
As You asked, I made a capture between the SER and XCAP.
It was a little difficult, because I didn't see interesting traffic between the SER and XCAP, but a few minutes later I realised, that the SER for the communication (in that case) uses the loopback (lo) interface.
You can see here the capture, that I made on the lo interface:
1 0.000000 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [SYN] Seq=0 Len=0 MSS=16396 TSV=3808162073 TSER=0 WS=0
2 0.000056 127.0.0.1 -> 127.0.0.1 TCP www > 37512 [SYN, ACK] Seq=0 Ack=1 Win=32767 Len=0 MSS=16396 TSV=3808162073 TSER=3808162073 WS=0
3 0.000065 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [ACK] Seq=1 Ack=1 Win=32767 Len=0 TSV=3808162073 TSER=3808162073
4 0.000072 127.0.0.1 -> 127.0.0.1 HTTP GET /xcap/pres-rules/users/12345/presence-rules.xml HTTP/1.1
5 0.000079 127.0.0.1 -> 127.0.0.1 TCP www > 37512 [ACK] Seq=1 Ack=113 Win=32767 Len=0 TSV=3808162073 TSER=3808162073
6 0.000545 127.0.0.1 -> 127.0.0.1 HTTP HTTP/1.1 200 OK
7 0.000559 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [ACK] Seq=113 Ack=262 Win=32767 Len=0 TSV=3808162074 TSER=3808162074
8 0.000571 127.0.0.1 -> 127.0.0.1 HTTP Continuation or non-HTTP traffic
9 0.000578 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [ACK] Seq=113 Ack=870 Win=32767 Len=0 TSV=3808162074 TSER=3808162074
10 0.005535 127.0.0.1 -> 127.0.0.1 TCP 37513 > www [SYN] Seq=0 Len=0 MSS=16396 TSV=3808162079 TSER=0 WS=0
11 0.005556 127.0.0.1 -> 127.0.0.1 TCP www > 37513 [SYN, ACK] Seq=0 Ack=1 Win=32767 Len=0 MSS=16396 TSV=3808162079 TSER=3808162079 WS=0
12 0.005565 127.0.0.1 -> 127.0.0.1 TCP 37513 > www [ACK] Seq=1 Ack=1 Win=32767 Len=0 TSV=3808162079 TSER=3808162079
13 0.005616 127.0.0.1 -> 127.0.0.1 HTTP GET /xcap/pres-rules/users/bartaj/presence-rules.xml HTTP/1.1
14 0.005623 127.0.0.1 -> 127.0.0.1 TCP www > 37513 [ACK] Seq=1 Ack=114 Win=32767 Len=0 TSV=3808162079 TSER=3808162079
15 0.005989 127.0.0.1 -> 127.0.0.1 HTTP HTTP/1.1 200 OK
16 0.006000 127.0.0.1 -> 127.0.0.1 TCP 37513 > www [ACK] Seq=114 Ack=262 Win=32767 Len=0 TSV=3808162079 TSER=3808162079
17 0.006011 127.0.0.1 -> 127.0.0.1 HTTP Continuation or non-HTTP traffic
18 0.006017 127.0.0.1 -> 127.0.0.1 TCP 37513 > www [ACK] Seq=114 Ack=870 Win=32767 Len=0 TSV=3808162079 TSER=3808162079
19 2.979491 127.0.0.1 -> 127.0.0.1 HTTP GET /xcap/rls-services/global/index HTTP/1.1
20 2.979722 127.0.0.1 -> 127.0.0.1 HTTP HTTP/1.1 200 OK
21 2.979734 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [ACK] Seq=209 Ack=1126 Win=32767 Len=0 TSV=3808165053 TSER=3808165053
22 2.979745 127.0.0.1 -> 127.0.0.1 HTTP Continuation or non-HTTP traffic
23 2.979751 127.0.0.1 -> 127.0.0.1 TCP 37512 > www [ACK] Seq=209 Ack=1887 Win=32767 Len=0 TSV=3808165053 TSER=3808165053
You can see, that in the message number 19 the SER downloaded the index file.
This file contains correct information:
sip:~# wget 127.0.0.1/xcap/rls-services/global/index
--17:22:43-- http://127.0.0.1/xcap/rls-services/global/index
=> `index'
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 761 [text/plain]
100%[====================================>] 761 --.--K/s
17:22:43 (7.26 MB/s) - `index' saved [761/761]
sip:~#
sip:~# cat index
<?xml version="1.0" encoding="UTF-8"?>
<rls-services>
<service uri="sip:bartaj-list@test.intra">
<list name="Human resources">
<entry uri="sip:test1@test.intra">
<display-name>bartaj</display-name>
</entry>
<entry uri="sip:test2@test.intra">
<display-name>12345</display-name>
</entry>
</list>
<packages>
<package>presence</package>
</packages>
</service>
<service uri="sip:hr2@test.intra">
<list name="Human resources">
<entry uri="sip:test1@test.intra">
<display-name>bartaj</display-name>
</entry>
<entry uri="sip:test2@test.intra">
<display-name>12345</display-name>
</entry>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
sip:~#
And at last, how can I add query_rls_services and query_resource_list log informations into the config file?
Thx,
Jani
-----Original Message-----
From: Vaclav Kubart [mailto:vaclav.kubart@iptel.org]
Sent: Tuesday, April 03, 2007 11:18 AM
To: Barta János
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] global contact list
Hi,
this part of config file is not sufficient for me, but I guess that RLS related things stayed as in the original config you mentioned... In which way it doesn't work? (For example it returns non OK responses?) Please could you try to capture HTTP traffic between XCAP server and SER? (If SER really queries the right resource list document.)
You can add more log information around important config parts (query_rls_services and query_resource_list functions are most important here).
BTW the second message you sent is not subscription to resource list or user, it is subscription to event package 'sip-profile' (content of Event header field) which is not supported by SER.
It is possible to use registration status as source for presence - in this case you have to have PA module on your server handling registrations and PA module parameter 'use_callbacks' must be set to 1.
Vaclav
<br><br>_____________________________________________________________________<br>
Tudod már, hol nyaralsz? Úti beszámolókat, utazási ajánlatokat találsz a <a href="http://ad.adverticum.net/b/cl,1,6022,159388,223268/click.prm" target="new">travelline.hu-n!</a><br>
Ha Te is megírod élményeidet, megnyerhetsz egy párizsi utat vagy egy kalandtúrát az Alpokba!
Hi,
My clients get registered but no call is successfully transfered when I
used UCTIMSCLIENT or Linphone.
Besides I can't get any output or trace to know what is wrong with SER.
micadeyeye@micadeyeye:/opt/OpenIMSCore$ sudo ngrep port 5060 -d eth0
Password:
interface: eth0 (10.128.0.0/255.255.0.0)
filter: (ip or ip6) and ( port 5060 )
PLS HELP.
MIKE
