The use of the realm setting in the SIP [general] section is simply to set the protection domain of the Asterisk server as a registration server. According to the RFC the string must be globally unique, so we are finally just following proper protocol. It is not used to as a credential when registering Asterisk as a UAC with another domain, such as FWD on its own behalf (ie for all users) or of its users individually. For such requests it will use the realm string that is received from the respective domain upon a SIP/401 or 407.
The register line does specify the realm within which you are trying to authenticate, only it's the same as the hostname of the proxy. But I don't know of a single case where this is a problem. That is a short-coming perhaps until we get the outbound proxy support finalized. The final syntax details aren't worked out. The issues are whether we want to abandon the register line and put all registration info into the [user/peer] definitions and what the final parameter names etc are. There is a lot of confusion about the existing parameters and this should be cleared up and streamlined.
In your "proxy" example below, you should just register each UA with a username on the Asterisk using the Asterisk's domain (realm=sip.foo.com) and routing calls to the appropriate service XYZ based on the originating user. To service XYZ you can register with the appropriate domain and account number with the existing register statement if needed or use a [peer] with appropriate credential to route calls. Nothing new required.
I don't know what really mean by "shared" but you can register as many accounts as you wish to one domain as is.
Calls come in for those accounts through the same [user] into that [user]'s context, so it is already "shared"
So, all the functionality we do have, it's just not always easy to understand the syntax.
Chris A. Icide wrote:
JT,
I've not yet tested (played) with setting the realm yet, but I plan to. However, one would think that realm should be a per-entry setting versus a global setting, or perhaps both.
The problem that really arises is when you try to use asterisk as a local UA "proxy". I don't mean proxy in the official term, but just as a description of what it is doing. In other words, you have several accounts which are some sort of gateway service, be it PSTN, or some other gateway. You would normally register a specific UA to these (ata-18X, sipura, cisco 79xx, etc.). However to "simplify" the end user experience, you stick an asterisk server in front of the UA devices and allow it to route calls as needed freeing the UA user from having to remember what line to dial out on for what, etc.
In this case, we have an issue that may come up, where we need to register with the service as a specific realm. Now as you well know, the register statement doesn't support alot of the things it should, including being able to set realm per register.
I've always thought there needed to be a much better format for register that currently exists.
perhaps type=x (user|peer|friend|register)
forgive me if I'm somewhat out of date on sip.conf, as I've been somewhat busy, but there are a few other things that should be available (if it hasn't been added recently) to both a register in this format as well as the normal SIP UA definitions:
bindaddr=a.b.c.d (defines the interface IP to register or accept traffic for this client/server)
realm= (per entry realm definition)
shared=x (no|yes\numeric value)
The shared statement would of course require significant changes (perhaps Olle has done this is chan_sip2), but this would define whether or not multiple UA's are able to register to the same sip entry and perhaps limit the number of shared registrations - this of course to allow asterisk in the future to support notify/subscribe shared line presentation)
Anyway, I'm sure this ground has been covered many times, but just in case one of these somehow has not been brought up, I figured I would give the topic a bump.
-Chris
On 01:00 AM 5/19/2004, John Todd wrote: >Tony - > For what it's worth, I haven't been able to make the "realm=" >setting do diddly-squat. I think it's broken, but I don't have time >to test enough to put useful/valid data into the bugtracker. > > If anyone can show me a "Digest" line that has a realm= that was >changed with the global realm= setting in the current CVS, I'm >interested in learning the syntax you used... > >JT
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
