pjsip.conf minimal Setup registration

[IEEE]

Nach 15 Jahren chan_sip bin ich nun endlich pjsip angegangen. Soweit hab ich auch alles zum Laufen gebracht.

Was die Strategie der Pflege der Config angeht, so habe ich mich relativ rasch gegen die Wizard Geschichten, Templates etc. entschieden. Mir persönlich ist das zu abstrakt, ich tu mir leichter die Sektionen einfach runter zu tippen,

Beim Studieren der Materie ist mir aufgefallen dass sehr viele Beispiele jeweils eigene endpoints für Ein- und Ausgehende Anrufe Ihres Providers anlegen. Das hat vermutlich auch oft seine Berechtigung.
In meinem Fall hat mein Anbieter aber ein Setup, das ich mal als sehr simpel und straight forward bezeichnen würde. Es sind keine SRV records oder so im Spiel und die gesamte Kommunikation (sowohl SIP als auch RTP) läuft ausschließlich über eine IP. Somit hab ich relativ schnell festgestellt, dass ich mit einem Endpoint für ein- und ausgehende Anrufe auskomme.

Das Ganze sieht dann so aus

[MeinProvider]
type = registration
retry_interval = 30
max_retries = 0
contact_user = MeinUsername
expiration = 120
transport = transport-udp
outbound_auth = MeinProvider
client_uri = sip:MeinUsername@<provider-ip>
server_uri = sip:<provider-ip>


[MeinProvider]
type = aor
contact = sip:MeinUsername@<provider-ip>

[MeinProvider]
type = identify
endpoint = MeinProvider
match = <provider-ip>

[MeinProvider]
type = auth
username = MeinUsername
password = MeinPasswort

[MeinProvider]
type = endpoint
context = incomingMeinProvider
dtmf_mode = auto
disallow = all
allow = alaw
direct_media = no
trust_id_inbound = yes
send_pai = yes
send_rpid=yes
from_user = MeinUsername
from_domain = <provider-ip>
outbound_auth = MeinProvider
aors = MeinProvider

Beim Endpoint hab ich also eine outbound_auth angelegt, die ausgehende Anrufe authentifiziert. Eingehende Anrufe schickt mir der Provider natürlich ohne Auth, daher habei ch hier keinen weiteren auth Eintrag. Wenn ich testweise dem endpoint ein "auth = MeinProvider" hinzufüge, verhält sich alles wie erwartet, eingehende Anrufe erfordern dann eine Authentifizierung.

Also soweit eigentlich alles gut, ich würde euch aber gerne fragen ob ich hier etwas übersehe oder an dem Setup irgendwas dran ist, das mir mal auf den Kopf fallen könnte.

Vielen Danke und lieben Gruß!

 

[IEEE]

Mir ist noch ein Schönheitsfehler in meinem Setup aufgefallen. Asterisk schreibt bei den OPTIONS Paketen an den Provider (die aufgrund qualify gesendet werden) den Namen meines AOR Kontexts in das From Feld.

Das sieht dann so aus

<--- Transmitting SIP request (422 bytes) to UDP:provider-ip:5060 --->
OPTIONS sip:sip.provider.com SIP/2.0
Via: SIP/2.0/UDP meine-ip:54321;rport;branch=z9hG4bKPjde29c147-988f-4cc4-b294-1feebb8e1236
From: <sip:[email protected]>;tag=ce8f2afb-fed2-4672-884b-731d4820bfd3
To: <sip:sip.provider.com>
Contact: <sip:mein-kontextname@meine-ip:54321>
Call-ID: 8c266a66-f404-4149-8c2a-a1f2d98320d8
CSeq: 39619 OPTIONS
Max-Forwards: 70
User-Agent: PBX
Content-Length:  0

Das Qualify ist ja Sache des AORs, hier habe ich aber keine Möglichkeit gefunden einen User oder Contact anzugeben.

Meinen Provider scheinen diese Pakete nicht zu stören, würde mich aber interessieren ob das Heranziehen des Kontextnamens als From hier das geplante Standardverhalten ist.

 

[koyaanisqatsi]

Moinsen


Selbst wenn der Ziel SIP Server eine negative Antwort (Forbidden), weil nicht authorisiert, raushaut, wäre das OPTIONS aka SIP-Ping qualify erfolgreich.
...eben weil der Server geantwortet hat.

Wie unter Use hier zu sehen...

SIP Ping

gekk.info

keine Möglichkeit gefunden einen User oder Contact anzugeben.

Mit chan_sip.so geht das mit der Aktivierung von: sendrpid
Der chan_pjsip.so bietet das auch: send_pai send_rpid

res_pjsip - Asterisk Documentation

wiki.asterisk.org

Das kannst (solltest/müsstest, da ich pjsip nicht selber fahre) du dann in der extensions.conf "verbiegen" mit: SET(${CALLERID(all)}=name <registrar>)
...denn das fügt nicht nur den P_ Header mit ein sondern ändert zusätzlich auch das: From:

 

[IEEE]

Korrekt. Wie gesagt, Der Qualify Mechanismus funktioniert. Es ist eher mein eigener Ehrgeiz, weil ich gern verstehen würde warum das Paket so geformt wird ;-)

 

[sonyKatze]

Ist das Heranziehen des [AoR-] Kontextnamens als From hier das geplante Standardverhalten ist.

Du meinst, warum nicht from-user aus dem Endpoint bis in den AoR bzw. das AoR-Qualify vererbt wird bzw. dort den User dann überschreibt. Puh. Gute Frage. Auf die Schnelle fand ich den Quell-Code nicht, der dafür zuständig ist. Ich vermute, dass geht nicht, weil ein Endpoint mehrere AoR haben kann. Wenn Du es unbedingt wissen willst, wäre mein Tipp mit einem Debugger den Code durch-zu-steppen. Weißt Du, wie das geht?

keine Möglichkeit gefunden einen User […] anzugeben

Du könntest den Kontext so wie Deinen User nennen, also in Deinem Beispiel nicht „MeinProvider“ sondern „MeinUsername“ (jedenfalls den Kontext type=aor). Oder geht das nicht?

 

[IEEE]

Grüß Dich,

Ich hab das in der Zwischenzeit probiert und den Namen des aor Kontextes mal geändert. Er schickt trotzdem noch den selben Namen. Wie ganz oben beschrieben, nutze ich ja für die aor, identifiy, registration und endpoint Kontexte jeweils den selben Namen. Das heißt, er zieht sich den From aus dem Namen von endpoint, registration oder identify, aus dem AOR jedenfalls mal definitiv nicht. Ich werde das jetzt noch weiter eingrenzen und einen nach dem anderen umbenennen. Dann wird klar sein welchen Namen er hier nimmt.

Debugger ist mir einigermaßen klar, obs mir dann den Aufwand wert ist, hab ich noch nicht entschieden ;-)

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Ich habe es eingegrenzt. Er nimmt den Kontext Namen des Endpoints...
Es wäre denkbar, dass ein "from_user=" dies overruled, das kommt für mich aber nicht in Frage weil mein Provider bei INVITEs (ausgehende Anrufe) meine vollständige Nummer plus ggf. Durchwahl im From erwartet. Und ein Setzen des from_user würde mir diesen dann auch bei diesen INVITEs überschreiben.

 

[sonyKatze]

ob’s mir dann den Aufwand wert ist

Ja, chan_pjsip ist Wahnsinn. Den zu Debuggen habe ich jetzt wirklich ein paar Mal durch … und habe es auch jedes Mal geschafft. Aber Spaß war das keiner. Vielleicht muss ich selbst noch mal in der Asterisk-Community fragen, ob es da einen schön(eren) Trick gibt.

Es wäre denkbar, dass ein "from_user=" dies overruled, das kommt für mich aber nicht in Frage weil

Ich meinte im Kontext Endpoint. Oder wo würdest Du noch ein from_user= setzen wollen? Weil Du ja im Endpoint ein from_user= bereits hast. Oder meinst Du den contact= im AoR? Oh je, ich stehe gerade wirklich auf dem Schlauch.

Er nimmt den Kontext Namen des Endpoints.

Das ist dann richtig seltsam. Gut, so kannst Du das kontrollieren. Aber dann hätte ich erwartet, dass er den from_user= aus dem Endpoint nimmt/überschreibt/vererbt, denn der ist ja spezieller und wird für alles andere (?) benutzt. Hast Du das bereits mal in der Englisch-sprachigen Asterisk-Community angesprochen: E-Mail oder Web?

 

[IEEE]

Tut mir leid, es ist meine Schuld dass dieser Thread jetzt ein bisschen verwirrend geworden ist. Weil ich ja mit dem Startpost eine ganz andere Frage gestellt und im Zuge dessen eine pjsip.conf gepostet habe, die aus einem Teststadium von vor ein paar Tagen mit einem völlig anderen Provider stammt.

Mittlerweile bin ich im Produktivbetrieb und hier habe ich jetzt meinen echten VoiP Anbieter. Meine pjsip.conf von oben ist immer noch eine brauchbare Referenz ABER das "from_user" im Endpoint Kontext muss man sich weg denken. Das kann ich wie gesagt bei meinem produktiven Anbieter nicht setzen, weil sonst würde dieser from_user in meinen ausgehenden INVITE Paketen landen wenn ich jemand anrufe. Mein Anbieter will aber hier im From Feld meine vollständige Absenderrufnummer drin haben. Setze ich dennoch einen from_user, dann overruled dieser alle CallerIDs die ich im Wählplan setze und ich bin nicht mehr in der Lage abgehend Durchwahlen als Absender zu schicken.

Ich werd mit dem Thema mal in die Asterisk Community schauen, auch wenns wie gesagt wirklich eine Kleinigkeit und für den täglichen Betrieb kaum von Bedeutung ist.
Ein bisschen stört mich einfach, dass hier Felder raus geschickt werden, die ich bisher für privat gehalten habe. Ich bins nicht gewohnt dass interne Config Bezeichnungen nach außen geschickt werden.
Also würde ich jetzt als Kontextname [MeinUnsympathischerProvider] nehmen (das ist er nicht, der ist schwer in Ordnung, nur als Beispiel), dann wird das einfach so an ihn geschickt. Missfällt mir irgendwie.

 

[sonyKatze]

bisschen stört mich einfach

Ja, empfinde ich auf den ersten Blick auch falsch. Daher mal in der Asterisk-Community fragen und uns dann bitte verlinken bzw. Rückmeldung geben.

das "from_user" im Endpoint Kontext muss man sich weg denken. Das kann ich wie gesagt bei meinem produktiven Anbieter nicht setzen, weil sonst würde dieser from_user in meinen ausgehenden INVITE Paketen landen wenn ich jemand anrufe. Mein Anbieter will aber hier im From Feld meine vollständige Absenderrufnummer drin haben. Setze ich dennoch einen from_user, dann overruled dieser alle CallerIDs die ich im Wählplan setze und ich bin nicht mehr in der Lage abgehend Durchwahlen als Absender zu schicken.

Das habe ich jetzt leider noch gar nicht verstanden. Mit „landen“ assoziiere ich den Dialplan, also die Konfigurationsdatei extensions.conf. Wäre vielleicht ein eigener Thread wert, damit man sich das anschaut.

 

[IEEE]

Danke, aber nein, ist keinen eigenen Thread wert.
Es geht nur darum, dass der from_user Parameter im Endpoint das tut, weswegen er wohl from_user heißt. Er schickt dann bei allen Paketen diesen Usernamen im FROM Feld. Das ist ein durchgängiges Verhalten von asterisk seit schon immer (nur war es bei chan_sip der Parameter fromuser).
Und diesen from_user darf ich bei meinem Provider nicht setzen, weil wenn ich jemand anrufe dann will der Provider meine Absendernummer da drin stehen haben (die ich vorher im Diaplan mit dem CallerID Funktionen setze) und keinen statischen Usernamen. Aber wie gesagt, das ist nicht weiter verfolgenswert. Das mit den Options Paketen eventuell schon, da schau ich mal in die Asterisk Community wenn ich etwas Luft habe.

 

[sonyKatze]

Ach so, der from_user überschreibt auch die im Dialplan gesetzte Caller-ID. Puh. Hätte ich jetzt so herum auch nicht erwartet.

 

[IEEE]

Hätte ich jetzt so herum auch nicht erwartet.

Wirkich? Das war schon immer so. Also da bin ich das erste mal 2009 drüber gefallen. Im Prinzip ist es ja okay, was sonst sollte ein Parameter namens from_user (respektive fromuser bei chan_sip) auch machen? Und bei manchen Providern ist es ja auch erforderlich dass der Username immer im From steht, denen schickt man die Absendernummer halt dann bei Bedarf über irgendeinen Header oder sie erlauben es ohnehin nicht, eine zu setzen (zb. Einzelaccount Szenario).

Ich als asterisk Neuling damals musste da halt erst mal drauf kommen. Lang ists her.