Raj Jain wrote:
> [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.
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.
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
>>>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
