Meerdere trunks vanaf 1 IP, geeft problemen met onderscheid

Meerdere trunks vanaf zelfde IP onderscheiden

Meerdere trunks vanaf hetzelfde (klant)-IP adres registreren op hetzelfde voip-portal.

Dit zal niet (of soms) werken, omdat het billing protal niet meer weet welke trunk gebruikt moet worden voor uitgaande gesprekken. Er is geen IP adres verschil meer, dus de SIP invites worden willekeurig omgewisseld of verkeerd geinterpreteerd.

De reden:

Omdat je 2 trunks registreert vanaf hetzelfde ip adres, weet de pbx, of het billing portal niet meer van wie en naar wie het verkeer moet worden gestuurd. Er is geen onderscheid meer van ipadressen aan beide kanten. Er is hier heel weinig duidelijk info over te vinden, maar wij hebben de oplossing gevonden en getest. Technische achtergrond: In de trunkregistratie dient toegevoegd te worden: fromuser=910xxxx Echter geeft dat het volgende probleem dat het juiste callerID niet meer uitgestuurd kan worden. Er zal nu de waarde van het Fromuser= veld meegestuurd worden als uitgaand CallerID.

De Oplossing:

Makkelijke oplossing kan zijn: verander bij de provider de 'username' naar het telefoonnummer waarmee uitgebeld moet worden. Helaas werk dit niet in alle gevallen, zoals bijvoorbeeld vanuit de PBX bepalen met wel CLID uitgebeld moet worden.

Uitgebreide oplossing Dit lossen we vervolgens op door het callerid niet van de sip header te pakken maar van een extra veld die toegevoegd wordt genaamd RPID (RemotePartyID). Hier wordt een kopie van de CallerID in geplaatst en deze kan later weer gebruikt worden als CallerId ipv fromuser info. In de trunk van de PBX en in het portal lossen we dit alsvolgt op door: In Portal Device Settings:

 trusrpid en sendrpid aanvinken
 insecure port en invite dienen uitgevinkt te staan!

In de PBX Trunk Settings:

 -Trunk naam wijzigen in puur het trunknummer (zonder letters e.d.), 
  anders komen inkomende gesprekken niet meer aan
 -In de trunk bij Uitgaande Settings: senrpid=yes en trustrpid=yes
 -Indien aanwezig te verwijderen van: insecure=invite of insecure=port,invite
  als insecure=invite aanstaat, dan wordt de inkomende sip header genegeerd 
  en staat het alles toe van buitenaf, ook wat eventueel niet van jezelf afkomt.
 -fromuser=91xxxx  (je tunk nummer invullen, dit wordt teruggestuurd naar het portal, 
  zodat er onderscheid wordt gemaakt in KlantTrunks vanaf hetzelfde IP adres)

Nu wordt het uitgaande CallerID volledig bepaald door wat je in de trunk van de PBX, of bij Uitgaande Route hebt ingevoerd bij CalleID. De settings van het portal als callerdID worden volledig genegeerd. Aantekening: Indien een anoniem nr inbeld, dan is er geen InkomendCallerID aanwezig. Voor interne gesprekken zal je gewoon "nr onbekend"te zien krijgen, mocht je dit gesprek weer doorschakelen naar een extern nummer buiten de centrale (bv een mobiel), dan zal je niet "nr onderdrukt"zien, maar het laatste wat bekend was. Dat zal dan het fromuser veld zijn wat je te zien krijgt. (dit kan voor verwarring zorgen).

Het luistert allemaal vrij nauwkeurig, dus test het goed! Het kan zomaar zijn dat Klant-A bijvoorbeeld opeens uitbeld op kosten van Klant-B !!!!

Bijkomend probleem waar rekening mee gehouden moet worden: Anoniem uitbellen middels SIPheader toevoegen, geeft problemen. De Custom sipheader 'Privacy: id' wordt namelijk niet gelezen als je de RPID uitleest inplaats van de FROMUSER header. Dit is echter op te lossen door niet beide trust en sendrpid te activeren.

Mocht er een trunkwissel zijn, dan zal Asterisk zichzelf niet zomaar corrigeren, Handmatig is dit op te lossen middels:

# asterisk -vr
# core sip reload
# exit

---

Update:

Onderscheid zonder FROMUSER settings. Alternatieve methode om onderscheid te maken: Zorg dat er geen insecure setting is in de trunk settings. Voeg het volgende toe aan FreePBX Sip settings:

match_auth_username=yes

Of in andere asterisk configuratie's moet dit toegevoegd worden aan sip.conf onder [general] > > Add "match_auth_username=yes" in the [general] section of sip.conf > > > > Remove from each peer any "insecure" entry > > > > Usually I add also "auth", "defaultuser" and "username" to the peer > > definition, but some of these entries are not needed.