sr-users September 2007

sr-users@lists.kamailio.org

158 participants
248 discussions

[OpenSER-Users] Do most SIP devices support SRV DNS lookup?
by Iñaki Baz Castillo 14 Sep '07

14 Sep '07

Hi, I'd like to know about experiences using SRV DNS: - Do most SIP device support it? - Will I have unexpected surprises with some SIP phones or softphones because don't support it? - How often do the SIP devices supporting SRV have it enabled by default? Of course I will test it by myself, but I'd like to be warned about it :) Thanks for any response. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 1

[OpenSER-Users] tls errors
by Jeremy George 14 Sep '07

14 Sep '07

Hello All, I could use some help with tls. Any pointers to a possible solution would be greatly appreciated. Please let me know if any further information would be helpful. Thanks. Everything seems to register correctly. Openserctl ul show seems correct (see below.) For a short time all is well. I can call from/to Polycom hard phones. (Eyebeam never seems to make calls, though it does register correctly.) Then calls stop working, and I begin getting the following error messages. Sep 12 16:17:16 spongy openser[30644]: ERROR: tcp_blocking_connect: SO_ERROR (111) Connection refused Sep 12 16:17:16 spongy openser[30644]: ERROR: tcpconn_connect: tcp_blocking_connect failed Sep 12 16:17:16 spongy openser[30644]: ERROR: tcp_send: connect failed Sep 12 16:17:16 spongy openser[30644]: msg_send: ERROR: tcp_send failed Sep 12 16:17:16 spongy openser[30644]: ERROR:tm:t_forward_nonack: sending request failed Sep 12 16:17:53 spongy openser[30644]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:17:53 spongy openser[30644]: ERROR:tm:w_t_relay: t_forward_nonack failed Sep 12 16:17:59 spongy openser[30629]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:17:59 spongy openser[30629]: ERROR:tm:w_t_relay: t_forward_nonack failed Sep 12 16:18:25 spongy openser[30625]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:18:25 spongy openser[30625]: ERROR:tm:w_t_relay: t_forward_nonack failed I thought the errors might be caused by an underlying tcp configuration issue on the machine, so I reconfigured the proxy and uas to use tcp (but not tls) and I had no trouble. Googling and looking through the archives seems to indicate I'm not the first person to have this problem. http://www.ip-phone-forum.de/archive/index.php/t-100539.html (I don't know if there is an answer here; unfortunately, I can't read German :) Spongy% sudo openser -V version: openser 1.2.2-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 2304 2007-05-25 16:36:07Z bogdan_iancu $ main.c compiled on 11:33:05 Sep 1 Spongy% sudo openserctl ul show Domain:: aliases table=512 records=0 max_slot=0 Domain:: location table=512 records=5 max_slot=1 AOR:: didama Contact:: sip:didama@75.56.10.117:37522;transport=tls Q= Expires:: 227 Callid:: acae15de-44fdabfd-e712aa40(a)75.56.10.117 Cseq:: 38 User-agent:: PolycomSoundPointIP-SPIP_330-UA/2.1.2.0049 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 AOR:: jeremy Contact:: sip:jeremy@75.56.10.115:5060;transport=udp Q= Expires:: 85 Callid:: 00036b09-50520002-40d733bc-0d83cc25(a)75.56.10.115 Cseq:: 140 User-agent:: Cisco-CP7960G/8.0 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:128.91.3.19:5060 Methods:: 4294967295 AOR:: jessica Contact:: sip:jessica@75.56.10.116:55250;transport=tls Q= Expires:: 1196 Callid:: ef97ec67-46682f92-799b9cc1(a)75.56.10.116 Cseq:: 84 User-agent:: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 AOR:: peggy Contact:: sip:peggy@75.56.10.113:1210;transport=TLS;rinstance=dd48392409b03c0a Q= Expires:: 3567 Callid:: M2NhMmI1OGZkZThhYjUzMmZiZTcxY2M0MjhlODE1ZDQ. Cseq:: 4 User-agent:: eyeBeam release 1013t stamp 43069 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 5951 AOR:: helen Contact:: sip:helen@75.56.10.116:55250;transport=tls Q= Expires:: 1197 Callid:: f556d6ba-86bff9c9-f62d758c(a)75.56.10.116 Cseq:: 84 User-agent:: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 Contact:: sip:helen@75.56.10.117:37522;transport=tls Q= Expires:: 228 Callid:: dd7e9645-83cfde68-f0f8341f(a)75.56.10.117 Cseq:: 38 User-agent:: PolycomSoundPointIP-SPIP_330-UA/2.1.2.0049 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 - Jeremy

2 1

[OpenSER-Users] 513 Massage too big
by Arya 14 Sep '07

14 Sep '07

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 and the computer trying to connect is on 192.168.1.100 And ngrep gave me these massages: Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 67.186.60.123:29296 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. -- Thank You

4 6

Re: [OpenSER-Users] CANCEL generated by openser after SIP/SDP Status: 200 OK
by Jan ONDREJ (SAL) 13 Sep '07

13 Sep '07

Hello, On Wed, Sep 12, 2007 at 05:32:15PM +0200, Klaus Darilion wrote: > 1. I have forgotten to tell you to use the "-W byline" switch too in > ngrep (much more readable SIP logs) I can resend you new logs if needed. > 2. Nevertheless, I have found the error: In the openser proxy your > create a second branch: Take a look at the logs - there are 2 INVITEs > sent from openser to ser - the only different in these INVITEs is the > branch parameter in the topmost Via header. > > The first is: > branch=z9hG4bK41a.25464943.0 > the second is: > branch=z9hG4bK41a.25464943.1 > > Thus, openser does parallel forking. Then, when Grandstream answers the > second branch (branch=z9hG4bK41a.25464943.1) openser will CANCEL the > first branch. Right. There is no problem with CANCEL but with 2 INVITEs. I have this in my openser log: 2(13970) DEBUG: t_lookup_request: no transaction found 2(13970) DBG: trans=0xb60d6e80, callback type 1, id 1 entered 2(13970) DEBUG:dialog:build_new_dlg: new dialog on hash 2386 2(13970) DBG: trans=0xb60d6e80, callback type 1, id 0 entered Is this a right place where the second fork is done? > Thus, you have either bug in your config or in your provisioning (maybe > you have the user twice in alias table or location table). Which command can create this second INVITE? What I need to find in my config? This user is not local, it is found by ENUM. My ENUM configuration: if (uri=~"^sip:\+[0-9]+@") { if (enum_query("e164.arpa.")) { xlog("L_ERR", "ENUM[e164.arpa]: [$rm] from user $fu to $ru\n"); route(5); return; }; if (enum_query("e164.arpa.", "voice")) { route(5); return; }; if (enum_query("e164.bts.sk.")) { route(5); return; }; }; Thanks. SAL

2 2

[Serusers] FW: problem in DNS lookup from enum
by geethanjali.csg＠wipro.com 13 Sep '07

13 Sep '07

Hi, I am configuring ser to use enum module. I am getting this error when dns lookup is done from ser. 0(27798) get_record: lookup(8.7.6.e164.arpa, 35) failed 0(27798) enum_query(): No NAPTR record found for 8.7.6.e164.arpa. This is my zone file: $TTL 3D @ IN SOA e164.arpa. root( 4 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS localhost IN NS e164.arpa. localhost A 127.0.0.1 e164.arpa. A 10.200.220.200 $ORIGIN 1.2.3.4.e164.arpa. IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:abcd@e164.arpa!" . $ORIGIN 8.7.6.e164.arpa. IN NAPTR 20 100 "u" "E2U+sip" "!^.*$!sip:xyz@e164.arpa!" . named.conf file contains, zone "e164.arpa" IN { type master; file "/var/named/named.enum"; }; This is my enum code in ser.cfg. loadmodule "/usr/local/lib/ser/modules/enum.so" modparam("enum", "domain_suffix", "e164.arpa.") if (method == "INVITE" && uri =~ "sip:\+[0-9]*+@.") { if (enum_query("e164.arpa")) { route(1); }; }; Its possible to ping the domain e164.arpa from the m/c where ser is installed. Any help in this regard is appreciated. Regards Geethanjali The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

[OpenSER-Users] Installing OpenSER in multiprocessor machine
by John Barry 13 Sep '07

13 Sep '07

Hello, I would like to know if there are any especial considerations when compiling, configuring, and running OpenSER v1.2.2 in a multiprocessor machine. I am using a quad-processor machine (Intel Xeon @ 3.00GHz) with Red Hat Enterprise Linux AS release 4 (2.6.9-42.0.3.ELsmp #1 SMP x86_64 x86_64 x86_64 GNU/Linux). I am also using MySQL DB for authentication in the same machine. I will appreciate any advice or information. Bests, JB _________________________________________________________________ Check out some new online services at Windows Live Ideas—so new they haven’t even been officially released yet. http://ideas.live.com

2 1

[Serusers] problem in DNS lookup from enum
by geethanjali.csg＠wipro.com 13 Sep '07

13 Sep '07

1 0

Re: [Serusers] WARNING: xl_mod_init: more IP 10.0.0.21 not used and ERROR: init_tcpudp_sock: bind: Address already in use [98]
by Jiri Kuthan 13 Sep '07

13 Sep '07

At 11:55 12/09/2007, Frank Wang wrote: >I downloaded ser 2.0.0-rc1 source code from <http://www.iptel.org/ser_2_0_0_release_candidate_1>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: <http://10.0.0.21>10.0.0.21 [<http://10.0.0.21>10.0.0.21]:5060 > tcp: <http://10.0.0.21>10.0.0.21 [<http://10.0.0.21>10.0.0.21]:5060 >Aliases: > tcp: <http://sipmcu.leadtek.com.cn:5060>sipmcu.leadtek.com.cn:5060 > udp: <http://sipmcu.leadtek.com.cn:5060>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 <http://10.0.0.21>10.0.0.21 not used unimportant. (I checked the code and I was a bit puzzled by it, but it really shold not matter much.) > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) ERROR: init_tcpudp_sock: bind: Address already in use [98] This is the problem. Maybe you have a SER instance running from the last time and you are starting the script again, for which reason SER can't be restarted -- it can't claim the same port number twice. > 0(3078) ERROR: ctl: mod_init: init ctrl. sockets failed > 0(3078) init_mod(): Error while initializing module ctl >ERROR: error while initializing modules This could have same reason. > >could anybody tell me how about it? Thanks a lot. > >Regards, >Frank >_______________________________________________ >Serusers mailing list >Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/

2 2

Re: [OpenSER-Users] WeSIP with openser 1.2.0 again
by Elias Baixas 13 Sep '07

13 Sep '07

Hi Gregorio, posting the SIP message that caused the problem would help me reproduce it, also some OpenSER logs would help. It seems to be related to the binary-encoding of the message. try out sipSpy to capture messages if you like. remove any field which you find confidential (lest Max-Forwards...) from the SIP message send it to me privately if you want. regards, Elias Gregorio wrote: > > 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.java: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.java: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.java: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.java:70) > > at > com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) > > at java.lang.Thread.run(Thread.java:595) > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

1 0

[OpenSER-Users] redirect server and handling 302 messages
by erik.linder＠accenture.com 12 Sep '07

12 Sep '07

Hello, I'm trying to make openser process 302 messages though I have problems(part of .cfg file below). I'll briefly explain the call flow I'd like to have: UA1 ---INVITE---> Session border controller ---INVITE--->SIP PROXY1 SIP PROXY1---INVITE--->REDIRECT SERVER---302 MOVED--->SIP PROXY1 SIP PROXY1---INVITE--->SIP PROXY2---INVITE---> Session border controller---INVITE---> UA2 This is how I want it to work. However managed to get a weird call flow were the 302 is forwarded back to the session border controller by the proxy1 which then trigger an INVITE sent to the SIP proxy2. But that is not what I want. My 302 message looks like this 20:12:34.314705 IP 192.168.200.101.sip > 192.168.200.102.sip: SIP, length: 488 E.....@.@.%....e...f........SIP/2.0 302 Moved temporarily Via: SIP/2.0/UDP 192.168.200.102;branch=z9hG4bK1658.2543f3d6.0 Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bKpis9m130dgj04b08v7k1.1 To: "22222"<sip:22222@btsip.bt.com>;tag=cc0e227ef05fff2dd833db745f3905a6.25f 2 From: "111"<sip:11111@btsip.bt.com>;tag=SDvto0501-df614a6e Call-ID: SDvto0501-515b91532ff7927a8345f39add52762f-06ahc50 CSeq: 1 INVITE Contact: , sip:22222@mydomain.com;maddr=192.168.200.103:5060;side=term> Content-Length: 0 192.168.200.101 is redirect server 192.168.200.102 is the proxy1 192.168.200.103 is proxy2 192.168.200.10 is session border controller 1. I would like to have proxy1 process the 302 message but there seems (from other mails on the mailing list) that openser does not allow routing depending on maddr in the Contact field. Sic :-( <- how can this routing decision been taken , using rewritehostport after get_redirect("*") is kind of ignored. The only workaround I have is to change the mydomain.com to the IP of proxy2 to get the automatic redirect 2. How can I block the redirect to the session border controller and send an invite right away to the proxy2? Here are the relevant part of the logic I use in proxy1 to handle the 302 I'm using this to trigger the forward to the redirect server: lookup("aliases"); #dest is remote if (!lookup("location")) { t_on_failure("3"); xlog("L_INFO","redirect invite to SLS\n"); #change orig to term in request URI $avp(s:request_uri_to_use)=$ru; avp_subst("$avp(s:request_uri_to_use)", "/orig/term/"); avp_pushto("$ru","$avp(s:request_uri_to_use)"); #forward("udp:192.168.200.101:5060"); #exit; rewritehostport("192.168.200.101:5060"); if(!t_relay()) { sl_reply_error(); } return; and this to try to handle the 302 that is received but it does not behave like I want: failure_route[3] { xlog("L_WARN","redirect FAILUREROUTE: time_t=$Ts messageid=$mi remark=here we are $bR\n"); if(t_check_status("3[0-9][0-9]")) { get_redirects("*"); xlog("L_WARN","^method=$rm ^ruri=$ru ^messageid=$mi^remark=2status is 3xx\n--$br--\nbR((($bR)))\n"); #rewritehost("$(ru{uri.maddr})"); serialize_branches(0); } xlog("L_WARN","nextbranch\n"); #next_branches(); #t_on_failure("3"); #t_relay(); return; #t_reply("404", "No branches left"); } Help would be appreciated Cheers erik This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

2 2

← Newer
1
...
15
16
17
18
19
20
21
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users September 2007