Re: [reSIProcate-users] cancel Client INVITE does not stopretransmitting
I haven't analyzed this from every angle, but I think you're okay if you
stop retransmitting the INVITE under these circumstances. However,
you *do* need to keep the transaction around for a while. In fact,
because the response can be a 200, you need to run for at least a full
64*T1 before you discard the transaction (see Timer M, described in
draft-sparks-sip-invfix, for rationale).
I really think the solution here is that the application needs to track
outstanding INVITE requests -- even canceled ones -- until the stack
hands back a final response. (My recollection is that it always will,
even if the response is an internally-generated 408). That way, the
application can keep track of which sessions the user is no longer
interested. If the user has already attempted to cancel a session
initiation request, it's up to the application to squelch the GUI
indication. (Alternately, the application can keep track of which
sessions the user is still interested in, and render information only
for those transactions).
/a
Byron Campen wrote:
So, the problem with doing this is that the other side might send a
2xx, which we will just drop. The other side will then retransmit this
2xx, wasting resources. So you don't want to delete the transaction; you
want the right thing to happen if a 2xx comes in. But, I think we'll be
mostly ok if we stop retransmitting the INVITE. We have two cases here:
1) No provisional yet. If our first INVITE never made it to the other
end, nobody will care if we stop retransmitting (but, this is the less
likely event). If it did make it to the other end, the other end will
send a response of some sort soon. If it sends a provisional, and we get
it, we're supposed to stop retransmitting anyway. If it sends an
unreliable provisional and we _don't_ get it, we can run into a small
amount of trouble, where our transaction times out, and then a 2xx comes
in, which we drop, sending the other end into futile retransmissions. If
the other end sends a 2xx relatively soon, then everything will be ok.
2) Provisional received. Obviously, our INVITE made it, so we've stopped
retransmitting anyway.
Anyone else want to weigh in on this? Would it be acceptable for the
dropped unreliable provisional case I mentioned to happen occasionally?
Best regards,
Byron Campen
Same issue I had faced in my live project,
After cancel invite till 32 second invite getting retransmitted so
what happen even after 20 second client come back in network, he get
miscall indication on GUI.
What solution I have given:
1) DUM: send cancel to transaction layer even not get any 1xx response.
2) Transaction Layer: delete transaction if did not get 1xx response
else go normal way.
And now its working for me.
Thanks,
Parag Patel
----- Original Message -----
*From:* Byron Campen <mailto:bcampen@xxxxxxxxxxxx>
*To:* Scott Godin <mailto:sgodin@xxxxxxxxxxxxxxx>
*Cc:* resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>
*Sent:* Saturday, April 25, 2009 3:57 AM
*Subject:* Re: [reSIProcate-users] cancel Client INVITE does not
stopretransmitting
Hmm. Interesting. I'm going to have to mull this one over...
Best regards,
Byron Campen
I can't find anything explicit in the RFC for direction on this
one. I suppose though that it makes sense to stop re-transmitting
the INVITE. I'll look into this further.
Scott
On Thu, Apr 2, 2009 at 1:03 PM, fuliang yuan
<fuliangyuan@xxxxxxxxx <mailto:fuliangyuan@xxxxxxxxx>> wrote:
Scott,
CancelClientInvite transaction msg dose not cause resip stack
to send out CANCEL msg, but mark the transaction as bing
abandoned. It should stop retransmitting INVITE msg.
My question is why resip stack keep retransmitting the
canceled INVITE msg.
Thanks
Frank
On Thu, Apr 2, 2009 at 11:09 AM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx <mailto:sgodin@xxxxxxxxxxxxxxx>> wrote:
A cancel cannot be sent out unless a 100 trying or
provisional response has been received. From section 9.1
of RFC3261:
"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."
Scott
On Thu, Apr 2, 2009 at 11:48 AM, fuliang yuan
<fuliangyuan@xxxxxxxxx <mailto:fuliangyuan@xxxxxxxxx>> wrote:
Hi,
The resiprocate version is 1.4.1.
The call scenarios is to send INVITE and send
cancelClientInvite to stop retransmiting INVITE after
200 ms. There is no response from server.
But it did not stop it.
Here is the log:
STACK | 20090402-102959.127 | testClient |
RESIP:TRANSACTION | 3086866656 | Tran
sactionState.cxx:354 | Found matching transaction for
CancelClientInviteTransact
ion: 5b66074fd95b973f -> tid=5b66074fd95b973f [
ClientInvite/Calling unreliable
target=[ V4 0.0.0.0:0 <http://0.0.0.0:0>
UNKNOWN_TRANSPORT target domain=unspecified
mFlowKey=0 ]]^
M
STACK | 20090402-102959.127 | testClient |
RESIP:TRANSACTION | 3086866656 | Tran
sactionState.cxx:799 |
TransactionState::processClientInvite: CancelClientInvite
Transaction: 5b66074fd95b973f tid=5b66074fd95b973f [
ClientInvite/Calling unreli
able target=[ V4 0.0.0.0:0 <http://0.0.0.0:0>
UNKNOWN_TRANSPORT target domain=unspecified mFlowKey=
0 ]]^M
STACK | 20090402-102959.728 | testClient |
RESIP:TRANSACTION | 3086866656 | Tran
sactionState.cxx:354 | Found matching transaction for
Timer: Timer A 500 -> tid=
5b66074fd95b973f [ ClientInvite/Calling unreliable
target=[ V4 0.0.0.0:0 <http://0.0.0.0:0> UNKNOWN
_TRANSPORT target domain=unspecified mFlowKey=0 ]]^M
STACK | 20090402-102959.728 | testClient |
RESIP:TRANSACTION | 3086866656 | Tran
sactionState.cxx:799 |
TransactionState::processClientInvite: Timer: Timer A 500
tid=5b66074fd95b973f [ ClientInvite/Calling
unreliable target=[ V4 0.0.0.0:0 <http://0.0.0.0:0> UN
KNOWN_TRANSPORT target domain=unspecified mFlowKey=0 ]]^M
STACK | 20090402-102959.728 | testClient |
RESIP:TRANSACTION | 3086866656 | Tran
sactionState.cxx:951 | timer fired: TimerMessage
TransactionId[5b66074fd95b973f]
Type[Timer A] duration[500]^M
DEBUG | 20090402-102959.728 | testClient |
RESIP:TRANSACTION | 3086866656 | Time
rQueue.cxx:85 | Adding timer: Timer A
tid=5b66074fd95b973f ms=1000^M
INFO | 20090402-102959.728 | testClient |
RESIP:TRANSACTION | 3086866656 | Trans
actionState.cxx:962 | Retransmitting INVITE: SipReq:
INVITE 5557771234@xxxxxxxx <mailto:5557771234@xxxxxxxx>
3.90 tid=5b66074fd95b973f cseq=INVITE
contact=yffulf@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<mailto:yffulf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
m:5080 / 1 from(tu)^M
.............................................................
Regards,
Frank
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>
List Archive:
http://list.resiprocate.org/archive/resiprocate-users/
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
------------------------------------------------------------------------
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
__________ NOD32 4035 (20090425) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
------------------------------------------------------------------------
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/