asterisk users - Jun 2017 - pjsip: Inbound calls: selecting the correct trunk with one provider and different numbers

Hello Joshua,

thank you very much for your extremely quick answer! I really appreciate
your work and your friendly and your patient support!


On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>> Hello!
>>
>> I've got a problem to select the correct trunk if there is one
provider
>> and different numbers with different configurations for this same
>> provider.
>>
>> Example:
>>
>> trunk-prov1-2345
>> trunk-prov1-2346
>> trunk-prov1-2347
>>
>> Each trunk registers an own number (at the same provider) and provides
>> own configuration: they have different allowed codecs e.g..
>>
>> What I'm experiencing now, is, that each incoming call is provided
by
>> trunk-prov1-2346, no matter which number has been dialed.
>>
>> The problem isn't the routing (this is done on base of the correct
DID),
>> but the problem is, that wrong codices are used if the wrong trunk is
>> selected.
>>
>> Is this a problem of asterisk or is it caused by the provider, which
>> always addresses the same "trunk" regardless which number has
been
>> called?
> 
> Asterisk is the one who associates an incoming message with an endpoint.
> In the case of providers you can use IP based matching - which would
> behave as you see, only one can be matched. The second option is the
> line option[1] which may or may not work (it depends on the behavior of
> the provider). If it works then the right endpoint would be chosen. Out
> of those two options there's nothing else applicable built in to match.
> 
> [1]
>
http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
> 
Unfortunately Deutsche Telekom doesn't support this solution :-(. I
tried it by faking DNS entries and use different server names to get
different IP addresses. Unfortunately, this doesn't work, because the
name wasn't accepted by the ISP. Using the IP address directly isn't a
good solution, too, because you can't receive changes any more.

A "solution" would be via regularly created rpz DNS entries, which are
used to resolve a fake server name (like fake1.real.name.com) by
asterisk to the desired IP. All other string operations would use the
real.name.com.

Ok, it's a pipe dream!


Regards,
Michael

On 06/08/2017 at 10:22 PM Michael Maier wrote:
> Hello Joshua,
> 
> thank you very much for your extremely quick answer! I really appreciate
> your work and your friendly and your patient support!
> 
> 
> On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
>> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>>> Hello!
>>>
>>> I've got a problem to select the correct trunk if there is one
provider
>>> and different numbers with different configurations for this same
>>> provider.
>>>
>>> Example:
>>>
>>> trunk-prov1-2345
>>> trunk-prov1-2346
>>> trunk-prov1-2347
>>>
>>> Each trunk registers an own number (at the same provider) and
provides
>>> own configuration: they have different allowed codecs e.g..
>>>
>>> What I'm experiencing now, is, that each incoming call is
provided by
>>> trunk-prov1-2346, no matter which number has been dialed.
>>>
>>> The problem isn't the routing (this is done on base of the
correct DID),
>>> but the problem is, that wrong codices are used if the wrong trunk
is
>>> selected.
>>>
>>> Is this a problem of asterisk or is it caused by the provider,
which
>>> always addresses the same "trunk" regardless which number
has been
>>> called?
>>
>> Asterisk is the one who associates an incoming message with an
endpoint.
>> In the case of providers you can use IP based matching - which would
>> behave as you see, only one can be matched. The second option is the
>> line option[1] which may or may not work (it depends on the behavior of
>> the provider). If it works then the right endpoint would be chosen. Out
>> of those two options there's nothing else applicable built in to
match.
>>
>> [1]
>>
http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
>>
> 
> Unfortunately Deutsche Telekom doesn't support this solution :-(.
Further investigation showed, that Telekom provides the line info in the
Request Line (as seen by Wireshark):

Request-Line: INVITE sip:+49xxxx at 46.37.15.4:5060;line=azpreyb SIP/2.0

You can't find it if you expect it in contact header - or do you expect
it in the Request-Line?


Regards,
Michael

On 06/09/2017 at 08:44 PM Michael Maier wrote:
> On 06/08/2017 at 10:22 PM Michael Maier wrote:
>> Hello Joshua,
>>
>> thank you very much for your extremely quick answer! I really
appreciate
>> your work and your friendly and your patient support!
>>
>>
>> On 06/07/2017 at 10:33 PM, Joshua Colp wrote:
>>> On Wed, Jun 7, 2017, at 05:28 PM, Michael Maier wrote:
>>>> Hello!
>>>>
>>>> I've got a problem to select the correct trunk if there is
one provider
>>>> and different numbers with different configurations for this
same
>>>> provider.
>>>>
>>>> Example:
>>>>
>>>> trunk-prov1-2345
>>>> trunk-prov1-2346
>>>> trunk-prov1-2347
>>>>
>>>> Each trunk registers an own number (at the same provider) and
provides
>>>> own configuration: they have different allowed codecs e.g..
>>>>
>>>> What I'm experiencing now, is, that each incoming call is
provided by
>>>> trunk-prov1-2346, no matter which number has been dialed.
>>>>
>>>> The problem isn't the routing (this is done on base of the
correct DID),
>>>> but the problem is, that wrong codices are used if the wrong
trunk is
>>>> selected.
>>>>
>>>> Is this a problem of asterisk or is it caused by the provider,
which
>>>> always addresses the same "trunk" regardless which
number has been
>>>> called?
>>>
>>> Asterisk is the one who associates an incoming message with an
endpoint.
>>> In the case of providers you can use IP based matching - which
would
>>> behave as you see, only one can be matched. The second option is
the
>>> line option[1] which may or may not work (it depends on the
behavior of
>>> the provider). If it works then the right endpoint would be chosen.
Out
>>> of those two options there's nothing else applicable built in
to match.
>>>
>>> [1]
>>>
http://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/
>>>
>>
>> Unfortunately Deutsche Telekom doesn't support this solution :-(.
> 
> Further investigation showed, that Telekom provides the line info in the
> Request Line (as seen by Wireshark):
> 
> Request-Line: INVITE sip:+49xxxx at 46.37.15.4:5060;line=azpreyb SIP/2.0
> 
> You can't find it if you expect it in contact header - or do you expect
> it in the Request-Line?
Ok - got it.

It's necessary, that the value given for endpoint= is exactly the same
name as used for the trunk name itself and the match option for this
trunk should be omitted completely.


Thanks,
Michael

On Fri, Jun 9, 2017, at 03:44 PM, Michael Maier wrote:

<snip>
> 
> Further investigation showed, that Telekom provides the line info in the
> Request Line (as seen by Wireshark):
> 
> Request-Line: INVITE sip:+49xxxx at 46.37.15.4:5060;line=azpreyb SIP/2.0
> 
> You can't find it if you expect it in contact header - or do you expect
> it in the Request-Line?
Recent code checks the To URI and the Request URI.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org