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
