Register multiple tenants to the same ISP

Asterisk Asterisk SIP
1

Consider this scenario; I have multiple tenants, on the same box, and let’s say each registers with the same ISP.

I would like the OPTIONS packet (sent from the ISP) to be replied. Asterisk currently returns Not Found in response to the OPTIONS. I currently have no identify definition, but even if I add one, it seems to accept the first OPTION message, but then rejects the rest.

Currently, both registration, inbound and outbound calls are all working fine. It’s not a big deal but I would, like to understand the mechanism and fix the response.

res_pjsip/pjsip_distributor.c:673 log_failed_request: Request 'OPTIONS' from '<sip:server1@some-isp.com>' failed for '11.22.33.44:5060' (callid: 013532e7-1037bc26-d4985@11.22.33.44) - No matching endpoint found
2

What does “rejects the rest” mean? What actually happens?

3

I get the error message above “… No matching endpoint”

4

Are they coming from different IP addresses?

5

No, the all the options are from the same ISP, but from different “accounts”. Each tenant would sent up a register to the same ISP.

6

Same ISP doesn’t inherently mean same IP address that the OPTIONS could be coming from. What does a SIP trace actually show?

7

In this case, its the same ip.

Here is some lab data:

First response after register:

OPTIONS sip:195e2b3f885bd8b181d9e278e68660af1facb9d2@192.168.88.48:5060;line=kcdkurq SIP/2.0
Via: SIP/2.0/UDP 52.50.165.204:5060;branch=z9hG4bKb26e.318b1a1624cc8f11
From: sip:hello@eu-west-1-sbc-1.siperb.com;tag=6dce7e6
To: sip:195e2b3f885bd8b181d9e278e68660af1facb9d2@192.168.88.48:5060;line=kcdkurq
Call-ID: 013532e7-33e7bc26-31ad6@52.50.165.204
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0

Reply:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 52.50.165.204:5060;rport=5060;received=52.50.165.204;branch=z9hG4bKb26e.318b1a1624cc8f11
Call-ID: 013532e7-33e7bc26-31ad6@52.50.165.204
From: <sip:hello@eu-west-1-sbc-1.siperb.com>;tag=6dce7e6
To: <sip:195e2b3f885bd8b181d9e278e68660af1facb9d2@192.168.88.48>;tag=z9hG4bKb26e.318b1a1624cc8f11;line=kcdkurq
CSeq: 1 OPTIONS
Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, application/pidf+xml, application/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;version=2

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, INFO, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: Asterisk PBX 20.10.0-rc1
Content-Length:  0

Then a few seconds later:

OPTIONS sip:e4e6eee081a34b77219b42b79e6ef21f6cd83436@192.168.88.48:5060;line=kedchws SIP/2.0
Via: SIP/2.0/UDP 52.50.165.204:5060;branch=z9hG4bK5586.cb8cf0ea90dcd3c1
From: sip:hello@eu-west-1-sbc-1.siperb.com;tag=7dce7e6
To: sip:e4e6eee081a34b77219b42b79e6ef21f6cd83436@192.168.88.48:5060;line=kedchws
Call-ID: 013532e7-43e7bc26-71ad6@52.50.165.204
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0

Reply:

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 52.50.165.204:5060;rport=5060;received=52.50.165.204;branch=z9hG4bK5586.cb8cf0ea90dcd3c1
Call-ID: 013532e7-43e7bc26-71ad6@52.50.165.204
From: <sip:hello@eu-west-1-sbc-1.siperb.com>;tag=7dce7e6
To: <sip:e4e6eee081a34b77219b42b79e6ef21f6cd83436@192.168.88.48>;tag=z9hG4bK5586.cb8cf0ea90dcd3c1;line=kedchws
CSeq: 1 OPTIONS
Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, application/pidf+xml, application/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;version=2

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, INFO, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: Asterisk PBX 20.10.0-rc1
Content-Length:  0

These are the two sample accounts:

[User1]
type=registration
transport=udp_transport
outbound_auth=User1
server_uri=sip:eu-west-1-sbc-1.siperb.com:5060
client_uri=sip:e4e6eee081a34b77219b42b79e6ef21f6cd83436@eu-west-1-sbc-1.siperb.com:5060
retry_interval=60
max_retries=9999
fatal_retry_interval=60
forbidden_retry_interval=60
contact_user=e4e6eee081a34b77219b42b79e6ef21f6cd83436
expiration=60
endpoint=User1
line=yes

[User4]
type=registration
transport=udp_transport
outbound_auth=User4
server_uri=sip:eu-west-1-sbc-1.siperb.com:5060
client_uri=sip:195e2b3f885bd8b181d9e278e68660af1facb9d2@eu-west-1-sbc-1.siperb.com:5060
retry_interval=60
max_retries=9999
fatal_retry_interval=60
forbidden_retry_interval=60
contact_user=195e2b3f885bd8b181d9e278e68660af1facb9d2
expiration=60
endpoint=User4
line=yes
8

Okay, so that’s a 404 and not a rejection as a result of not finding a corresponding endpoint. OPTIONS are treated the same as an INVITE for handling for determining the response. Specifically the request URI user portion is looked up in the dialplan. If it is found then a 200 OK response occurs, if it’s not found then a 404 Not Found response occurs.

1 Like
9

Yes, but INVITES are working correctly User1 and call User4 no problem

10

The second OPTIONS is looking for an extension of “e4e6eee081a34b77219b42b79e6ef21f6cd83436” in the dialplan context of the endpoint you specified for the identify. Is one there?

11

No, i have no identify definitions at all

12

If it is matching based on line in the outbound registration as it now would be, then my same response applies except:

The second OPTIONS is looking for an extension of “e4e6eee081a34b77219b42b79e6ef21f6cd83436” in the dialplan context of the “User1” endpoint. Is one there?

1 Like
13

Ah… a see…

So I generally try to avoid _. it seems that was the trick.

I added:

exten => _.,1,NoOp(You called: ${EXTEN})

And now they all work correctly.

14

You should avoid _. Use sends_line_with_registrations = yes in the ISP definition

15

I have line=yes and endpoint=... in my register definition. (not using wizard)

16

There could be a work-around to using _. in the main dial plan. It could match at some arbitrary endpoint. But in order to match on the sip username that can be any character really 0-9 and a-z and A-Z.

I can make an identify definition, something like:

[Siperb_identify]
type=identify
match=eu-west-1-sbc-1.siperb.com
endpoint=Siperb_Options

and this Siperb_Options endpoint could have a context in the dial plan that would match on the _.

[Siperb_Options]
type=endpoint
context=Handle_Options

Then INVITES would match on the register definition and options would match on the identify definition. yes? no? maybe?

(I have not tried this… but in theory it could work)