[reSIProcate] Fw: CANCEL before provisional recieved.

[Volodymyr.Stepanov at aricent.com]

if (m_outgInviteMsg && !m_outgInviteMsg->isInvalid() 
                                && m_outgInviteMsg->isRequest()
                                && (pSession->GetState() != eUnreachable)
                                && (pSession->GetState() != eBusy)
                                && (pSession->GetState() != 
eDisconnected))
                        {
                                std::cout<<"CSipWorker::HangCall: Send 
cancel";
                                resip::SipMessage* pCancelMessage = 
resip::Helper::makeCancel(*m_outgInviteMsg);
 
                                resip::SharedPtr<resip::SipMessage> 
pShCancelMessage(pCancelMessage);
                                m_pDum->send(pShCancelMessage);
                                m_outgInviteMsg = NULL;
                                DebugLog(<< "CSipWorker::HangCall: Send 
cancel finished");
                        }


That's all application do to signal about tear down the call.(maybe 
something erong here too? :) )

Probably I should change my app architecture to provide ability to send 
"some sort of note-to-self to send a CANCEL once a provisional comes in",

Best regards,


MSN : stepanov_v_m at hotmail.com
ICQ : 272708933



Byron Campen <bcampen at estacado.net> 
07.05.2007 23:24

To
Volodymyr.Stepanov at aricent.com
cc
<resiprocate-devel at list.resiprocate.org>
Subject
Re: [reSIProcate] Fw:  CANCEL before provisional recieved.






What is your app doing to signal its intent to tear down the call?

Best regards,
Byron Campen


Yes,I'm using DUM ... 
Any suggestions? 

Best regards,

Volodymyr Stepanov



Byron Campen <bcampen at estacado.net> 
Sent by: resiprocate-devel-bounces at list.resiprocate.org
04.05.2007 18:05 


To
Volodymyr.Stepanov at aricent.com 
cc
resiprocate-devel <resiprocate-devel at list.resiprocate.org> 
Subject
Re: [reSIProcate] Fw:  CANCEL before provisional recieved.








Are you using DUM? I got the impression that this was not the case. 

Best regards, 
Byron Campen 
FYI - DUM should be handling all of this. 
  
From: resiprocate-devel-bounces at list.resiprocate.org [
mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Byron 
Campen
Sent: Friday, May 04, 2007 10:44 AM
To: Volodymyr.Stepanov at aricent.com
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] Fw: CANCEL before provisional recieved. 
  
          If you are going to freeze the CANCEL transaction, it needs to 
be done at the TU. So, if your app decides to end a call, it needs to put 
some sort of note-to-self to send a CANCEL once a provisional comes in, 
and if a final response comes in, to send a BYE. 
  
Best regards, 
Byron Campen 



Byron Campen <bcampen at estacado.net> 
04.05.2007 16:53 


To
Volodymyr.Stepanov at aricent.com 
cc
<resiprocate-devel at list.resiprocate.org> 
Subject
Re: [reSIProcate] Fw:  CANCEL before provisional recieved.
  








Sending a CANCEL before a provisional response is invalid behavior. Right 
now, the stack forges a CANCEL/200 and sends it to the TU, but does not 
allow the CANCEL to hit the wire. From here, if B never sends a 
provisional, the INVITE transaction will time-out, causing the stack to 
send a simulated INVITE/408. However, if B does respond, the call will 
continue normally. (This is something a TU must be prepared to handle; 
just because you get a CANCEL/200 doesn't mean the remote UAS will end the 
INVITE transaction.) If B does send a provisional, but never sends a final 
response, it is up to A to decide at what point it wishes to end the 
transaction. (The TU does this by sending a CANCEL; this will cause the 
stack to put a CANCEL on the wire, and start a timer that will cause the 
INVITE transaction to be torn down, if it never gets a response) 

Best regards, 
Byron Campen 





Lets try again :) 
B sends provisional,but there is large time gap between A INVITEs and  B 
receives this INVITE, and answers back. 
I know that sending CANCEL before provisional is incorrect. 
I trying to find "standart" solution for ,maybe, waiting for provisional 
or "freeze" CANCEL transaction. 
Maybe there is another way to deal with my problem? 
Thanks.

Sorry :) 

MSN : stepanov_v_m at hotmail.com
ICQ : 272708933_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
_______________________________________________ 
resiprocate-devel mailing list 
resiprocate-devel at list.resiprocate.org 
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
_______________________________________________ 
resiprocate-devel mailing list 
resiprocate-devel at list.resiprocate.org 
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
  

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel 
<smime.p7s>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070508/e1291d64/attachment.htm>