Re: [OpenSIPStack] FW: Proxy - CANCEL Processing
Brought to you by:
joegenbaclor
Menu
▾
▴
Re: [OpenSIPStack] FW: Proxy - CANCEL Processing
|
From: Joegen E. B. <joe...@gm...> - 2007-08-03 21:53:05
|
Hi gustavo,
Thanks for all these patches. I will definitely going to look at them as =
soon as I get time. I might have some free time late next week.
Gustavo Curetti wrote:
> Hi Joegen:
>
> I added code to respond 200 ok to the CANCEL like the RFC3261 said:
> **
> *
>
> 16.10 CANCEL Processing
>
> **If a matching response context is found, the element MUST=20
> immediately return a 200 (OK) response to the CANCEL request*.
>
> In ProxySession::ValidateRequest():
>
> if(m_SessionManager.GetUserAgent().GetStack().CancelInviteServerTransac=
tion(m_Request))
> {
> SIPMessage ok;
> request.CreateResponse( ok, SIPMessage::Code200_Ok );
> SendRequest( ok );
> }
>
> Please check this if you have time.
>
> Thanks for your help
>
> Gustavo
>
>
>
> -------------------------------------------------------------------=
-----
> From: cur...@ho...
> To: ope...@li...
> Subject: FW: Proxy - CANCEL Processing
> Date: Thu, 2 Aug 2007 16:42:15 +0200
>
> Resending with compressed logs.
>
>
> -----------------------------------------------------------=
-------------
> From: cur...@ho...
> To: ope...@li...;
> jb...@so...; joe...@gm...
> Subject: Proxy - CANCEL Processing
> Date: Wed, 1 Aug 2007 22:32:29 +0200
>
> Hi Joegen:
>
> I was checking the cancel processing in Proxy Only Mode.
>
> From the RFC 3261:
>
> **
>
> *16.10 CANCEL Processing*
>
> A stateful proxy MAY generate a CANCEL to any other
> request it has generated at any time (subject to receiving
> a provisional response to that request as described in
> section 9.1). A proxy MUST cancel any pending client
> transactions associated with a response context when it
> receives a matching CANCEL request.
>
> A stateful proxy MAY generate CANCEL requests for pending
> INVITE client transactions based on the period specified
> in the INVITE=92s Expires header field elapsing. However,
> this is generally unnecessary since the endpoints involved
> will take care of signaling the end of the transaction.
>
> While a CANCEL request is handled in a stateful proxy by
> its own server transaction, a new response context is not
> created for it. Instead, the proxy layer searches its
> existing response contexts for the server transaction
> handling the request associated with this CANCEL. *_If a
> matching response context is found, the element _**_MUST
> immediately return a 200 (OK) response to the CANCEL
> _**_request_*. In this case, the element is acting as a
> user agent server as defined in Section 8.2. Furthermore,
> the element MUST generate CANCEL requests for all pending
> client transactions in the context as described in Section
> 16.7 step 10.
>
> If a response context is not found, the element does not
> have any knowledge of the request to apply the CANCEL to.
> It MUST statelessly forward the CANCEL request (it may
> have statelessly forwarded the associated request previousl=
y).
>
> From the RFC 3665:
>
> 3.8. Unsuccessful No Answer
> Alice Proxy 1 Proxy 2 Bob
> | | | |
> | INVITE F1 | | |
> |--------------->| INVITE F2 | |
> | 100 F3 |--------------->| INVITE F4 |
> |<---------------| 100 F5 |--------------->|
> | |<---------------| |
> | | | 180 F6 |
> | | 180 F7 |<---------------|
> | 180 F8 |<---------------| |
> |<---------------| | |
> | CANCEL F9 | | |
> |--------------->| | |
> | 200 F10 | | |
> |<---------------| CANCEL F11 | |
> | |--------------->| |
> | | 200 F12 | |
> | |<---------------| |
> | | | CANCEL F13 |
> | | |--------------->|
> | | | 200 F14 |
> | | |<---------------|
> | | | 487 F15 |
> | | |<---------------|
> | | | ACK F16 |
> | | 487 F17 |--------------->|
> | |<---------------| |
> | | ACK F18 | |
> | 487 F19 |--------------->| |
> |<---------------| | |
> | ACK F20 | | |
> |--------------->| | |
> | | | |
> In this scenario, Alice gives up on the call before Bob
> answers (sends a 200 OK response). Alice sends a CANCEL
> (F9) since no final response had been received from Bob.
> If a 200 OK to the INVITE had crossed with the CANCEL,
> Alice would have sent an ACK then a BYE to Bob in order to
> properly terminate the call.
>
> _Note that the CANCEL message is acknowledged with a 200
> OK on a hop by hop basis, rather than end to end._
>
> But the OpenSBC behavior in Proxy Mode is:
>
> Alice Proxy-OpenSBC Bob
> | INVITE | |
> |--------------->| INVITE |
> | 100 |--------------->|
> |<---------------| 180 |
> | 180 |<---------------|
> |<---------------| |
> | CANCEL | |
> |--------------->| |
> | 487 | |
> |<---------------| CANCEL |
> | ACK |--------------->|
> |--------------->| 200 |
> | |<---------------|
> | | 487 |
> | |<---------------|
> | | ACK |
> | 200 |--------------->|
> |<---------------| |
>
>
>
> I attached a log (CANCEL-OK.log) and a sip flow
> (CANCEL-OK.jpg).
>
> I have two problems with the cancel:
>
> -When the callee don't answer, the caller retransmit the
> cancel, because the OpenSBC don't send the 200 ok response
> for the cancel. Log: CANCEL-RETRANS.log , Sip Flow:
> CANCEL-RETRANS.jpg
>
> -When the callee send the 487(Request Cancelled) response
> for the INVITE before the 200 ok response for the CANCEL,
> the 200 ok is not been proxy by the OpenSBC. Log:
> CANCEL-NOTOK.log , Sip Flow: CANCEL-NOTOK.jpg. In the log,
> the sesion is deleted by the 487:
> :
>
> 222:22:52.761 DBG: [CID=3D0x0475] Finding transaction for
> SIP/2.0 487 Request Terminated
> 222:22:52.762 DBG: [CID=3D0x0475] Setting Transaction ID to=
> 955903155@192.168.0.60|z9hG4bKe531e528fbc6f89e|INVITE
> <mailto:955903155@192.168.0.60%7Cz9hG4bKe531e528fbc6f89e%7C=
INVITE>
> 222:22:52.762 DTL: [CID=3D0x0475] Found
> IST|955903155@192.168.0.60|z9hG4bKe531e528fbc6f89e|INVITE
> <mailto:IST%7C955903155@192.168.0.60%7Cz9hG4bKe531e528fbc6f=
89e%7CINVITE>
> for SIP/2.0 487 Request Terminated
> 222:22:52.763 DTL: [CID=3D0x0475] IST(800569658)
> Event(SIPMessage) - SIP/2.0 487 Request Terminated
> 222:22:52.763 DBG: [CID=3D0x0475] TRANSACTION: (IST) SIP/2.=
0
> 487 Request Terminated State: 3
> 222:22:52.764 DTL: [CID=3D0x06cb] *** QUEUED FOR DELETION
> *** SIPSession: 955903155@192.168.0.60
> <mailto:955903155@192.168.0.60>
> 222:22:52.764 DBG: [CID=3D0x0000] GC: First Stale Object
> ProxySession
> _222:22:52.765 ERR: [CID=3D0x0000] GC:
> .\src\ProxySession.cxx:601
> ProxySession::OnCheckRoutePolicy:: Attempt to
> CreateReference() a garbage collected pointer_
> _222:22:52.766 ERR: [CID=3D0x0000] GC:
> .\src\ProxySession.cxx:625 ProxySession::OnFinalResponse::
> Attempt to CreateReference() a garbage collected pointer_
>
> Any idea? Thanks for your help.
>
> Gustavo
>
>
>
>
>
>
>
> -----------------------------------------------------------=
-------------
> Descubre Live.com - tu propia p=E1gina de inicio,
> personalizada para ver r=E1pidamente todo lo que te interes=
a
> en un mismo sitio. todo en el mismo sitio.
> <http://www.live.com/getstarted>=20
>
>
> ---------------------------------------------------------------=
---------
> Env=EDa mensajes de correo electr=F3nico directamente a tu blog=
> con MSN. Carga chistes, fotograf=EDas y muchas otras cosas. Es
> gratis.
> <http://clk.atdmt.com/MSN/go/msnnksac0030000001msn/direct/01/?h=
ref=3Dhttp://www.imagine-msn.com/spaces>
>
>
>
> -------------------------------------------------------------------=
-----
> Comun=EDcate al instante con Windows Live Messenger Windows Live
> Messenger
> <http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Des=
-ar&source=3Djoinmsncom/messenger>
>
>
>
> -----------------------------------------------------------------------=
-
> Se uno de los primeros en probar Windows Live Mail. Windows Live Mail. =
> <http://ideas.live.com/programpage.aspx?versionId=3D5d21c51a-b161-4314-=
9b0e-4911fb2b2e6d>
|
