Hello,
this logic is definitely wrong -- FreeSwitch can send also a request, it means that you send it back to it.
Only the initial request of a dialog should be routed with rules like dispatcher/load balancer/least cost routing/... The requests within dialog should be routed based on loose routing.
Of course, one can think of exceptions, but then you should be fully aware of what kind of routing you do.
Cheers,
Daniel
Hello Daniel,My setup is proxy all requests to freeswitch via dispatcher.Slava.From: "Daniel-Constantin Mierla" <miconda@gmail.com>
To: "volga629" <volga629@skillsearch.ca>, "sr-users" <sr-users@lists.sip-router.org>
Sent: Thursday, 10 November, 2016 04:56:53
Subject: Re: [SR-Users] BYE dispatcherHello,
as I said before, the registrations have little to do with calls in sip, unless there is gruu in use.
Cheers,
DanielOn 09/11/16 18:07, Slava Bendersky wrote:Hello Everyone,I cleared registrations and tried again and issue still present.Client reply with 481.IP (tos 0x0, ttl 52, id 7731, offset 0, flags [none], proto UDP (17), length 638)
client_pub_ip.49383 > proxy_pub_ip.llrp: [udp sum ok] UDP, length 610
E..~.3..4...c....E.\.....j..SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP proxy_pub_ip:5084;branch=z9hG4bK3ea6.0c594485bff5b216f30af0f6172cb2b9.0
Via: SIP/2.0/UDP 10.18.130.24:5160;received=10.18.130.24;rport=5160;branch=z9hG4bKm80c0USSKv5Bp
From: "Test Extension" <sip:4300@sip.company.tld>;tag=SXt3DQQ90a0Dj
To: <sip:4300@client_pub_ip:49383>;tag=719973534
Call-ID: 1abc150b-2141-1235-b5ad-5254003e39bb
CSeq: 99019404 BYE
Supported: replaces, path, eventlist
User-Agent: Grandstream Wave 1.2.2
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0Slava.
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com