> 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. -- 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 > >>> Sip-implementors@lists.cs.columbia.edu > >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >>> > > > > > -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
