Difference between revisions of "Meerdere trunks vanaf 1 IP, geeft problemen met onderscheid"

From 4AllBusiness
Jump to navigation Jump to search
Line 16: Line 16:
 
'''De Oplossing:'''
 
'''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.
+
  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.
 
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 de trunk van de PBX en in het portal lossen we dit alsvolgt op door:
Line 46: Line 47:
 
Het luistert allemaal vrij nauwkeurig, dus test het goed!
 
Het luistert allemaal vrij nauwkeurig, dus test het goed!
 
Het kan zomaar zijn dat Klant-A bijvoorbeeld opeens uitbeld op kosten van Klant-B !!!!
 
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.
  
 
Zie screenshots:
 
Zie screenshots:

Revision as of 00:06, 10 September 2016

Meerdere trunks vanaf zelfde IP onderscheiden Laatst bijgewerkt 2 years ago

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!
ClipCapIt-160909-235840.PNG


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)
ClipCapIt-160909-235930.PNG


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.

Zie screenshots: