2 Sipgate Trunks pjsip

Hello everyone.
I started working with Asterisk (16) again and I am confronted with pjsip for the first time.
Here is my question:
I have 2 Sipgate Trunks private and business which have the usernames XXXXXXe0@sipgate .de and XXXXXXe1@sipgate .de

I configured both in pjsip.conf, but both are routed to the same extensions, because -as I guess - the first host matches in die identity
[sipgatebusiness_identity]
type = identify
endpoint = sipgatebusiness
match = sipgate.de

I googled and found out that I can change to identification by username, but this didn’t change anything.
So how do I accomplish to safely route business-calls to the business-context and private to private?

Thank you for any hint!

You can try using line support[1] to differentiate the registrations.

[1] https://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/

If it is really a trunk, you may have to evaluate the P-CALLED-PARTY-ID header.

Hello Jcolp,

thank you for your reply.
I tried adding line=yes, but if I do that it doesn’t register anymore. So I guess this is not working with sipgate :frowning:

@EkFudrek:
Thank you for this advice. I googled a little and I found the function PJSIP_HEADER(read,To)
I can print the USERNAME@sipgate.de so I think the way to go is to differantiate between the called party.

if User 1234567e0@sipgate.de -> goto private context
else ->goto business context

I will try that, but right now I am stuck, because I can’t get that into a variable to work with it.

same => n,NoOp(SIP To : {PJSIP_HEADER(read,To)) same = n,Set(calledsipgatetmp={PJSIP_HEADER(read,To)})
same = n,NoOp(${calledsipgatetmp})

NoOp returns empty… I will come back if I find the solution for someone else who might need it.

It should not stop registration from occurring, if it did then you may have misconfigured things which would be stated at startup.

I do not think that you really need to deal with the SIP headers yourself. The standard setup is such that it works pretty much out of the box.

Somewhere else here are complete configurations for German Telekom products. There is nothing really special there. You may have to remove the “loose routing” option (lr). But I actually do not know whether it hurts in case strict routing is needed. If the names resolve properly and there aren’t any “vias”, it shouldn’t matter (you may report, :slight_smile: ).

Trunks are a bit different as you register a single number instead of all. In that case you may have to evaluate the P-CALLED-PARTY-ID header manually. German Telekom requires it and they describe the procedures in their technical documents 1TR114 and 1TR118. This is because all incoming calls use the contact of the original registration. It looks a bit clumsy, but I guess SIP was never made for the equivalent of the so-called “Anlagenanschluesse”. Again, try to stay away from directly manipulating or evaluating the headers.

It is not german Telekom. It is sipgate.de
and the special thing is that I am using different sipgate accounts. Asterisk is identifying them by the host and they all have the same IP…

I solved it like this
[sipgate-in]
exten = _X.,1,Noop(Processing an incoming call from {CALLERID(num)}) ;same = n,NoOp(SIP From: {PJSIP_HEADER(read,From)})
;same = n,NoOp(SIP To : {PJSIP_HEADER(read,To)}) same = n,Set(calledsipgatetmp={PJSIP_HEADER(read,To)})
same = n,Set(calledsipgateprivat={REGEX("(*privateuserid|privatenumber*@sipgate.de|*alternativeprivatenumber*@sipgate.de)" {calledsipgatetmp})})
same = n,Set(calledsipgatebusiness={REGEX("(*businessnumber|businessuser*@sipgate.de)" {calledsipgatetmp})})
;same = n,NoOp({calledsipgateprivat}) ;Wenn privater Anruf, dann privat, same = n,GosubIf(["{calledsipgateprivat}" = "1"]?sipgate-privat-in,s,1) same = n,GosubIf(["${calledsipgatebusiness}" = “1”]?sipgate-business-in,s,1:sipgate-other-in,s,1)

I was aware that it is sipgate. My point was that the Telekom config should work for sipgate as well, provided you replace the names. Your dialplan is currently not so interesting; your pjsip.conf files are.

PS, I doubt that you really need to handle this in the dial plan.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.