I misspoke when I said an FQDN can have multiple A records in the DNS. I meant to use the term "domain name" not FQDN.
-- Raj On Jan 9, 2008 10:43 AM, Raj Jain <[EMAIL PROTECTED]> wrote: > On Jan 9, 2008 9:31 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > If its fully distributed with no central point of control, then > > presumably the individual line cards (UAs) become available/unavailable > > independently. That seems inconsistent with the desire to have a single > > registration enable routing to them all. It would seem that each would > > be needing to register independently. > > While correct in theory, the issue with that is explosion of REGISTER > messages. With 'n' AoRs where each has 'm' Contacts, you would have > n*m REGISTER messages at the start up and then at every refresh cycle. > > It's not that SIP doesn't support what we're trying to do, but we're > basically after optimization. Let's review the key question again: > > Does it make sense to use FQDNs in Contact URIs? Is the Contact > fundamentally supposed to identify a device? There may a couple of > corner cases (like the one I stated earlier) where it might be okay to > use FQDNs in Contact. However, what happens when someone sends an FQDN > in the Contact URI in a 200 OK and then ACK goes to wherever the DNS > tells you to send it to (assume non-record-routing proxies in the > middle)? > > -- > Raj > > > > > Raj Jain wrote: > > >> Then I am very confused. Why are hundreds of contacts bound to a single > > >> AOR? When a caller addresses a call to the AOR, can it really be > > >> answered by any of hundreds of devices? The only situation I am aware of > > >> that fits that description is a call center. But it doesn't sound like > > >> that is what you have. > > > > > > Yes it can be answered by any of hundreds of devices. Its not exactly > > > a call center but close enough for the purpose of this discussion. > > > I've explained about the system in another post, but here it is again: > > > > > > It's a key telephone system. We live and breathe Shared Line Appearances. > > > The system is fully-distributed with no central point of control, > > > whatsoever. The system is comprised of tiny trunk cards (due to legacy > > > reasons) that have now been converted to SIP UAs. The system is highly > > > scalable and as result there can be hundreds of these SIP UA cards > > > installed > > > in a single system. These trunk cards are "created equal" - i.e. anyone of > > > them can take you to the same extension (AoR). An AoR is registered with > > > the > > > Registrar/Proxy when a user logs-in. To hide the multiplicity of these SIP > > > UA cards from the external world we've fronted them with a SIP Proxy > > > Server. > > > The proxy server load balances traffic to these line cards in some > > > fashion. > > > > If its fully distributed with no central point of control, then > > presumably the individual line cards (UAs) become available/unavailable > > independently. That seems inconsistent with the desire to have a single > > registration enable routing to them all. It would seem that each would > > be needing to register independently. > > > > So I am still groping to understand the constraints of the problem. > > > > Paul > > > > > > > -- > > > Raj > > > > > > > > >> Paul > > >> > > >> > > >>> The fundamental issue is how to tell the Location Service that a > > >>> particular > > >>> AoR can be reached by hundreds of IP addresses. We said it is > > >>> impractical to > > >>> carry all the IP addresses in a REGISTER so let's put them in the > > >>> Location > > >>> Service using some out-of-band mechanism, and then use REGISTER to turn > > >>> the > > >>> bindings on or off. Using an FQDN (which may not exist in DNS) in the > > >>> Contact: is a subtly different point, but I think it seems okay to do > > >>> so. > > >>> > > >>> -- > > >>> Raj > > >>> > > >>> > > >>>> [EMAIL PROTECTED] wrote: > > >>>>> From: "Raj Jain" <[EMAIL PROTECTED]> > > >>>>> > > >>>>> On Jan 7, 2008 1:54 PM, <[EMAIL PROTECTED]> wrote: > > >>>>> > I'm not sure whether it makes to sense to use > > >>>> domain names in a > > >>>>> > Contact URI. The SIP ABNF allows it. Any thoughts > > >>>> or suggestions on > > >>>>> > this? > > >>>>> > > > >>>>> > It is legal to do so, and it is mandatory that a > > >>>> registrar/proxy > > >>>>> > support it correctly, as the registrar does not > > >>>> control the contact > > >>>>> > addresses that UAs will present to it. > > >>>>> > > >>>>> Define "support it correctly". If my Registrar uses its > > >>>> own database > > >>>>> to resolve a domain name in a Contact URI instead of > > >>>> querying DNS, > > >>>>> then am I violating any normative statements made in any RFC? > > >>>>> > > >>>>> I suppose it depends on what is in the database. If that > > >>>> matches what > > >>>>> DNS returns, or it is correct in the context for domain > > >>>> names that the > > >>>>> Registrar has some knowledge about, that would seem OK. > > >>>>> > > >>>>> > I don't know what the constraints in your design are, > > >>>> but have you > > >>>>> > considered using a URI-parameter? If your redirection > > >>>> service carries > > >>>>> > the URI-parameter form the AOR to the registered > > >>>> contact, then you can > > >>>>> > have an unlimited number of different SIP URIs that > > >>>> map through one > > >>>>> > registration to distinct contact URIs. > > >>>>> > > >>>>> Let me try to understand this. We didn't really have a > > >>>> redirection > > >>>>> service in mind. We were thinking that a Registrar and a > > >>>> Proxy will be > > >>>>> sufficient. Our goal is to bind hundreds of Contact URIs > > >>>> to one AoR. > > >>>>> We're saying that we can't carry all those Contact URIs > > >>>> in-line in a > > >>>>> REGISTER message so lets carry them "indirectly" and use an OOB > > >>>>> mechanism. I'm not sure how a Redirection Service, URI > > >>>> parameter helps > > >>>>> this situation. > > >>>>> > > >>>>> You say "Our goal is to bind hundreds of Contact URIs to one AoR." > > >>>>> without specifying what those contact URIs might be. Would it be > > >>>>> possible to use one base URI but to create many different > > >>>> derived URIs > > >>>>> by adding a URI-parameter? > > >>>>> > > >>>>> In any case, if you want useful advice, you should describe more of > > >>>>> the problem -- it is likely that determining a "good" solution > > >>>>> requires understanding why you think you need to register > > >>>> hundreds of > > >>>>> contacts for an AOR. Otherwise, all we can say is "What you have > > >>>>> suggested doesn't seem like it is going to work well." > > >>>>> > > >>>>> Dale > > >>>>> _______________________________________________ > > >>>>> Sip-implementors mailing list > > >>>>> [email protected] > > >>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > >>>>> > > >>> > > > > > > > > > > > > > > > > -- > Raj Jain > > mailto:rj2807 at gmail dot com > sip:rjain at iptel dot org > -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
