The consensus, on this list and on the main sip list, was that in order to
detect merged requests, a device has to examine the top Via header of
incoming requests.
(Review: merged requests are the following case. Consider that we're "D".)
--- --- --- ---
| | | B | | | | |
| |-->|___|-->| | | |
| A | ___ | D |-->| E |
| |-->| C |-->| | | |
|___| |___| |___| |___|
The thought was that if the top Via headers don't match, you consider the
request to be merged, and send a 4xx (probably a 482) to the second merged
branch you receive.
The question is: what's the definition of "matching" for Via headers?
Clearly, the Transport, Port, and Branch values must match (and
protocol-name and protocol-version must be "SIP" and "2.0" respectively).
The hard question, though, is the host. Should we require that:
* The hostname string, as sent by the client, matches literally?
* The hostname resolves to the same IP address?
* The IP address we received the request from (i.e. the "received"
parameter we'd insert) matches?
* Some combination of these, either as an 'and' or an 'or'?
Also, for multicast requests, do the 'maddr' and 'ttl' parameters have to
match?
My thought is that the hostname should just match case-insensiively as a
string, that maddr should have to match the same way, but that ttl should be
ignored. However, if people feel differently about this, I'd be curious to
know what they think.
--
Jonathan Lennox
[EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
