Hadriel Kaplan wrote:
I think you're talking past each other. Your original statement did
not specify their listen ports would be different.
Yes, Hadriel is accurate in pointing that out.
If they're not different, ie if both domains end up pointing to the
same IP+port on the server, then they are the same server, which just
happens to be servicing multiple domains, and sending to the same
connection is fine.
...but fraught with peril, though. Technically this is feasible,
because there is enough information in the signaling to allow
routing to the right virtual server (I think.) HTTP uses the Host
header to allow the virtual server to distinguish different
domains. The SIP equivalent is the domain name in the R-URI or
topmost Route header; the domain in one of these URIs should point
to the right virtual domain.
Now, whether we should be actively encouraging this over TCP is
another question. Note that over TLS, we do not. That is,
if red.com opens a TLS connection to example.com, then red.com's
identity (sip:red.com) is saved in the alias table. Thus,
when example.com sends a request to blue.com, even though
rfc3263 resolution will result in the same IP+port, the earlier
connection will not be reused because the identity does not
match (i.e., sip:red.com != sip:blue.com).
If they're the same IP but different ports, such that SRV resolves
example.com to port 5060 and blue.com to 5070, for example, then you
^^^^^^^^^^^ red.com
shouldn't send to both domains on the same connection - because they
may well be two different processes, and example.com could lie and
^^^^^^^^^^^ red.com
take over blue.com's requests.
Right. That is what I was worried about.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
