Ben, No, in your example the stateless proxy should use 'B' as a branch for the top Via in the CANCEL it forwards, not 'ZZ'. See RFC3261 section 16.6 point 8 (which implies it should not use random branch values).
In fact, it is recommended that stateless proxies simply copy the branch parameter from the top via in the received request. See http://bugs.sipit.net/show_bug.cgi?id=755 for details. So in your example, both the INVITE and the CANCEL should have two times 'via A' when they arrive at the stateful proxy The receiver ~always~ uses the topmost via branch as a transaction id, unless it doesn't start with the magic cookie. This does not depend on the type of method Regards, jeroen ----- Original Message ----- From: "Ben Papworth" <[EMAIL PROTECTED]> To: "Jeroen van Bemmel" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, February 22, 2006 7:07 PM Subject: Re: [Sip-implementors] Stateful Proxies Forwarding CANCELs > Hi Jeroen, > Thanks for the clarification, it's very helpful. > > Ok, so let's make it a bit more complicated. If there is a stateless proxy > in the chain, for example: > > UA Stateless Stateful UA > Proxy Proxy > > > Initial Request > INVITE INVITE INVITE INVITE > via A --> via B --> via C --> via D > via A via B via C > via A via B > via A > > So, the CANCEL will look like this - > CANCEL CANCEL via A --> via ZZ --> > via A > > 200 OK 200 OK (Stateful proxy sends response back) > <-- via A <-- via ZZ > via A > > CANCEL (Stateful proxy forwards CANCEL to next hop) > via C --> > 200 OK > <-- via C > > The point I'm trying to clarify here is that the receiver of the CANCEL > should use the branch id of the final via header to identify the > transaction, as stateless elements sitting in between will handle the > CANCEL in an end-to-end fashion, rather than hop-by-hop. > > Am I interpreting RFC3261 correctly here too? > > Thanks. > > Best Regards, > Ben > > Jeroen van Bemmel wrote: >> Ben, >> >> It also applies to proxies. So if you have the following scenario: >> >> UA->proxy >> INVITE >> Via: branch=b1 >> >> proxy->onwards >> INVITE >> Via: branch=b2 >> Via: branch=b1 >> >> then if UA sends CANCEL, it becomes >> >> UA->proxy >> CANCEL >> Via: branch=b1 >> >> proxy->onwards >> CANCEL >> Via: branch=b2 <= Note: only 1 Via header here >> >> When the proxy starts forking, each forwarded INVITE gets its own branch. >> So for two targets {A,B} it becomes: >> >> proxy->onwards_A >> INVITE >> Via: branch=b2 >> Via: branch=b1 >> >> proxy->onwards_B >> INVITE >> Via: branch=b3 >> Via: branch=b1 >> >> A subsequent CANCEL must have matching top branch again, so <b2> towards >> A and <b3> towards B >> >> Hope this clarifies, >> >> jeroen >> >> >> ----- Original Message ----- From: "Ben Papworth" >> <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Wednesday, February 22, 2006 4:40 PM >> Subject: [Sip-implementors] Stateful Proxies Forwarding CANCELs >> >> >>> Hi, >>> >>> I'm currently writing a call stateful SIP proxy. I've got a question >>> about how I should handle CANCELs... >>> >>> The SIP book (SIP: Understanding the Session Initiation Protocol) says >>> that CANCELs should have the same branch id as the request that's being >>> cancelled. Does this only apply to the UA that created the request and >>> issued the CANCEL, or should intermediate proxies use the same branch id >>> their via header for both the forwarded request and the forwarded >>> CANCEL? >>> >>> This proxy may also be capable of forking requests at a later date. In >>> this instance, is it desirable to use the same branch ids for requests >>> and their CANCELs? >>> >>> Thanks for any help! >>> >>> Best Regards, >>> Ben Papworth >>> >>> >>> >>> _______________________________________________ >>> 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
