[Users] CANCEL problem

[Michael Ulitskiy]

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 at 192.168.83.61 received from 192.168.80.26:5060
 0(14899) INVITE: cseq=102: looked up: sip:xyz_100_1_st2 at 192.168.0.249:5060 flags: 00000040
 0(14899) INVITE: cseq=102: sip:xyz_100_1_st2 at 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 at 192.168.83.61 received from 192.168.80.26:5060
 0(14899) CANCEL: cseq=102: looked up: sip:xyz_100_1_st2 at 192.168.0.249:5060 flags: 00000040
 0(14899) CANCEL: cseq=102: sip:xyz_100_1_st2 at 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 at 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
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>    
> >>
> >
> >  
> >
> 
>