Bogdan,
The problem is still there and actually I can't see any difference.
0(14899) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) INVITE: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) CANCEL: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1083 0(14899) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1083
ngrep shows that CANCEL is never get sent to the user xyz_100_1_st2 at 192.168.76.250:1083
Michael
On Monday 15 August 2005 01:03 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus