To answer your last question - it can certainly make sense in some
cases. An example is a fault tolerant UA with multiple instances.
In any case it is not the business of the registrar to decide if it
makes sense - the UA gets to decide what sort of contact it wants to
use. The registrar is expected to route to the registered contact using
the standard rules, which includes DNS lookups if the contact contains a
domain name.
I suppose you could construct your registrar to reject REGISTER requests
when the contact contains a domain name. But you would then cease to be
a fully compliant registrar. That may be fine in your case. But the DNS
mapping only costs if the contact contains a domain name. If your UAs
don't use domain names you won't incur the cost. Having support for the
domain name will make your implementation more complete.
Paul
Raj Jain 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
>>>>>>> Sip-implementors@lists.cs.columbia.edu
>>>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>>>>
>>>
>>>
>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
