line=yes may not be enough. You need to make sure that the service provider actually supports that. When they support that and they offer something like which is frequently described as a “trunk”, you may need to check whether you also need to evaluate other SIP headers like P-Called-Party-ID. And if the service provide is really big, you may have to deal with some DNS related issues. I know of one big player that allows communication only with the server (out of many) where you have registered your box, but it is allowed to register to several of their proxies at the same time…
From the OPs description, they do return the line= part of the Contact URI. Strictly speaking everyone should.
What he is saying is they then don’t provide the mysterious BNUM value. I’m wondering if they were presenting the called number in the request URI, rather than strictly following the RFC and sending the Contact URI, but the additional URI parameter has forced them to use the Contact URI properly.
The OP should see if they can arrange to use one account, which is likely to be a better solution.
Failing that, they need to capture a complete INVITE request and look to see if it contains a “BNUM”. If it does, and they can highlight it, we can probably find a way of extracting it and will know what one is.
I’ve never heard of a “BNUM”, but that probably doesn’t mean a lot. Anyway, I am running routinely several accounts of the same provider on my devices. The only thing I need to do is to evaluate some SIP headers except for line=yes for the registration. For convenience, there is only a single entry point in my dialplans.
Thanks for all the answers,
Ill try to get better at using the LINE parameter, and if nothing works, i will test using different ports per Account (I have 30 right now. . .)
Currently, I’m facing the following “issue” when using LINE parameter
When there is a value in: contact_user (Registration section), the Destination Number (BNumber) received from the ProviderA gets overwritten by contact_user value.
ProviderA sends call to Asterisk (SRC: 123456, DST: 987654)
Asterisk sends call to BLeg modifying the original destination number to the value of “contact_user” (SRC: 123456, DST: Account1)
When I remove the value of “contact_user” parameter, Asterisk sends the Registration request of the account with s@ ProviderA_IP:5060, so, ProviderA sends the calls to DST Number: s
Any updates or fixes found will be shared down below