Hi, >>>>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote:
>> This have some sense (but we shall say again - not in security >> context). Imagine two different NATs and two agents behind them, >> both on address 192.168.1.1, and with monotonic branch numeration >> (z9hG4bK1, z9hG4bK2, z9hG4bK3...) If rule is "compare sent-by", >> their branches will mix. > It expected that branch value is so random and big that it can't be > repeated, isn't? It's recommended, as the simplest path to satisfy the requirement, but the real requirement is simply === cut here === The branch parameter value MUST be unique across space and time for all requests sent by the UA. === end cut === so we can imagine e.g. stable storage (NVRAM) of mototonically increased number of 64 bits:) > However I think we can expect that there will be > never two identical branch values coming from same public IP at the > same time. One public IP of NAT is good case to have pool of identical UAs. >> Correct matching shall take all four >> known identifiers (sent-by.host, sent-by.port, received, rport), >> and I'm unsure it was really correct to drop all another >> identifiers from matching (according to RFC2543); >> as minimum, we >> can add call-id, from_tag and CSeq number to matching, because >> none other rule allows to change them inside transaction. > Sure, but wouldn't make it too much "expensive"? Yes, for some applications, as fast proxy, it can be too expensive. But such application still needs some way to calculate branch uniquely. We have got problem with SER 0.9 which calculates branch as hash of raw text of some header fields, and if UA sends to_tag of provisional response in CANCEL (this is very common error), or makes some other change in header (one case was - UA which prepends <url> in h_From with space in INVITE but doesn't this in CANCEL) SER makes another branch ID when resends such CANCEL and we are unable to match it to INVITE. For such cases, I expect matching in RFC2543 style is more working.:) I don't know whether is this fixed in modern SER. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
