David, see inline
Regards, jeroen ----- Original Message ----- From: "David Cutullic" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 10, 2006 11:10 AM Subject: [Sip-implementors] Should a cancel generate a new servertransaction ? > Hi, > > When a cancel is received from the network, should it be matched with a > new server transaction or with the server transaction of the initial > invite request ? > My interpretation is: both. A reasonable implementation could be the following: An incoming CANCEL should first be matched against ongoing CANCEL servertransactions. If one matches, the CANCEL is a retransmission, and the last response sent (probably a 200 OK) should be repeated. If no CANCEL ST matches, the CANCEL is matched against ongoing INVITE transactions (technically, CANCEL may apply to any request, but RFC3261 says it SHOULD NOT be used to cancel anything except INVITE. The INFO RFC recommends differently, but the resulting RACE conditions are bad, so IMO it's better not to do this) If an INVITE transaction matches, a proxy will cancel all outstanding branches for it. A UAS will send a 487 > When i read the chapter 17 of the rfc 3261, in understand than all the > request must create a transaction. > No, not always. You may have a stateless proxy or a transaction stateless UAS (although the RFC only talks about a stateless UAS in the sense of a UAS that does not maintain ~dialog~ state). There are other situations (e.g. authentication challenge) for which you might not want to create a transaction. > But I use the java NIST SIP implementation that don't match the cancel > request with a transaction. Is it an error of the implementation ? > In NIST, how it should work (though this is not very clearly documented) is that processRequest gives you the ServerTransaction of the original INVITE. The (proxy) application itself must then create a ServerTransaction for the CANCEL request. I have personally written a test to verify that the RI at least gives you the INVITE ST, and that works (not sure about retransmitted CANCELs) > Thanks for your attention > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
