sr-users February 2008

sr-users@lists.kamailio.org

146 participants
260 discussions

[OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?

by Iñaki Baz Castillo

Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE). Imagine this scenario: - A calls B. This produces a "Start" acc action, so a SQL INSERT. - After 1 minute A crashes (no BYE sent and RTP stop). - After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK). - But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!! How to avoid it? how to avoid anyone sending a malicious BYE with From&To tags and Call-ID from any other already ended call? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 9 months

[OpenSER-Users] RTP-Proxy

by Adrian Georgescu

>>>>>>> I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ? Hi Jerome, Freeradius/MediaProxy/CDRTool combination gives your this zero tolerance. CDRs are always correct down to the second regardless of missing BYEs, VAD and other things you have assumed in the previous postings. Regards, Adrian

16 years, 9 months

[Serusers] Can mediaproxy support relaying audio between destinations on two ethernet interfaces?

by Frank Durda IV

I'm having a problem with Mediaproxy, and am wondering if this is something it simply can't do (or won't do as written). I have a SER/mediaproxy server connected to two networks that cannot be reached by other means. So the only way for a SIP phone on one network to have a conversation with the other would be for the SER/mediaproxy combination to accept the audio from one side and shove it out to the destination on the other end. Network diagram: [SIP phone]---------+ [Asterisk Server]--[ethswitch]---[interface re2 on SER box] [PSTN switch]--------------------[interface re0 on SER box] SIP phone 192.168.200.20 Asterisk box 192.168.200.10 SER re2 192.168.200.30 PSTN switch RTP 10.9.193.146 SER re0 10.9.193.148 Again, these two networks are isolated and only meet at the SER box. This layout was a prototype for later use of NAT and the fact that the Asterisk (or a similar device) and phones would be at another company, on a network likely NAT-ed at least one more time. But for the moment there is no NAT activity, just two networks that can't send SIP data to each other except by what SER and mediaproxy/rtpproxy allow. What we see is that the call originating at the SIP phone is set up, the distant POTS phone rings, POTS phone answers, the SIP phone is informed, and we see audio passing from the PSTN network to the SER box, but no audio in either direction between SER box and SIP phone. So, mediaproxy did manage to insert itself into things enough so that the PSTN gateway knows the audio should go to a port there, so that is working. The reason for no audio on the SIP-phone side appears to be that mediaproxy is only aware of a single network interface being involved, and when the call was established, it gave the SIP phone an unreachable IP address of the network interface on the PSTN side of the SER box, not the IP address of the SER server interface on the side that is facing the SIP phone. (Packet sniff as viewed leaving the SER server) # U 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as5fc6504f. To: <sip:9613789999@192.168.200.30>;tag=13f0000-0-402969611. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK7d39191f;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on> . Contact: <sip:9613789999@10.9.193.130:5060>. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411495426 3411495447 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 10004 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - # U 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK6793020d;rport. Route: <sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on>. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as5fc6504f. To: <sip:9613789999@192.168.200.30>;tag=13f0000-0-402969611. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . but because the c=IN IP4 10.9.193.148 isn't set to 192.168.200.30, the SIP phone doesn't send any audio that is addressed for the SER/mediaproxy box, and so no one or two-way audio happens. So the ten %currency_unit question is this: Is this a limitation of Mediaproxy, that all audio must enter and leave (from and to all sources) on a single interface? A look at the source code suggests that it can only cope with a single interface, but I have not written code in Python, so may not be reading this right. The second question would be is this also a restriction of rtpproxy, or can it deal with having two or more network interfaces handling audio traffic? If it can, we'll switch to rtpproxy. If neither can handle it, we have problems. It seems odd that SER supports this situation but the audio component would not. Our mediaproxy is 1.7.2 Our ser is 0.9.6 Thanks in advance, Frank

16 years, 9 months

Re: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?

by Alex Balashov

On Fri, February 8, 2008 11:17 am, IÃ±aki Baz Castillo wrote: > - But now imagine that user B sends a BYE after 2 hours using the same > From&To tags and Call-ID. This is terrible!!! OpenSer will notify a > "Stop" action Why would it do that? Call-IDs are supposed to be GUIDs (Globally Unique Identifiers) and never reused. You shouldn't really be seeing collisions of them on a UA that properly implements the generation algorithm for them and fulfills the requirements of the RFC on this point. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

16 years, 9 months

[OpenSER-Users] R: How to use $fn ?

by malmic＠alice.it

________________________________ Da: malmic(a)alice.it Inviato: ven 08/02/2008 16.57 A: users-bounces(a)lists.openser.org Oggetto: How to use $fn ? Hi there, I'm running openser v1.1.1 and I'm trying to use the $fn pseudo -variable in this way: if($fn == "0123456") action(..); but when I try to start openser it gives me sintax error . What I am doing wrong? Thanks all Mik

16 years, 9 months

[OpenSER-Users] AVP syntax problem in config

by Sri Rao

I get the following in the daemon.log when I try to start openser: Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:pv_parse_spec: bad parameters Feb 8 08:34:46 vishnu openser[16425]: ERROR:lcr:mod_init: Malformed or non AVP definition <s:fr_inv_timer_avp> Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:init_mod: failed to initialize module lcr Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:main: error while initializing modules Here are the offending lines in openser.cfg: modparam("lcr", "contact_avp", "1401") modparam("lcr", "fr_inv_timer_avp", "s:fr_inv_timer_avp") Is there a different way of defining them? Thanks, Sri.

16 years, 9 months

Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture

by Schumann Sebastian

Hi Bogdan, one more inmportant note, I discovered this morning. This error only appears if the option mode=debug is set. A normal # make all does compile properly! Here is the output: netra120:/usr/local/src/openser# make mode=debug prefix=/usr/local all bison -d -b cfg cfg.y cfg.y: conflicts: 1 shift/reduce flex cfg.lex New SVN revision: 2:3654 Compiling action.c gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c action.c -o action.o Compiling blacklists.c gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c blacklists.c -o blacklists.o /tmp/ccRk3oFx.s: Assembler messages: /tmp/ccRk3oFx.s:831: Error: Architecture mismatch on "membar". /tmp/ccRk3oFx.s:831: (Requires v9|v9a|v9b; requested architecture is sparclite.) /tmp/ccRk3oFx.s:847: Error: Architecture mismatch on "membar". /tmp/ccRk3oFx.s:847: (Requires v9|v9a|v9b; requested architecture is sparclite.) make: *** [blacklists.o] Error 1 netra120:/usr/local/src/openser# Regards Sebastian -----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Friday, 08. February 2008 11:33 AM To: Schumann Sebastian Cc: users(a)lists.openser.org Subject: Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture Hi Schumann, Can you post please the compile line (as printed by make) - just to check the compile options. Thanks, Bogdan Schumann Sebastian wrote: > Dear all > > I am facing problems installing OpenSER 1.3 from branch on a Debian > 4.0R2 running on a SUN UltraSPARC IIi server (sparc64). > > After retrieving all required files and executing # make mode=debug, the > second file's compilation fails already: > > Compiling blacklist.c > .... > Error: Architecture mismatch on "membar". > (Requires v9|v9a|v9b; requested architexture is sparclite.) > > Does anyone know what could be the reason for that. On i386 I never > faced problems, and as OpenSER supports Solaris, it should also support > Debian on sparc64 architecture or not? > > Thanks a lot in advance. > > Best regards > Sebastian > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users > >

16 years, 9 months

Re: [OpenSER-Users] Survey for new mailing list

by Dan-Cristian Bogos

Folks, I share the same opinion that an announcements channel should be implemented in OpenSER project. Since another mailing list could be just another subject for SPAM detectors (sometimes removals) or SPAM senders, perhaps another good approach would be the presence of an RSS feed aggregator on OpenSER website where all the important news alerts could come in (security fixes, new releases) and be read by whoever is interested via RSS. It could be a supplementary effort from a person editing these news but it would benefit from the advantage of a read only channel so a trusted entity for real news. Cheers, DanB

16 years, 9 months

[Serusers] Is SER doc PSTN Gateway example incomplete/incompatible with Asterisk?

by Frank Durda IV

Hello, I am working my way through the "SER - Getting Started" documentation, using the sample configurations largely unchanged, and have run up against something that apparently others have also encountered, but I have not come across an actual fix for the problem. The basic lab setup here is SIP_Phone -> Asterisk_box -> SER_box -> Telica/Lucent LCS switch -> POTS All IP addresses are 192.168.x.x or 10.x.x.x addresses, with no NATing being performed. Asterisk and SER are operating on separate computers. The goal right now is to originate a call from the SIP phone and have a POTS phone ring answer on the other side of the LCS switch. The ser.cfg is essentially the one on page 49 of the "SER Getting Started" manual, with the local IP addresses substituted. However, any message received from the Asterisk server results in a "483 Too Many Hops" error. As mentioned in lots other places that Google can find, the Asterisk system fails to include some items that the RFC say should (or must) be there, and so SER promptly fails. The question is how to work around this, as in real life I won't have control of the Asterisk boxes communicating with my SER server and so can't patch Asterisk to play well with others. So the accommodation has to be in SER, or more likely, in its config file. Here is an OPTIONS that are regularly generated by Asterisk, and what happens to it when SER sees it: OPTIONS sip:192.168.200.30 SIP/2.0 Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK239aa8ac;rport From: "asterisk" <sip:asterisk@192.168.200.10>;tag=as0e01f6d8 To: <sip:192.168.200.30> Contact: <sip:asterisk@192.168.200.10> Call-ID: 74f1aaf801a2f3d750d053e82951e1a5(a)192.168.200.10 CSeq: 102 OPTIONS User-Agent: Asterisk PBX Max-Forwards: 70 Date: Tue, 05 Feb 2008 13:24:09 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 (HDR_VIA) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 235, <rport> = <n/a>; state=17 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=128 (HDR_ROUTE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16 This is the first unexpected behavior. SER apparently silently overrides the hop count specified by the message source (70) down to 16. Not a big deal, but in complex networks 16 might not be enough. Anyway, on to what happens... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=256 (HDR_RECORDROUTE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_newtran: msg id=449 , global msg id=448 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=-1 (HDR_EOH) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=60 (HDR_INVITE|HDR_INFO|HDR_CANCEL|HDR_BYE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: check_via_address(192.168.200.10, 192.168.200.10, 0) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG:maxfwd:is_maxfwd_present: value = 16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=256 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[4]: 0x284eb508 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[0]: 0x284eb518 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SER: new transaction fwd'ed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: receive_msg: cleaning up Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: t_newtran: msg id=454 , global msg id=453 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=-1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=60 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: check_via_address(192.168.200.30, 192.168.200.30, 0) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_to_tail_of_timer[4]: 0x284eccd0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_to_tail_of_timer[0]: 0x284ecce0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: SER: new transaction fwd'ed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: receive_msg: cleaning up Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK3bd.da3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG:maxfwd:is_maxfwd_present: value = 15 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=256 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: t_newtran: msg id=454 , global msg id=453 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=-1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=60 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: check_via_address(192.168.200.30, 192.168.200.30, 0) ... waiting for the hop counter to decrement to zero... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.bb3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ab3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.9b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.8b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.7b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.6b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.5b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.4b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.3b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.2b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.1b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.0b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.fa3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ea3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.da3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=9 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: to body [<sip:192.168.200.30>^M ] Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG:maxfwd:is_maxfwd_present: value = 1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=29 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=256 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: found end of header Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: find_first_route: No Route headers found Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: loose_route: There is no Route HF Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_newtran: msg id=453 , global msg id=452 , T on entrance=0xffffffff Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=-1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=60 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: check_via_address(192.168.200.30, 192.168.200.30, 0) Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[4]: 0x28510828 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[0]: 0x28510838 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: SER: new transaction fwd'ed Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: receive_msg: cleaning up Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: SIP Reply (status): Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: status: <483> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: reason: <Too Many Hops> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ab3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: After parse_msg... ... So the hop counter reaches zero and the activity ends with a 438 Too Many Hops error being returned. None of this appears to have made it past the SER system, so I don't believe the LCS (acting as PSTN gateway) got involved at all. The problem appears to circle around the lack of a Route: or Record-Route: and/or a lack or "lr" in the message. INVITE and other message types fail in the same way, so nothing gets started at all. In searching around, I came across a reference to adding this piece of code to the start of route[1] [-]# A note on when we need to call lookup("location") [-]# [-]# This was posted to serusers on 02/23/2005 by Daniel-Constantin Mierla [-]# [-]# lookup("location") has to be used for any request that has the domain [-]# part of R-URI pointing to your SIP server, should be delivered to an [-]# end-user and does not have to follow any Route header -- it does not [-]# matter the type of method. Could be said that only REGISTERs are just [-]# for servers, the others are either mixed (e.g, OPTIONS) or only for [-]# end-users. [-] [-] if (!search(^"Route:") && !search(^"Record-Route:")) { [-] lookup("location"); [-] }; but the description was not clear (might be a language translation issue) as to if this would solve this particular problem, and in testing, the addition of this code does not seem to change the outcome. In our lab network, here are the IPaddrs of interest: 192.168.200.20 SIP phone (/24 netblock) 192.168.200.10 Asterisk server (/24 netblock) 192.168.200.30 SER server (re2) (/24 netblock) 10.9.193.135 SER server (re1) (/28 netblock) 10.9.193.148 SER server (re0) (/29 netblock) 10.9.193.130 LCS Signaling port (/28 netblock) 10.9.193.146 LCS Bearer/RTP port (/29 netblock) and here is the ser.cfg, with just IPaddrs set from the published sample: # $Id: gw-pstn.cfg 51 2006-01-31 13:28:04Z /CN=Paul Hazlett/emailAddress=paul(a)onsip.org $ debug=4 fork=yes log_stderror=no listen=192.168.200.30 # INSERT YOUR IP ADDRESS HERE alias=192.168.200.30 port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("nathelper", "rtpproxy_disable", 1) modparam("nathelper", "natping_interval", 0) modparam("mediaproxy","natping_interval", 30) modparam("mediaproxy","mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/ser/sip-clients") modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/ser/rtp-clients") modparam("usrloc", "db_mode", 2) modparam("registrar", "nat_flag", 6) modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") route { # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { # INSERT YOUR IP ADDRESS HERE record_route_preset("192.168.200.30:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { end_media_session(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; }; if (method=="INVITE") { if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { route(4); route(1); } else { sl_send_reply("403", "Forbidden"); }; break; }; if (method=="ACK") { route(1); break; } else if (method=="CANCEL") { route(1); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- #Didn't seem to fix hop count error # if (!search(^"Route:") && !search(^"Record-Route:")) { # lookup("location"); # }; t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!search("^Contact:[ ]*\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); }; if (!www_authorize("","subscriber")) { www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } route[3] { # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { # International PSTN route(4); route(5); break; }; if (!lookup("location")) { if (uri=~"^sip:[0-9]{10}@") { # Domestic PSTN route(4); route(5); break; }; sl_send_reply("404", "User Not Found"); break; }; route(4); route(1); } route[4] { # ----------------------------------------------------------------- # NAT Traversal Section # ----------------------------------------------------------------- if (isflagset(6) || isflagset(7)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; } route[5] { # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- rewritehost("10.9.193.130"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); route(1); } onreply_route[1] { if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { if (!search("^Content-Length:[ ]*0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; } - - - - - - - - - - - - - - - - - - - - - - - - - - - Any suggestions or ideas as to how to get around this issue are appreciated! Frank

16 years, 9 months

[Serusers] Problem with nat + forward on busy

by Martina

Hi, I have the following problem when using t_relay in a failure route: - next hop is correctly set but SIP message is forwaded to a wrong IP address (specifically to the address in request uri) failure_route[failure] { if (t_check_status("486|600")) { xlog("L_ERR", "LXLOG FAILURE_ROUTE: forward busy\n"); attr2uri("$tr.forward_busy"); $tu.uid=$tu.uid_busy; route(INBOUND); } } In route[INBOUND] several actions are performed including lookup_contacts and NAT_MANGLE Finally in the route[FORWARD] if (isflagset(FLAG_FAILUREROUTE)) { xlog("L_ERR","LXLOG: FORWARD: failure flag is set"); append_branch(); } # if this is an INVITE we might try another # (forwarding or voicemail) target after receiving an error if (method=="INVITE" && !$to_gw){ xlog("L_ERR","LXLOG: FORWARD: set_failure_route"); t_on_failure("FAILURE_ROUTE"); } # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP xlog("L_ERR","L_XLOG <%ru> request uri <%nh> <%ds>"); if (!t_relay()) { sl_reply_error(); xlog("L_ERR","LXLOG: FORWARD: !t_relay"); }; drop; The LOG IS: Feb 7 18:32:40 pc005 ser[11574]: LXLOG: FORWARD: set_failure_route Feb 7 18:32:40 pc005 ser[11574]: LXLOG: %ru = <sip:103@192.168.23.237> %nh = <sip:100.0.0.2:1037;dstip=100.0.0.1;dstport=5060> %ds = <Contact: <sip:103@192.168.23.237>;q=0, sip:103@192.168.23.237> but when I look at the sent packets using ethereal INVITE message is sent to 192.168.23.237 instead that 100.0.0.2. Do you have any suggestion about possible cause of this behaviour? Thanks in advance Martina

16 years, 9 months

← Newer
1
...
17
18
19
20
21
22
23
...
26
Older →

Jump to page:

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 February 2008