reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] cancel Client INVITE does not stopretransmitting

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 -----
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> 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> 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> 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 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 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 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 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
3.90 tid=5b66074fd95b973f cseq=INVITE contact=yffulf@xxxxxxxxxxxxxxxxxxxxxxxxxxx
m:5080 / 1 from(tu)^M
.............................................................

Regards,

Frank


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/



_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/



_______________________________________________
resiprocate-users mailing list
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature