The PJSIP Configuration Sections and Relationships documentation’s section seems to cover these subjects, but without much detail, and some of the statements seem to be somewhat contradictory, so I’d like to confirm that my understanding is correct.
An Endpoint represents a configuration profile and maps to a specific, well, endpoint(i.e., device).
An AoR represents a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the “public address” of the user(e.g., sip:user@domain).(RFC 3261 - SIP: Session Initiation Protocol)
Now, according to the ERD and its annotation on the same page of the documentation, we learn that:
Many ENDPOINTs can be associated with many AORs
meaning that a user, can potentially be reached, using his SIP URI, through multiple endpoints.
Each endpoint can be configured to allow registrations only for specific AoRs, using the aors property. Also, an endpoint might be authorized using the auth object.
When an Endpoint tries to register against an AoR, a contact that contains some config options related to the connection is created.
It seems that AORs by themselves lack any kind of authentication and are used only in combination with a specific and preassigned set of endpoints. Furthermore, we have the sections naming requirement for endpoint and aor types which must match the user portion of the SIP URI in the “From” header for inbound SIP requests with an exception of endpoints that have a related identify section in which case the request would be matched by IP.
Now, I struggle to wrap my head around the following matters:
Is the only way for that many to many relationship to occur is to create several endpoints with a related identify section, and one, perhaps the main one, with the user portion as the name?(RFC5947)
Now, it looks perfectly fine for an AOR to be registered with several Endpoints, let’s say a desk hard phone and a softphone, but in what occasions an Endpoint would have several AORs?
It looks redundant to have a separate Identify section since after the Endpoint’s registration on behalf of an AOR we have a related Contact, what do I miss?
That naming requirement is not correct. The REGISTER request states what AOR the registration is against in the To header, and it can differ from the name of the endpoint. I can have an endpoint named “alice” but the endpoint could specify to register against the AOR “1000”. It requires the remote endpoint to support this, though.
No
If supported by the remote endpoints you could have an endpoint named “alice” with an AOR named “alice-desk” and “alice-mobile”.
An identify is not required. If you are matching based on IP address then you generally would not have the remote side register, and just use a statically configured contact.
That’s exactly the part that confused me. Your explanation is mostly consistent with what I learnt from the documentation, except for the following part (the highlighting is mine):
However, in some cases, (endpoint and aor types) the section name has a relationship to its function. In the case of endpoint and aor their names must match the user portion of the SIP URI in the “From” header for inbound SIP requests. The exception to that rule is if you have an identify section configured for that endpoint. In that case the inbound request would be matched by IP instead of against the user in the “From” header.[1]
So I think the documentation could be improved on this side, as I found several similar questions here and on other resources before asking the question here.
This answer was apparent from your explanation, but I had no luck with registering remote endpoints (please correct me if I interpreted you wrong, I read it as UAC, in my particular case meaning softphones). Could you, please, point me to a softphone (preferably FOSS) that reliably supports this?(e.g., Zoiper is known to support this?)
This is something I obviously misunderstood, and probably because of this misunderstanding my configuration is not working. Until now I thought the endpoint was a hard or soft phone, so “alice-desk” and “alice-mobile” should be the endpoints. The AOR for both of them could be named alice, to reflect her public address(as in RFC-3261, i.e. SIP URI) e.g. sip:alice@domain. But now I see that it’s the other way round, isn’t it?
A solid understanding of basic terminology, objects and their responsibilities will probably clarify this issue as well. Could you draw parallels between the objects of the system and the actual objects, processes and events they represent?
Things that register are registrants. When something registers itself, it intends to become a UAS, so that it can receive calls. You don’t need to register to be a UAC. There is a tendency to treat SIP as asymmetric, in the way that you have the asymmetry between FXO and FXS, but an entity can actually be UAS and UAC in the same session, and that is not uncommon, e.g. it tends to happen when you use direct media.
I think you are chasing an edge case that is not very common.
Well, probably yes, but without understanding the behaviour of the system in edge cases one cannot claim to understand what is going on, it will remain something like black magic to them. But the case I started playing with was very similar to what @jcolp suggested - one user, two phones, I wanted them to ring simultaneously until the user picked up. I made it work with one endpoint, one AoR that has two contacts, but it seemed a bit hacky and I wanted to understand the “right” way to configure such a scenario, since I wasn’t sure about the correctness of my understandings.
I’d love to, but as of current, the only contribution I can suggest is proofreading and styling.
Well, I don’t need a list, but I gather you don’t know even one of them, which is a pity as I won’t know if things aren’t working due to misconfiguration or if they’re just not supported.
I can see how well thought out the flexibility of things is, but the problem is that I couldn’t figure out more than one way to make things work.
If you can point me to any resource where I can get such insight - I would be most grateful, as I have spent quite a bit of time and almost all of them provide just solutions without insight, and those that try to explain are pretty much just citing each other. Otherwise, thank you for the time you’ve spent answering my possibly silly questions.
There is no “right” way, it’s the way you want to use or the way most people do things out of convenience. Most people for that scenario do what you did - one endpoint, one AOR, multiple contacts since it has the widest compatibility with endpoints. Many things assume that if you use the name “alice” then the AOR is also “alice”.
I don’t have any additional information or resources to give.
That’s why I put the word in inverted commas, to emphasise that it’s not about correctness, it’s about my sense of shoddiness of my configuration.
Well, I think flexibility is about configuration, not assumption, which we all know is mother… But when you say “If you use a name”, do you mean the custom part of the SIP URI or the endpoint (or something else)? Because if the former, that makes sense, but in the case of the latter it means the endpoint has to be named after the AOR, or it would go against the assumptions in those many things.
When I find the answers, I’ll be happy to add them to the documentation.
Configuring a third party device/softphone results in configuring the underlying URIs in use which then are used in SIP requests. If such implementation accepts only a single username, then it uses that username in all the various URIs. These URIs include the From one, as well as the To one. These are then used by Asterisk for both identifying incoming requests and for knowing which AOR a REGISTER is for. Therefore if only a single username is used, the configuration in Asterisk for the endpoint and the AOR must use the same name.
What the protocol allows and what Asterisk allows does not necessarily overlap with all other implementations of SIP and the methods by which they allow their own configuration. It is convenient for them and simplifies their own work to just assume a single username and name.