Thanks Guys! On Wed, Mar 11, 2009 at 12:38 PM, Bob Penfield <[email protected]>wrote:
> Section 17.3.2 of RFC 3261 says: > > If the branch parameter in the top Via header field is not present, > or does not contain the magic cookie, the following procedures are > used. These exist to handle backwards compatibility with RFC 2543 > compliant implementations. > > The INVITE request matches a transaction if the Request-URI, To tag, > From tag, Call-ID, CSeq, and top Via header field match those of the > INVITE request which created the transaction. In this case, the > INVITE is a retransmission of the original one that created the > transaction. The ACK request matches a transaction if the Request- > URI, From tag, Call-ID, CSeq number (not the method), and top Via > header field match those of the INVITE request which created the > transaction, and the To tag of the ACK matches the To tag of the > response sent by the server transaction. Matching is done based on > the matching rules defined for each of those header fields. > Inclusion of the tag in the To header field in the ACK matching > process helps disambiguate ACK for 2xx from ACK for other responses > at a proxy, which may have forwarded both responses (This can occur > in unusual conditions. Specifically, when a proxy forked a request, > and then crashes, the responses may be delivered to another proxy, > which might end up forwarding multiple responses upstream). An ACK > request that matches an INVITE transaction matched by a previous ACK > is considered a retransmission of that previous ACK. > > For all other request methods, a request is matched to a transaction > if the Request-URI, To tag, From tag, Call-ID, CSeq (including the > method), and top Via header field match those of the request that > created the transaction. Matching is done based on the matching > rules defined for each of those header fields. When a non-INVITE > request matches an existing transaction, it is a retransmission of > the request that created that transaction. > > Because the matching rules include the Request-URI, the server cannot > match a response to a transaction. When the TU passes a response to > the server transaction, it must pass it to the specific server > transaction for which the response is targeted. > > > Cheers, > (-:bob > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of cool goose > Sent: Wednesday, March 11, 2009 3:22 PM > To: [email protected] > Subject: [Sip-implementors] What should be the response from a Registrar if > the REGISTER request via header field has no "branch" parameter > > Hi, > > In RFC 3261 it is stated that: > > The Via header field value MUST > contain a branch parameter. This parameter is used to identify the > transaction created by that request. This parameter is used by both > the client and the server. > > > What do you guys think that a registrar should respond for a REGISTER > request whose Via header field has no "branch" parameter. > > > Thank You, > CoolGoose. > _______________________________________________ > 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
