It looks like the listen and alias statement are properly configured and your openser will likely detect the CANCEL targeted to itself (check the logs). The "problem" is that if you do not add a port to the listen|alias then openSER assumes that the server is listening to all ports. This leads to problems when you have other SIP entities colocated to openSER in the same machine. If you do add port to the listen|alias then ONLY those ports will match the myself condition.

From your config file you would match ALL ports because you have the

alias set to 10.200.0.228. There was recently a thread about aliases in openser, you might find more info there...

From the dokuwiki:

"It is necessary to include the port (the value used in the "port=" defintion) in the alias definition otherwise the loose_route() function will not work as expected for local forwards"

So add the 5060 port to the alias and check if it is solved.

About the second problem....it's been a long time since I last checked it so I might be totally wrong and the core developers should provide you more info. The CANCEL matching is something really inside openSER and requires quite changes in the core. I repeat that this might be solved because in SER it has been done so somebody might have ported it to openSER.

Hope it helps, Samuel.

2006/5/4, unplug maillisting@gmail.com:

Here is the alias and listen statements.

listen=10.200.0.228:5060 # INSERT YOUR IP ADDRESS HERE listen=10.200.0.228:6060 # INSERT YOUR IP ADDRESS HERE listen=210.14.7.5:5060 # INSERT YOUR IP ADDRESS HERE listen=210.14.7.5:6060 # INSERT YOUR IP ADDRESS HERE port=5060 children=16

dns=no rev_dns=no alias=o6.ol.com alias=10.200.0.228 alias=210.14.7.5

In the server, there are 2 interfaces (internal and external). I put both of them in the alias and listen statement. Anything wrong here?

Why openSER fail to recognize the request (CANCEL) as targeted to itself? How do you solve and prevent this problem? As the performance of the server will degrade when this loop happen. It must be a way to prevent it otherwise users connected to the system will be affected. reduce the time-out parameter? reduce the number of hops?

Thanks for help!

On 5/4/06, samuel samu60@gmail.com wrote:

...

What do you have in the alias and in the listen statements??

Sometimes I found similar behaviour and a 483 Too Many Hops at the end when openSER does not recognize the request (CANCEL) as targeted to itself. The problem is that 10.200.0.228 does not validates against the myself statement and the server sends the request to the IP present in the Req-URI, which happens to be the openSER IP address. This proceeding is repeated until the Too Many Hops is reached.

There was another issue with CANCEL to INVITE transactions which have not finished (no reply>199 received) because the CANCEL does not match the transaction when the caller "hangs up" before the callee "picks up the phone". I think this is more a openSER internal issue which might have been solved...apologies if this issue has been closed.

Hope it helps, Samuel.

2006/5/4, unplug maillisting@gmail.com:

...

I have experienced a problem (looping problem?) in the system. From the log (ngrep) below, the cancel message issues a loop and it will affect the performance of the system. User can't dial/receive call after the loop happened.

How and why this loop will created? Does it related to the rtpproxy that I am using in the system? Any one can give me some hints?

Thanks, unplug

Note: 10.200.0.228 is an openser server.

filter: (ip) and ( port 5060 ) U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85234163634@10.200.0.228 SIP/2.0. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.3ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.2ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.1ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.0ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.fefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.eefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.defb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.cefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.befb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.aefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.9efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.8efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.7efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.6efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.4efb2934.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKrmPCJR8Xm6JKY4o8. Max-Forwards: 55. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" sip:871966760539@10.200.0.228;tag=ckRP8FNJugUqMOjy. To: "85234163634" sip:85234163634@10.200.0.228. Call-ID: WfigvZ4YJatMKamV@10.0.0.92. Contact: sip:871966760539@10.0.0.92:5060. CSeq: 1 CANCEL. Content-Length: 0. .

# U 10.200.0.228:5060 -> 10.200.0.228:5060 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.201bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.101bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.001bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.ff0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.ef0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.df0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.cf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.bf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.af0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.9f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.8f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.7f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.6f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.5f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.4f0bae66.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKjMEHTGhvWKHZ0R2J. From: "871966760539" sip:871966760539@10.200.0.228;tag=SM4dtzpkDKYyCkzu. To: "8521878200" sip:8521878200@10.200.0.228;tag=4cdbaed0e769eb1d9b81f5252847cf64-3d33. Call-ID: nQCHB6bq42pOheks@10.0.0.92. CSeq: 1 CANCEL. Server: OpenSer (1.0.1 (i386/linux)). Content-Length: 0. Warning: 392 10.200.0.228:5060 "Noisy feedback tells: pid=3174 req_src_ip=10.200.0.228 req_src_port=5060 in_uri=sip:8521878200@10.200.0.228 out_uri=sip:8521878200@10.200.0.228 via_cnt==0". .

######## U 10.200.0.228:5060 -> 10.200.0.228:5060 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.bf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.af0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.9f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.8f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.7f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.6f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.5f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.4f0bae66.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKjMEHTGhvWKHZ0R2J. From: "871966760539" sip:871966760539@10.200.0.228;tag=SM4dtzpkDKYyCkzu. To: "8521878200" sip:8521878200@10.200.0.228;tag=4cdbaed0e769eb1d9b81f5252847cf64-ab74. Call-ID: nQCHB6bq42pOheks@10.0.0.92. CSeq: 1 CANCEL. Server: OpenSer (1.0.1 (i386/linux)). Content-Length: 0. Warning: 392 10.200.0.228:5060 "Noisy feedback tells: pid=3174 req_src_ip=10.200.0.228 req_src_port=5060 in_uri=sip:8521878200@10.200.0.228 out_uri=sip:8521878200@10.200.0.228 via_cnt==0". .

########### U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85292558811@10.200.0.228 SIP/2.0. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.edcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.ddcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.adcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.5dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.4dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.3dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.2dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.1dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.0dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.fccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.eccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.dccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.accf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6ccf03a7.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKlpjLoMyFjsI1BvQL. Max-Forwards: 45. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" sip:871966760539@10.200.0.228;tag=MySoSexGPE0vUXa5. To: "85292558811" sip:85292558811@10.200.0.228. Call-ID: 8p3FIbMUfYMXOuW3@10.0.0.92. Contact: sip:871966760539@10.0.0.92:5060. CSeq: 1 CANCEL. Content-Length: 0. .

### U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85234163634@10.200.0.228 SIP/2.0. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Record-Route: sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.3ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.2ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.1ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.0ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.fefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.eefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.defb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.cefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.befb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.aefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.9efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.8efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.7efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.6efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.4efb2934.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKrmPCJR8Xm6JKY4o8. Max-Forwards: 55. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" sip:871966760539@10.200.0.228;tag=ckRP8FNJugUqMOjy. To: "85234163634" sip:85234163634@10.200.0.228. Call-ID: WfigvZ4YJatMKamV@10.0.0.92. Contact: sip:871966760539@10.0.0.92:5060. CSeq: 1 CANCEL. Content-Length: 0. .

######## U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85292558811@10.200.0.228 SIP/2.0. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Record-Route: sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.adcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.5dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.4dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.3dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.2dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.1dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.0dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.fccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.eccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.dccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.accf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6ccf03a7.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKlpjLoMyFjsI1BvQL. Max-Forwards: 47. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" sip:871966760539@10.200.0.228;tag=MySoSexGPE0vUXa5. To: "85292558811" sip:85292558811@10.200.0.228. Call-ID: 8p3FIbMUfYMXOuW3@10.0.0.92. Contact: sip:871966760539@10.0.0.92:5060. CSeq: 1 CANCEL. Content-Length: 0. .

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

That's exactly what I mean and I don't know wether in 1.1 it's gonna be solved...Can any core developer shed some light on this??

The "best" way to solve this is to decrement Max-Forwards: header to a really low value (3 or 4 instead of the current minimum 16) BUT BE CAREFULL because you might have problems of failed sessions in remote proxies (it depends a lot on your topology and offered services). With this configuration your loop problem will reduce from the current 16 to 3 or 4.... I repeat THIS COULD INTRODUCE INTEROPERABIOLITY issues.....use it with care.

Another approach would be to increase the number of children so the probability that all openSER children get blocked is really low and the user experience is not affected. In this way you will just see from time to time the loop-effect on your logs and nothing more.

I can not provide you more info...hope I was not wrong and it helped you a little....

Samuel.

2006/5/5, unplug maillisting@gmail.com:

Thanks! Do you mean that the CANCEL matching problem (2nd problem) may be a bug in the openser core and may be solved in the 1.1 version? In the mean time, any suggestion to prevent it (in setting of configuration file) and how can you handle it? Just to want get more information about that problem.

On 5/4/06, samuel samu60@gmail.com wrote:

...

It looks like the listen and alias statement are properly configured and your openser will likely detect the CANCEL targeted to itself (check the logs). The "problem" is that if you do not add a port to the listen|alias then openSER assumes that the server is listening to all ports. This leads to problems when you have other SIP entities colocated to openSER in the same machine. If you do add port to the listen|alias then ONLY those ports will match the myself condition. From your config file you would match ALL ports because you have the alias set to 10.200.0.228. There was recently a thread about aliases in openser, you might find more info there... From the dokuwiki: "It is necessary to include the port (the value used in the "port=" defintion) in the alias definition otherwise the loose_route() function will not work as expected for local forwards"

So add the 5060 port to the alias and check if it is solved.

About the second problem....it's been a long time since I last checked it so I might be totally wrong and the core developers should provide you more info. The CANCEL matching is something really inside openSER and requires quite changes in the core. I repeat that this might be solved because in SER it has been done so somebody might have ported it to openSER.

Hope it helps, Samuel.

Daniel,

There was a thread in serdev with title "INVITE vs. CANCEL race condition" talking about this issue. After that Andrei modified the tm to solve this issue...

After re-reading that thread and what Daniel replied I could refresh my spoiled memory :P: The exact problem happens in two cases: *the CANCEL arrives BEFORE the INVITE, or *it arrives after but you are doing other high-cost processing steps (i.e., DNS lookup (ENUM)) before calling t_relay which will lead to process the CANCEL before creating the transaction.

So I was not fair talking about bugs and replies (1xx) in my previous answers to this thread, aplogies.

Samuel.

2006/5/5, Daniel-Constantin Mierla daniel@voice-system.ro:

Hello,

On 05/05/2006 10:17 AM, samuel wrote:

...

That's exactly what I mean and I don't know wether in 1.1 it's gonna be solved...Can any core developer shed some light on this??

can you give more details about this problem (web links, description ...).

CANCEL processing is a bit delicate, if you run stateful proxy, tm module takes care to forward the CANCEL to the adequate destination. But if the transaction does not exists, you may end in a loop, if the CANCEL processing does not follow same steps as INVITE.

For stateful proxy, you can check if the INVITE transaction still exists, and if not, drop the CANCEL, see: http://openser.org/docs/modules/1.1.x/tm.html#AEN461

Cheers, Daniel

...

The "best" way to solve this is to decrement Max-Forwards: header to a really low value (3 or 4 instead of the current minimum 16) BUT BE CAREFULL because you might have problems of failed sessions in remote proxies (it depends a lot on your topology and offered services). With this configuration your loop problem will reduce from the current 16 to 3 or 4.... I repeat THIS COULD INTRODUCE INTEROPERABIOLITY issues.....use it with care.

Another approach would be to increase the number of children so the probability that all openSER children get blocked is really low and the user experience is not affected. In this way you will just see from time to time the loop-effect on your logs and nothing more.

I can not provide you more info...hope I was not wrong and it helped you a little....

Samuel.

2006/5/5, unplug maillisting@gmail.com:

...

Thanks! Do you mean that the CANCEL matching problem (2nd problem) may be a bug in the openser core and may be solved in the 1.1 version? In the mean time, any suggestion to prevent it (in setting of configuration file) and how can you handle it? Just to want get more information about that problem.

On 5/4/06, samuel samu60@gmail.com wrote:

...

It looks like the listen and alias statement are properly configured and your openser will likely detect the CANCEL targeted to itself (check the logs). The "problem" is that if you do not add a port to the listen|alias then openSER assumes that the server is listening to all ports. This leads to problems when you have other SIP entities colocated to openSER in the same machine. If you do add port to the listen|alias then ONLY those ports will match the myself condition. From your config file you would match ALL ports because you have the alias set to 10.200.0.228. There was recently a thread about aliases in openser, you might find more info there... From the dokuwiki: "It is necessary to include the port (the value used in the "port=" defintion) in the alias definition otherwise the loose_route() function will not work as expected for local forwards"

So add the 5060 port to the alias and check if it is solved.

About the second problem....it's been a long time since I last checked it so I might be totally wrong and the core developers should provide you more info. The CANCEL matching is something really inside openSER and requires quite changes in the core. I repeat that this might be solved because in SER it has been done so somebody might have ported it to openSER.

Hope it helps, Samuel.

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

By analyzing the log created from ngrep, I have draft the following flow. http://fisher.no-ip.com/ngrep/loop.log In line 371, the looping occurs to openser itself. I wonder why openser loop the message itself. Do I need to do something in dial plan to prevent the looping? Any simply way to prevent it? Thanks!

UA (92) OPENSER (228) CISCO (215) -----------INV-------------> <--------trying------------ -------------INV-----------> -------------INV-----------> <----------trying------------ <----------trying------------ <----------183------------ <----------183------------ ---------CANCEL---------> ---------CANCEL---------> <------200 canceling------- <---------OK--------------- <---------487--------------- ---------ACK---------> <----------487------------ ---------CANCEL---------> <------200 canceling------- ---------ACK---------> ---------CANCEL---------> <------200 canceling------- ---------CANCEL---------> CANCEL (looping:line 371) CANCEL (looping) CANCEL (looping) CANCEL (looping) CANCEL (looping) 408 (looping) ...

On 5/10/06, unplug maillisting@gmail.com wrote:

Thanks for help. I have introduced the code below. Sometimes, I can see the logging message "CANCEL without matching transaction ... ignore and discard" in the log. It means it can handle the CANCAL/INVITE racing condition. However, the looping still occured after a series of INVITE/CANCEL operation.

route {

    xlog("L_INFO","---[$fU@MR]-$rm---\n");
    # -----------------------------------------------------------------
    # Sanity Check Section
    # -----------------------------------------------------------------
    if (!mf_process_maxfwd_header("10")) {
            sl_send_reply("483", "Too Many Hops");
            return;
    };

    if (msg:len > max_len) {
            sl_send_reply("513", "Message Overflow");
            return;
    };

    #------------------------------------------------------------------
    # Accounting section
    #------------------------------------------------------------------
    setflag(1);

    # -----------------------------------------------------------------
    # Record Route Section
    # -----------------------------------------------------------------
    if (method=="INVITE" && client_nat_test("3")) {
            # INSERT YOUR IP ADDRESS HERE
            record_route();
            add_rr_param(";nat=yes");
    } else if (method!="REGISTER") {
            record_route();
    };

    # -----------------------------------------------------------------
    # Call Tear Down Section
    # do not send to voicemail if BYE or CANCEL
    # is used to end call before user pickup or timeout
    # -----------------------------------------------------------------
    if (method=="BYE" || method=="CANCEL") {
            setflag(10);
            route(7);
            end_media_session();
    };
    if (method=="PRACK") {
            route(7);
    };

    # -----------------------------------------------------------------
    # Loose Route Section
    # -----------------------------------------------------------------
    if (loose_route()) {

            if (has_totag() && (method=="INVITE" || method=="ACK")) {

                    if (client_nat_test("3")||search("^Route:.*;nat=yes")){
                            setflag(6);
                            use_media_proxy();
                    };
            };

            route(1);
            return;
    };
    # -----------------------------------------------------------------
    # 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");
            };
            return;
    };

    if (method=="CANCEL") {
            if (!t_check_trans()) {
                    xlog("L_WARN","---CANCEL without matching

transaction ... ignore and discard.\n"); return; } route(1); return; } else if (method=="INVITE") { route(3); return; } else if (method=="REGISTER") { route(2); return; } else if (method=="ACK") { route(1); return; };

    lookup("aliases");
    if (uri!=myself) {
            route(4);
            route(1);
            return;
    };

    if (!lookup("location")) {
            sl_send_reply("404", "User Not Found");
            return;
    };

    route(1);

}

On 5/8/06, samuel samu60@gmail.com wrote:

...

Daniel,

There was a thread in serdev with title "INVITE vs. CANCEL race condition" talking about this issue. After that Andrei modified the tm to solve this issue...

After re-reading that thread and what Daniel replied I could refresh my spoiled memory :P: The exact problem happens in two cases: *the CANCEL arrives BEFORE the INVITE, or *it arrives after but you are doing other high-cost processing steps (i.e., DNS lookup (ENUM)) before calling t_relay which will lead to process the CANCEL before creating the transaction.

So I was not fair talking about bugs and replies (1xx) in my previous answers to this thread, aplogies.

Samuel.

2006/5/5, Daniel-Constantin Mierla daniel@voice-system.ro:

...

Hello,

On 05/05/2006 10:17 AM, samuel wrote:

...

That's exactly what I mean and I don't know wether in 1.1 it's gonna be solved...Can any core developer shed some light on this??

can you give more details about this problem (web links, description ...).

CANCEL processing is a bit delicate, if you run stateful proxy, tm module takes care to forward the CANCEL to the adequate destination. But if the transaction does not exists, you may end in a loop, if the CANCEL processing does not follow same steps as INVITE.

For stateful proxy, you can check if the INVITE transaction still exists, and if not, drop the CANCEL, see: http://openser.org/docs/modules/1.1.x/tm.html#AEN461

Cheers, Daniel

...

The "best" way to solve this is to decrement Max-Forwards: header to a really low value (3 or 4 instead of the current minimum 16) BUT BE CAREFULL because you might have problems of failed sessions in remote proxies (it depends a lot on your topology and offered services). With this configuration your loop problem will reduce from the current 16 to 3 or 4.... I repeat THIS COULD INTRODUCE INTEROPERABIOLITY issues.....use it with care.

Another approach would be to increase the number of children so the probability that all openSER children get blocked is really low and the user experience is not affected. In this way you will just see from time to time the loop-effect on your logs and nothing more.

I can not provide you more info...hope I was not wrong and it helped you a little....

Samuel.

2006/5/5, unplug maillisting@gmail.com:

...

Thanks! Do you mean that the CANCEL matching problem (2nd problem) may be a bug in the openser core and may be solved in the 1.1 version? In the mean time, any suggestion to prevent it (in setting of configuration file) and how can you handle it? Just to want get more information about that problem.

On 5/4/06, samuel samu60@gmail.com wrote:

...

It looks like the listen and alias statement are properly configured and your openser will likely detect the CANCEL targeted to itself (check the logs). The "problem" is that if you do not add a port to the listen|alias then openSER assumes that the server is listening to all ports. This leads to problems when you have other SIP entities colocated to openSER in the same machine. If you do add port to the listen|alias then ONLY those ports will match the myself condition. From your config file you would match ALL ports because you have the alias set to 10.200.0.228. There was recently a thread about aliases in openser, you might find more info there... From the dokuwiki: "It is necessary to include the port (the value used in the "port=" defintion) in the alias definition otherwise the loose_route() function will not work as expected for local forwards"

So add the 5060 port to the alias and check if it is solved.

About the second problem....it's been a long time since I last checked it so I might be totally wrong and the core developers should provide you more info. The CANCEL matching is something really inside openSER and requires quite changes in the core. I repeat that this might be solved because in SER it has been done so somebody might have ported it to openSER.

Hope it helps, Samuel.

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users