MWI sollicitated - 404 not found / 401 unauthorized

I have been trying to set up sollicitated MWI (unsollicitated works fine) on my newly upgraded Asterisk 18.8.0 box.

My understanding is that you just need to put the mailbox into the mailboxes= field of the aor. And then the endpoint that is linked to the aor (I have a one-to-one relationship for my testing to keep things simple) can then subscribe to mailbox@context

So I have an aor with mailboxes=706@4165551234 . I definitely have a 1706@4165551234 voicemailbox, as shown by running “voicemail show users for test” in Asterisk.

When I turn on the logger, I get subscription communication, but they are always rejected with 404 not found or 401 not authorized

I don’t know what my next steps are

Or is there anything else to turn on that I am not aware of?

Here is a logger snippet with some things like IPs scrambled.

[2021-11-15 19:52:14] VERBOSE[6336] res_pjsip_logger.c: <— Received SIP request (562 bytes) from UDP:24.35.34.56:26205 —>
SUBSCRIBE sip:706@4165551234 SIP/2.0
Via: SIP/2.0/UDP 10.0.8.109;branch=z9hG4bKefeb3e82BAE279C2
From: “PJSIP test” sip:test@server.domain.com;tag=17D798C5-664F257C
To: sip:706@4165551234
CSeq: 1 SUBSCRIBE
Call-ID: 31d992e1d5c55944ce3bc8dc073a7c70
Contact: sip:test@10.0.8.109
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
Event: message-summary
User-Agent: PolycomVVX-VVX_450-UA/6.4.1.2280
Accept-Language: en
Accept: application/simple-message-summary
Max-Forwards: 70
Expires: 60
Content-Length: 0

[2021-11-15 19:52:14] VERBOSE[7157] res_pjsip_logger.c: <— Transmitting SIP response (497 bytes) to UDP:24.35.34.56:26205 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.8.109;rport=26205;received=24.35.34.56;branch=z9hG4bKefeb3e82BAE279C2
Call-ID: 31d992e1d5c55944ce3bc8dc073a7c70
From: “PJSIP test” sip:test@server.domain.com;tag=17D798C5-664F257C
To: sip:706@4165551234;tag=z9hG4bKefeb3e82BAE279C2
CSeq: 1 SUBSCRIBE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1637023934/9ae102640995711d71eeede3d853095b”,opaque=“7b9555e3757a1002”,algorithm=md5,qop=“auth”
Server: mYPBX
Content-Length: 0

[2021-11-15 19:52:14] VERBOSE[6336] res_pjsip_logger.c: <— Received SIP request (834 bytes) from UDP:24.35.34.56:26205 —>
SUBSCRIBE sip:706@4165551234 SIP/2.0
Via: SIP/2.0/UDP 10.0.8.109;branch=z9hG4bKba77d7a2DAE02CA2
From: “PJSIP test” sip:test@server.domain.com;tag=17D798C5-664F257C
To: sip:706@4165551234
CSeq: 2 SUBSCRIBE
Call-ID: 31d992e1d5c55944ce3bc8dc073a7c70
Contact: sip:test@10.0.8.109
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
Event: message-summary
User-Agent: PolycomVVX-VVX_450-UA/6.4.1.2280
Accept-Language: en
Accept: application/simple-message-summary
Authorization: Digest username=“test”, realm=“asterisk”, nonce=“1637023934/9ae102640995711d71eeede3d853095b”, qop=auth, cnonce=“lT5NGzWEW80IUFS”, nc=00000001, opaque=“7b9555e3757a1002”, uri=“sip:706@4165551234”, response=“b363f135a690880eb3be94a044502a48”, algorithm=MD5
Max-Forwards: 70
Expires: 60
Content-Length: 0

[2021-11-15 19:52:14] VERBOSE[18258] res_pjsip_logger.c: <— Transmitting SIP response (348 bytes) to UDP:24.35.34.56:26205 —>
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.0.8.109;rport=26205;received=24.35.34.56;branch=z9hG4bKba77d7a2DAE02CA2
Call-ID: 31d992e1d5c55944ce3bc8dc073a7c70
From: “PJSIP test” sip:test@server.domain.com;tag=17D798C5-664F257C
To: sip:706@4165551234;tag=z9hG4bKba77d7a2DAE02CA2
CSeq: 2 SUBSCRIBE
Server: mYPBX
Content-Length: 0

You’d need to provide the actual configuration as well. For example it’s subscribing to MWI for an AOR named “706”. Is that the correct AOR, and it exists? Your username is “test” so it’s more likely your AOR is named test as well, which would mean that it’s subscribing to an AOR that doesn’t exist (or is not listed in the aors line for the endpoint) and thus a 404 would be sent back.

Preliminary tests point to this being the issue. Thanks, I will look in depth when I have time.

BUT - I don’t quite understand why creating an AOR called 706 helped, as it is subscribing to 706@4165551234 and not just 706.

Why did it work by calling the AOR 706 without the @4165551234 portion? Trying to understand the logic, as it does not matter for this specific test, but it does for the production system I am planning.

The SUBSCRIBE is to a specific AOR (not a mailbox), which is specified in the Request URI as the user portion:

SUBSCRIBE sip:706@4165551234 SIP/2.0

The domain portion doesn’t matter and is ignored, unless you enable multi-domain support.

Although I don’t know if anyone has truly tested with multi-domain support, it’s something only a few Asterisk users actually use.

I somehow missed the most basic of things - that you subscribe to an AOR, not a mailbox. Thank you for clarifying this.

How do I turn on multi-domain support?

I have plenty of things that are segmented with “domains” (or whatever term is used on each module) - context for voicemail, accountcode for most other things - all allow me to segment things in a reasonably logical fashion.

how would I turn on multi-domain? That`s not some kind of global flag is it? The only thing I feel I would need any multi-domain support for seems to be this particular feature, the rest is handled perfectly well with built-in fonctionality. But I want a user to be able to subscribe to simply “706” on their phone without caring about what context/domain/etc they are in but get the right mailbox subscription (say 706@123 or 706@456 depending on which endpoint).

I really appreciate the help you have given me so far…and feel free to just point me to a link if my Google skills failed me.

The multi-domain support does not work like that. It respects the domain in the request URI, not a configured one, so the endpoint would have to be configured to subscribe using it. It’s enabled globally in pjsip.conf[1]. Looking it appears to be enabled by default. What almost all users do is not use domains, but just have unique identities and dialplan contexts and other things.

[1] asterisk/pjsip.conf.sample at master · asterisk/asterisk · GitHub

So my understanding at this point is here is no way to have two devices subscribe to the same “named subscription” (706 in my example), each sent to different mailboxes depending on which endpoint we’re talking about.

Option 2, which seems easy enough, is to change my 706@123 to be 706-123 (or any other character segmenting the mailbox content from the mailbox name) and handle this via scripting/dialplan.

Correct. It’s easiest to just script/etc things and use the unique identifiers.