I will be out of the office starting Mon 06/02/2008 and will not return
until Mon 06/09/2008.
I will have very limited access to mail, so please contact the CSC at
888-899-4227 if you need immediate assistance.
It is not the matter of rfc3261, the nokia sip stack force any request adding this header. Without it, the test will not be going on.
Regards,
Kevin
_________________________________________________________________
新年换新颜,快来妆扮自己的MSN给心仪的TA一个惊喜!
http://im.live.cn/emoticons/?ID=18
On Wednesday 04 June 2008, Jason Penton wrote:
> Hi Henning
>
> would you mind elaborating a little?
Hi Jason,
please always CC to the user list.
First of all you need to define a failure_route in your config. After the
lookup() to your location database you arm this with t_on_failure. In the
failure route you check with t_check_status("408") the error code and forward
then to your voicemail.
Cheers,
Henning
On Wednesday 04 June 2008, Jason Penton wrote:
> yes, but maybe instead of deregistering the user, it could foeard to
> voicemail or similar instead of the callee just hearing 'nothing' and not
> knowing what is going on?????
(moved to the user list)
Hi Jason,
normally you just setup a prober INVITE timeout, and forward on the 408 that
is generated to voicemail.
Cheers,
Henning
Hi
All I have the following setup
Openser Server A --> Uses Localhost MySQL Server
Openser Server B --> Uses ServerA MySQL server
Each server is in a different location. Both servers share the same
database. I.e. in other words a user can successfully logon to either
server. Both servers have a similar configuration file. My problem at
hand is the following
User A and User C logon to Server A
User B logs on to Server B
I need user A or user C to be able to call user B.
I am using t_replicate for this setup. The relevant config section is
found below:
if(src_ip == OTHERSERVER)
{
xlog("L_INFO","PACKET FROM 9 PEER SERVER");
save("location");
}else{
xlog("L_INFO","NORMAL Packet");
if(is_method("REGISTER")){
if(!www_authorize("sero.test.net", "subscriber")){
www_challenge("sero.ahwar.net",
"1");
return;
}
save("location");
t_replicate("sip:OTHERSERVER:5060");
return;
}
I have looked at traces and it seems to me that if a user logs on to a
server t_replcicate forwards those register packets to the second
server. However the second server is not reponding to those register
packets it is replying with Bad Request replies
U OriginatingServer:5060 -> Target_of_Treplicate:5060
REGISTER sip:OriginatingServer SIP/2.0.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bKe47f.4bd99ca4.0.
Via: SIP/2.0/UDP
192.168.0.176:45374;received=193.227.186.146;branch=z9hG4bK-d87543-00509
f6c6f4a047f-1--d87543-;rport=45374.
Max-Forwards: 69.
Contact:
<sip:9613041705@193.227.186.146:45374;rinstance=1367153d6d22ca20>;expire
s=0.
To: "9613041705"<sip:9613041705@OriginatingServer>.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7d242230.
Call-ID: MmE3MTlmZDhiYWI0NjNmZjI5NWU5Njg1MmNhNDUwMDU..
CSeq: 6 REGISTER.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite release 1006e stamp 34025.
Authorization: Digest
username="9613041705",realm="sero.ahwar.net",nonce="484653b8b642971aef30
31dfa8d894fa90a4faf3",uri="sip:OriginatingServer",response="fd7943d66556
832aff9abcba071a9d85",cnonce="4f6aa73e9cba374f",nc=00000001,qop=auth,alg
orithm=MD5.
Content-Length: 0.
.
U Target_of_Treplicate:5060 -> OriginatingServer:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bKe47f.4bd99ca4.0.
Via: SIP/2.0/UDP
192.168.0.176:45374;received=193.227.186.146;branch=z9hG4bK-d87543-00509
f6c6f4a047f-1--d87543-;rport=45374.
To:
"9613041705"<sip:9613041705@OriginatingServer>;tag=991a35e6ab26c1f4ea62d
e8176a0818c.502f.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7d242230.
Call-ID: MmE3MTlmZDhiYWI0NjNmZjI5NWU5Njg1MmNhNDUwMDU..
CSeq: 6 REGISTER.
Server: OpenSER (1.3.2-notls (i386/linux)).
Content-Length: 0.
.
U OriginatingServer:5060 -> Target_of_Treplicate:5060
REGISTER sip:OriginatingServer SIP/2.0.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK4cef.3d1bfc.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-221288
3e6a0dc710-1--d87543-;rport=7988.
Max-Forwards: 69.
Contact: <sip:9613041705@192.168.0.176:7988;rinstance=c1ac0eda25c39951>.
To: "9613041705"<sip:9613041705@OriginatingServer>.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite release 1006e stamp 34025.
Authorization: Digest
username="9613041705",realm="sero.ahwar.net",nonce="484653c5b066afdc9b4d
3bc20faa9e549e1bbe93",uri="sip:OriginatingServer",response="fc7ee7ed4e3c
68f85de2a298f7579421",cnonce="42f3c2c5b71b4623",nc=00000001,qop=auth,alg
orithm=MD5.
Content-Length: 0.
.
U Target_of_Treplicate:5060 -> OriginatingServer:5060
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK4cef.3d1bfc.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-221288
3e6a0dc710-1--d87543-;rport=7988.
To:
"9613041705"<sip:9613041705@OriginatingServer>;tag=991a35e6ab26c1f4ea62d
e8176a0818c.7860.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 2 REGISTER.
Contact:
<sip:9613041705@192.168.0.176:7988;rinstance=c1ac0eda25c39951>;expires=5
67.
P-Registrar-Error: Invalid CSeq number.
Server: OpenSER (1.3.2-notls (i386/linux)).
Content-Length: 0.
.
U OriginatingServer:5060 -> Target_of_Treplicate:5060
REGISTER sip:OriginatingServer SIP/2.0.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK5cef.dfe76626.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-022b94
01307f967e-1--d87543-;rport=7988.
Max-Forwards: 69.
Contact:
<sip:9613041705@192.168.0.176:7988;rinstance=c1ac0eda25c39951>;expires=0
.
To: "9613041705"<sip:9613041705@OriginatingServer>.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 3 REGISTER.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite release 1006e stamp 34025.
Authorization: Digest
username="9613041705",realm="sero.ahwar.net",nonce="484653c5b066afdc9b4d
3bc20faa9e549e1bbe93",uri="sip:OriginatingServer",response="9ded822006fa
51735838d3fdea96800b",cnonce="68a12fcb5c00aeaf",nc=00000002,qop=auth,alg
orithm=MD5.
Content-Length: 0.
.
U Target_of_Treplicate:5060 -> OriginatingServer:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK5cef.dfe76626.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-022b94
01307f967e-1--d87543-;rport=7988.
To:
"9613041705"<sip:9613041705@OriginatingServer>;tag=991a35e6ab26c1f4ea62d
e8176a0818c.93c8.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 3 REGISTER.
Server: OpenSER (1.3.2-notls (i386/linux)).
Content-Length: 0.
.
U OriginatingServer:5060 -> Target_of_Treplicate:5060
REGISTER sip:OriginatingServer SIP/2.0.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK2cef.bec40741.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-ea14ff
1ac524e10c-1--d87543-;rport=7988.
Max-Forwards: 69.
Contact:
<sip:9613041705@193.227.186.146:7988;rinstance=7d4ba8842a9e4a7e>.
To: "9613041705"<sip:9613041705@OriginatingServer>.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 4 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite release 1006e stamp 34025.
Authorization: Digest
username="9613041705",realm="sero.ahwar.net",nonce="484653c5b066afdc9b4d
3bc20faa9e549e1bbe93",uri="sip:OriginatingServer",response="f126d934be4b
12c32a8ec783097a2ff6",cnonce="e3d03c6f36863764",nc=00000003,qop=auth,alg
orithm=MD5.
Content-Length: 0.
.
U Target_of_Treplicate:5060 -> OriginatingServer:5060
SIP/2.0 400 Bad Request.
Via: SIP/2.0/UDP OriginatingServer;branch=z9hG4bK2cef.bec40741.0.
Via: SIP/2.0/UDP
192.168.0.176:7988;received=193.227.186.146;branch=z9hG4bK-d87543-ea14ff
1ac524e10c-1--d87543-;rport=7988.
To:
"9613041705"<sip:9613041705@OriginatingServer>;tag=991a35e6ab26c1f4ea62d
e8176a0818c.5d32.
From: "9613041705"<sip:9613041705@OriginatingServer>;tag=7f0b7450.
Call-ID: MGJhNmM1ZDdlZmNmNWQ2ODZkOWE4YWEwNzkzNmEzMzA..
CSeq: 4 REGISTER.
Contact:
<sip:9613041705@193.227.186.146:7988;rinstance=7d4ba8842a9e4a7e>;expires
=566.
P-Registrar-Error: Invalid CSeq number.
Server: OpenSER (1.3.2-notls (i386/linux)).
Content-Length: 0.
.
Hi Eric,
To be honest, no, I haven;t, because I do not have access to such a
machine. Could you post the errors you get now?
Regards,
Bogdan
wliangy(a)gmail.com wrote:
> Thanks!
> But there is still problem.
> May I ask whether you have compiled successfully on Solaris 8 or 10?
>
> 2008/5/26 Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>:
>
>> Hi Eric,
>>
>> use "gmake" and not "make" on Solaris.
>>
>> Regards,
>> Bogdan
>>
>> wliangy(a)gmail.com wrote:
>>
>>> Hi experts,
>>> I am start user of openser and need use openser to support sctp.
>>> now I have download the source codes of openser-1.3.1-tls.
>>> then I compiled it, there have many errors that need your supports.
>>>
>>> e.g.
>>> openser-1.3.1-tls> make all
>>> Makefile.defs:717: *** missing separator. Stop.
>>>
>>> then I commented Makefile.defs line717 and 718.
>>> # $(warning Old gcc detected ($(CC_SHORTVER)), use
>>> gcc >= 3.1 \
>>> # for better results)
>>>
>>> Errors were still there.
>>>
>>> openser-1.3.1-tls> make all
>>> Makefile:402: warning: overriding commands for target
>>> `/opt/CiscoMGC$(DESTDIR)'
>>> Makefile:393: warning: ignoring old commands for target
>>> `/opt/CiscoMGC$(DESTDIR)'
>>> yacc -d -b cfg cfg.y
>>> "cfg.y", line 391: warning: redeclaration of precedence of SLASH.
>>>
>>> conflicts: 1 shift/reduce
>>> flex cfg.lex
>>> statistics.c:58: warning: #warning STATISTICS: Architecture with no
>>> support for atomic operations. Using Locks!!
>>> Makefile:402: warning: overriding commands for target
>>> `/opt/CiscoMGC$(DESTDIR)'
>>> Makefile:393: warning: ignoring old commands for target
>>> `/opt/CiscoMGC$(DESTDIR)'
>>> Compiling action.c
>>> gcc -g -O9 -funroll-loops -Wall -mv8 -DNAME='"openser"'
>>> -DVERSION='"1.3.1-notls"' -DARCH='"sparc64"' -DOS='"solaris"'
>>> -DCOMPILER='"gcc 2.91.66"' -D__CPU_sparc64 -D__OS_solaris -D__SMP_no
>>> -DCFG_DIR='"$(DESTDIR)/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
>>> -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024
>>> -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD
>>> -DHAVE_ALLOCA_H -DUSE_SIGACTION -D_POSIX_PTHREAD_SEMANTICS
>>> -DHAVE_DEVPOLL -DHAVE_SELECT -c action.c -o action.o
>>> parser/msg_parser.h: In function `char_msg_val':
>>> In file included from action.h:27,
>>> from action.c:44:
>>> parser/msg_parser.h:300: parse error before `)'
>>> forward.h: In function `msg_send':
>>> In file included from action.c:49:
>>> forward.h:95: parse error before `)'
>>> forward.h:103: parse error before `)'
>>> forward.h:107: parse error before `)'
>>> mem/../lock_alloc.h: In function `lock_set_alloc':
>>> In file included from mem/../locking.h:66,
>>> from mem/../statistics.h:115,
>>> from mem/shm_mem.h:33,
>>> from ut.h:52,
>>> from action.c:54:
>>> mem/../lock_alloc.h:68: parse error before `)'
>>> ut.h: In function `int2bstr':
>>> In file included from action.c:54:
>>> ut.h:172: parse error before `)'
>>> ut.h: In function `un_escape':
>>> ut.h:365: parse error before `)'
>>> ut.h: In function `shm_str_dup':
>>> ut.h:498: parse error before `)'
>>> ut.h: In function `pkg_str_dup':
>>> ut.h:515: parse error before `)'
>>> ut.h: In function `str_strcmp':
>>> ut.h:532: parse error before `)'
>>> ut.h:535: parse error before `int'
>>> ut.h:539: `minlen' undeclared (first use in this function)
>>> ut.h:539: (Each undeclared identifier is reported only once
>>> ut.h:539: for each function it appears in.)
>>> ut.h:547: `alen' undeclared (first use in this function)
>>> ut.h:547: `blen' undeclared (first use in this function)
>>> ut.h: In function `str_strcasecmp':
>>> ut.h:563: parse error before `)'
>>> ut.h:566: parse error before `int'
>>> ut.h:570: `minlen' undeclared (first use in this function)
>>> ut.h:578: `alen' undeclared (first use in this function)
>>> ut.h:578: `blen' undeclared (first use in this function)
>>> action.c: In function `run_action_list':
>>> action.c:140: parse error before `)'
>>> action.c: In function `do_assign':
>>> action.c:193: parse error before `)'
>>> action.c:202: parse error before `)'
>>> action.c:222: parse error before `)'
>>> action.c:228: parse error before `)'
>>> action.c: In function `do_action':
>>> action.c:302: parse error before `)'
>>> action.c:309: parse error before `)'
>>> action.c:335: parse error before `)'
>>> action.c:498: parse error before `)'
>>> action.c:524: parse error before `)'
>>> action.c:682: parse error before `)'
>>> action.c:710: parse error before `)'
>>> action.c:723: parse error before `)'
>>> action.c:757: parse error before `)'
>>> action.c:763: parse error before `)'
>>> action.c:807: parse error before `)'
>>> action.c:819: parse error before `)'
>>> action.c:870: parse error before `)'
>>> action.c:896: parse error before `)'
>>> action.c:904: parse error before `)'
>>> action.c:930: parse error before `)'
>>> action.c:939: parse error before `)'
>>> action.c:945: parse error before `)'
>>> action.c:966: parse error before `)'
>>> make: *** [action.o] Error 1
>>>
>>> Your any help is much appreciated!
>>>
>>> BR,
>>> Eric
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>
>
Hello,
If I want to have the ability to add a new branch for every negative response, included the 6xx (and despite what is written in the RFC3261), where should I change?
It is enough to remove the following code in t_should_relay_response function?
783 if (new_code>=600) {
784 /* this is a winner and close all branches */
785 which_cancel( Trans, cancel_bitmap );
786 picked_branch=branch;
787 /* no more new branches should be added to this transaction */
788 Trans->flags |= T_NO_NEW_BRANCHES_FLAG;
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
Hello,
I am trying to configure a number of openser servers.
I have the following testbed:
Phone1 + Proxy - Registrar - out proxy
Phone2/
The Proxy acts as outbound proxy for customers and uses ienum to route
messages to the right registrar (using user@domain), the registrar then
figures out where the destination is and sends the packet out to
ENUM/PSTN or in my case back to the same proxy.
The proxy is running nathelper (and redirects rtp to an rtp proxy) and
performs route-recording.
The proxy configuration has:
modparam("path", "use_received", 0)
and the registrar configuration contains:
modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)
When registering all is fine and well and the packet flows like:
Phone<X> -> Proxy -> Registrar (storing in DB) -> Proxy -> Phone<X>
and the DB contains in path:
<sip:ProxyIP;lr;received=sip:PhoneIP:PhonePort>
However, when performing an invite the ACK packet (INVITE/OK/ACK) can
not be routed properly as it is not part of the transaction, which
causes the call to be cancelled after a few seconds (as it should be
given the constance).
The ACK packet starts as
URI: <sip:user@<Registrar IP>:5060;rinstance=xxxxxx>
Contact: <sip:user@PhoneIP:PhonePort>
with the IP and Port correctly translated from the internal to the
firewall external.
It then travels like this:
Phone1 -> Proxy -> Registrar > Proxy <stop here>
When leaving Registrar the ACK URI has been changed to the one stored in
the DB path field ie: <sip:ProxyIP;lr;ftag=yyyyyy>
at that point the Proxy is not able to figure out where to forward the
packet even if the Contact field of the packet is still correctly set to
the IP:Port of the phone to be reached.
I was wondering if I am missing some understanding of how RFC3327 is
working.
I can see a few possible solutions:
- generate a first Path header with the Phone information on the proxy
before the current one.
- try to catch those 'out of transaction ACK' and set the URI to the contact
But before doing anything I would appreciate if someone could let me
know if I am attempting something idiotic from a design point of view
and tell me why what I expected to 'just work' does not behave as expected.
Thank you very much your your time and help.
Thomas
Hi,
Thanks to Anca Vamanu < anca at voice-system dot ro> , the auth module
has a new mechanism for protecting the nonce against third party attacks.
So far, the auth module provided only nonce lifetime limitation to
prevent re-usage of the nonce. The new mechanism offers protection
against sniffing intrusion. The module generates and verifies the nonces
so that they can be used only once (in an auth response). This is done
by having a lifetime value and an index associated with every nonce.
Using only an expiration value is not good enough because,as this value
has to be of few tens of seconds, it is possible for someone to sniff on
the network, get the credentials and then reuse them in another packet
with which to register a different contact or make calls using the
other's account. The index ensures that this will never be possible
since it is generated as unique through the lifetime of the nonce.
What problem is solved:
========================
Typical intrusion scenario is:
1) UAC sends INVITE with no credentials
2) openser sends challenge to UAC
3) UAC sends INVITE with credentials (lifetime 1 minute)
4) the credentials (auth response) are exposed on the net, so anybody
can grab them (lets assume by person X)
5) openser accepts the credentials and call is establish
6) person X injects (by sending to openser) an re-INVITE (to change the
media destination, for example) by re-using the credentials that he
grabbed from the net.
7) credentials are accepted by openser if the lifetime is not expired.
So, third parties can modify (or even initiate) dialogs by re-using the
credentials they captures from a previous authentication. The only
limitation is the nonce lifetime which is about 30 - 60 seconds, long
enough for allowing such an atack.
The new mechanism, by blocking the re-usage of the same nonce (even if
the lifetime is still valid), will block step 7) as the same nonce was
used in step 5) (by UAC).
Technical details:
==================
The auth module keeps state for each nonce - to validate it only on the
first usage. A binary array (which can by default accomodate 100K
nonces) is used to keep the state. An index in this array is allocated
when the challenge is generated; this index in kept for the whole life
duration of the nonce. After the first auth result (for the nonce), the
following auth results for that nonce are discarded and re-challenged.
As nonce can be generated and later checked from different processes,
the nonce state (binary array) is kept in shm memory and the access to
it is synchronized via locking.
The see what is the overhead added by the computation time (keeping the
nonce state) and locking (sharing between processes), Anca run several
of tests :
- openser single process
- openser multiple processes, single processor machine
- openser multiple processes, multi processor machine
For tests we were using authentication via PV (for password and
username) to avoid using any slow data backend (radius or DB) that might
eclipse the overhead.
The measured overhead is 4% - 7% (from the original version).
Regards,
Bogdan
Hi All,
Could someone tell me how to config openser 1.3.x route to support PRACK?
I had installed openser 1.3.x and didn't change any route configuration.
My scenario is:
A openser B
| --> INVITE (with 100rel) -> | --> INVITE (with 100rel) --> |
| | |
| <--183 <-- | <-- 183 <-- |
|
| --> PRACK --> |
| <-- 404 Not here <--- |
For the default the openser reply the "404 Not here" to A. I found the '404' was replied here:
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accouting ...
setflag(3); # ... even if the transaction fails
}
route(1);
} else {
/* !loose_route */
/* uncomment the following lines if you want to enable presence */
##if (is_method("SUBSCRIBE") && $rd == "your.server.ip.address") {
## # in-dialog subscribe requests
## route(2);
## exit;
##}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard.\n");
exit;
}
## These code will cause openser reply 483 response to PRACK
if ( is_method("PRACK") ) {
t_relay();
exit;
}
}
## Here reply me the 404
sl_send_reply("404","Not here");
}
exit;
}
Than I added the green code to route the PRACK, But I received "483","Too Many Hops" from openser. And I found the Max-Forward is 70 not a wrong value.
Does anyone can help me?
Best regards,
Steven Wu