Subject: [Sipping] Proxy acting as UAS -- CANCEL scenario

From: "Iliff, Tina" <[email-masked]>
Date: Mon, 04 Jun 2007 20:37:48 +0000

All,

RFC3261 Section 16 states the following regarding Proxy Behavior:

Being a proxy is a logical role for a SIP element. When a request
arrives, an element that can play the role of a proxy first decides
if it needs to respond to the request on its own. For instance, the
request may be malformed or the element may need credentials from the
client before acting as a proxy. The element MAY respond with any
appropriate error code. When responding directly to a request, the
element is playing the role of a UAS and MUST behave as described in
Section 8.2.

Please consider the following call flow scenario:

OUA sends INVITE to Proxy
Proxy sends 100 Trying to OUA
Proxy routes INVITE to SBC
SBC sends 100 Trying to Proxy
SBC routes INVITE to TUA
SBC does not receive 100 Trying from TUA and retransmits INVITE several
times
OUA sends CANCEL to Proxy
Proxy responds to CANCEL with 200OK
Proxy routes CANCEL to SBC
SBC does not route CANCEL to TUA
A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE request to
OUA
Several seconds elapse and Timer B pops on the SBC and it sends a 408
back to the Proxy for the INVITE request
The proxy does not ACK the 408 response; therefore, the SBC retransmits
the 408 for 64*T1 seconds

Note:  The SBC is acting as a proxy and not a B2BUA

Question:  Is the proxy behaving correctly by sending the 487 response
to the INVITE request on its own?

Regards,

Tina Iliff

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP