Bogdan, The problem is still there and actually I can't see any difference.
0(14899) INVITE: cseq=102: ruri=sip:[EMAIL PROTECTED] received from 192.168.80.26:5060 0(14899) INVITE: cseq=102: looked up: sip:[EMAIL PROTECTED]:5060 flags: 00000040 0(14899) INVITE: cseq=102: sip:[EMAIL PROTECTED]:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) CANCEL: cseq=102: ruri=sip:[EMAIL PROTECTED] received from 192.168.80.26:5060 0(14899) CANCEL: cseq=102: looked up: sip:[EMAIL PROTECTED]:5060 flags: 00000040 0(14899) CANCEL: cseq=102: sip:[EMAIL PROTECTED]:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) ACK: cseq=102: ruri=sip:[EMAIL PROTECTED] 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 > >>>> > >>>> > >>>> > >>>> > >> > >> > > > > > > > > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
