I’ve tested with two different UA types and same thing happens, must be a
result of the B2BUA sending the alias in the To header of the invite.
Example -
2020/04/10 12:31:36.851987 Proxy_IP:5060 -> NAT_Device_IP:58090
INVITE sip:399@UA1_IP:60916;rinstance=8ec7d4acf9c3436c SIP/2.0
Record-Route:
The FQDN must be in the Contact of the OPTIONS request that is used for the
trunk keep alive. No need to mess up with the Contact header for in dialog
requests/replies.
However, the FQDN must be in the Record-Route header facing MS for in
dialog requests/replies.
Regards,
Ovidiu Sas
On Fri, Apr
Hi,
Like in Hennings howto described if the front facing Kamailio used the FQDN
names in contact and so one it works.
And the "must be an certified sbc" is an marketing foo and for support
cases they can say "go-to your sbc vendor" imho.
I had this setup up and running.
Kind regards
Karsten
Contact:
Again, MS says it expects FQDN in Contact.
If you are re-writing the Contact received from
ENDPOINT_BEHIND_KAMAILIO_IP, then I suggest you don't, it's sufficient to
have FQDN in RR. This isn't a "[certified] SBC", if it was like MS says -
it shouldn't work at all with a proxy like
You're likely referring to this:
*Priority 1. Top-level Record-Route. If the top-level Record-Route contains
the FQDN name or IP, the FQDN name or IP is used to make the outbound
in-dialog connection.*
Like with many Microsoft products, nobody knows precisely what they expect.
To make matters
I thought they look only at first RR field?
пт, 10 апр. 2020 г. в 17:03, Sergiu Pojoga :
> You have too many RR of Kamailio, x1 FQDN, x3 IP. Why?
>
> IMO, you should have only 2 of Kamailio, if you're doing transport
> conversion. Both FQDNs + ";r2=on". MS clearly says FQDN everywhere, no IP,
>
You have too many RR of Kamailio, x1 FQDN, x3 IP. Why?
IMO, you should have only 2 of Kamailio, if you're doing transport
conversion. Both FQDNs + ";r2=on". MS clearly says FQDN everywhere, no IP,
especially RR
On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov
wrote:
> Thanks for the answer, I
Hi, Alex,
It's 16 virtual cores (8 physical plus HyperThreading) and 48GB of RAM.
Luis
On 4/10/20 8:02 AM, Alex Balashov wrote:
Luis,
I wonder, how many CPU cores/available hardware threads (taking into
account HyperThreading and all that—so just the number of CPUs in
/proc/cpuinfo) are
Luis,
I wonder, how many CPU cores/available hardware threads (taking into account
HyperThreading and all that—so just the number of CPUs in /proc/cpuinfo) are
available here? It almost sounds like something which would occur with maybe 1
or 2 CPUs being contended over. Perhaps the simplest
Thanks for the answer, I have disabled forse_rport() for Teams side,
responses now going to address in Via header, but it is not resolved my
issue, no ACK from Teams :(
чт, 9 апр. 2020 г. в 18:22, Sergiu Pojoga :
> Hi Aydar,
>
> Request from MS proxy has VIA: SIP/2.0/TLS 52.114.7.24:5061,
From: ;tag=64f4b712
Something wrong with the above From, no closing ">", also there's no place
for *alias *in From headers.
On Fri, Apr 10, 2020 at 1:25 AM Daniel W. Graham wrote:
> Have an issue with BYE routing in a lab setup, any suggestions on what I
> should be looking at?
>
>
>
>
11 matches
Mail list logo
