please unsubscribe me from this group...........
On 6/5/07, Iliff, Tina <[EMAIL PROTECTED]> wrote: > > 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 > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
