< Previous by Date Date Index  
< Previous in Thread Thread Index  

Re: [repro-users] route fail with same destination

Sorry I'm not following the question.


On Wed, Jun 19, 2019 at 7:37 AM Nikolay Shopik <shopik@xxxxxxxxxx> wrote:
Yeah, so problem is "no matching transport" is actually means both sides
doesn't speak same protocols.

This is usually fine if its just different endpoints within same repro
and its domains, but if its remote route it won't able connect TCP
endpoint with TLS remote route for example, due to that error.

Can I make it work and translate protocol with remote route?

On 19/6/19 10:24 am, Nikolay Shopik wrote:
> Hi Scott,
> Ah, no my match route _expression_ is actually correct they looks like
> ^sip:100@example\.com -> sip:100@xxxxxxxxxxxxxxx (working)
> ^sip:(0099[0-9]{9})@example\.com -> sip:$1@xxxxxxxxxxxxxxx (failing)
> so route matching is fine but it isn't clear why it can't found
> transport for second one and thus fail with error i mention. Any ideas
> what I should look into?
> For port matching this is remote trunk side(asterisk) so it like
> federated system for me. You saying that remote side should omit port
> when sending invite request? Why including port :5061 working as same as
> no port in requested invite. From my understanding invite uri can have
> port with basically matches original transport level port it sending.
> On 17/06/2019 17:54, slgodin@xxxxxxxxx wrote:
>> Hi Nikolay,
>> The $1 is not correct for a route match _expression_, it is a valid
>> destination string only.
>> You probably wanted:
>> sip:.*@pbx.example.net
>> As for the port matching problem. Repro is behaving as an rfc 3261
>> compliant proxy.  The registration aor must fully match the request
>> lines for messages sent to the proxy.  You should configure your
>> client to not send the port in the request line.  Use some form of
>> outbound proxy setting, if you need to hit a specific port.
>> Scott
>>> On Jun 17, 2019, at 9:58 AM, Nikolay Shopik <shopik@xxxxxxxxxx> wrote:
>>> I have 2 routes both points to same destination only difference is one
>>> is without any substitution:
>>> sip:100@xxxxxxxxxxxxxxx
>>> sip:$1@xxxxxxxxxxxxxxx
>>> But second always fail with "Can't find matching transport".
>>> What I'm missing here, why it can fail even though first one correctly
>>> processed?
>>> Also I'm having issue when I use non-standard port for secondary
>>> transport like pbx.example.net:8443 if remote side try send to it it
>>> will get "no targets for sip:100@xxxxxxxxxxx:8443 send 480".
>>> Both 5061 and 8443 serve same domain and it works fine if we receive
>>> request on 5061, request correctly forwarded to AOR.
>>> _______________________________________________
>>> repro-users mailing list
>>> repro-users@xxxxxxxxxxxxxxx
>>> https://list.resiprocate.org/mailman/listinfo/repro-users
> _______________________________________________
> repro-users mailing list
> repro-users@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/repro-users