[EMAIL PROTECTED] wrote: > Reading between the lines, this sounds like the goal is for a > "pbx" to register with a proxy, and then for the proxy to > route calls for a block of numbers to that pbx.
You're close. It's a key telephone system. > The sip forum addressed this to some extent in a spec known > as SIPConnect. (But IMO they botched it a bit.) The SIPConnect spec doesn't address our problem. In our case, the switching system and the proxy/registrar are sitting in the same domain. This is an intra-domain problem. The SIPConnect spec describes how a SIP PBX connects to a SIP Service Provider (SSP). Outbound registrations from an enterprise to the SSP are OPTIONAL in SIPConnect anyway. > If I have the scenario right, the problem is that you want to > register once, but then after calls have been routed by the > proxy to the pbx, it needs to be able to determine which AOR > had been called, so it can route to the proper phone/contact. > > Have I guessed right? Not exactly. The issue is the multiplicity of the Contacts bound to an AoR and not figuring out an AoR on the fly. When the call comes into the proxy, it comes to a known AoR. The proxy can now choose one among hundreds of IP addresses to push the call to that AoR. 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 > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
