El Martes, 15 de Julio de 2008, [EMAIL PROTECTED] escribió: > The fundamental problem is that the two requests will be sent from > different addresses/ports, and so should have different "sent-by" > parts in their first Via headers. The problems happen if we allow > them to have the same branch parameter value.
but that's not neccesary since a UAC could resend the request from same private IP (and set same "sent-by") but the retransmission could be routed by a different IP router (due to network issues). > Hi, imagine a UAC sending a request that arrives to UAS from > IP_A:port_A. Later the UAC closes the TCP connection or UDP link > and resend the *same* request (same "branch", "sent-by" and > "method") from IP_A:port_A (again). If UAC is behind NAT then "Via" > "received" and "rport" parameters could be different in both > identical requests because the outgoing port from the NAT is > different. That is, although the UAC *sent* the request from the > same address/port (and so used the same branch value), the > recipient sees it *coming from* a different address/port. > > Is it a valid retransmission? > > It seems that we must allow this. > > The consistent strategies for dealing with this are: > > The processes of 18.2.2 uses the *most recent* "received" and "rport" > parameter values that have been seen for this transaction. > > If multiple values for "received" and/or "rport" have been seen > for this transaction, 18.2.2 uses only the 4th choice, that is to > send directly to the sent-by address. > > The first option seems to provide the most reliability, although it is > subject to spoofing. That's the main problem as Anders Kristensen suggested. > The second option seems to be more robust against spoofing, but fails > if the sent-by addresses are not globally routable (which will happen > in about 100% of the cases with NATs, since almost all SIP elements > can only process IP addresses as sent-by addresses). So unuseful in fact. In conclusion I think the best option is to drop/ignore retransmissions from different address as I've already implemented. Maybe some RFC allows it by sincerely I think it's not well specified and possible issues (security) are more important than tha small advantage it could offer. Thanks a lot for your help. Best regards. -- Iñaki Baz Castillo _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
