Re: [SR-Users] Callee BYE routing issue

[Daniel W. Graham]

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: 
Via: SIP/2.0/UDP Proxy_IP;branch=z9hG4bKbfa9.767ffbe5f0e31be8c27932008d28844e.0
Via: SIP/2.0/UDP B2BUA_IP:5160;received= 
B2BUA_IP;branch=z9hG4bK22bd58aa;rport=5160
Max-Forwards: 69
From: "Dan Test" ;tag=as4220330a
To: 

Contact: 
Call-ID: 1835b7eb541743600e1b79c07615206c@ B2BUA_IP:5160
CSeq: 102 INVITE
User-Agent: xx
Date: Fri, 10 Apr 2020 16:31:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "Dan Test" 
Content-Type: application/sdp
Content-Length: 566

The alias is in the contact header for the invite sent by kamailio, so 
everything looks fine there.

Thanks,

-dan


From: sr-users  on behalf of Sergiu Pojoga 

Reply-To: "Kamailio (SER) - Users Mailing List" 
Date: Friday, April 10, 2020 at 2:29 AM
To: "Kamailio (SER) - Users Mailing List" 
Subject: Re: [SR-Users] Callee BYE routing issue

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 
mailto:d...@cmsinter.net>> wrote:
Have an issue with BYE routing in a lab setup, any suggestions on what I should 
be looking at?

Topology:

UA1  <-> NAT device 1 <-> Proxy1 <-> Registrar/B2BUA <-> Proxy1 <-> NAT device 
1 <-> UA2

All UA to UA calls flow through B2BUA.

All IP’s are public except for UA1 and UA2.

-Both endpoints can call each other.
-If the caller hangs up first, BYE is routed properly.
-If the callee hangs up first, BYE causes proxy to send 478.

On calls where BYE results in 478:
if(!isdsturiset()) {
………..not executed
handle_ruri_alias()
}
return;

Example issue call: UA2 to UA1, UA1 hang-up.

Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=16 n=if
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=532 a=24 
n=isdsturiset
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=2 
n=return
………..
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [ut.h:245]: uri2dst2(): 
bad_uri: [sip::;transport=]
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [t_fwd.c:1732]: 
t_forward_nonack(): failure to add branches
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=275 a=24 
n=sl_reply_error
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} sl [sl_funcs.c:401]: 
sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL)
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=277 a=2 n=exit

2020/04/10 00:31:28.625060 NAT_Device_IP:57808 -> Proxy_IP:5060
BYE sip:398@B2BUA_IP:5160 SIP/2.0
Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---43b5f31829f20952
Max-Forwards: 70
Route: 
Contact: 
To: "Dan Test" ;tag=as78671fd9
From: 
;tag=64f4b712
Call-ID: 24dc84a4592515245177483c2a657042@B2BUA_IP:5160
CSeq: 2 BYE
User-Agent: 
Content-Length: 0

#

For comparison, here is a BYE from another test call: UA1 to UA2, UA1 hang-up.

This BYE was routed correctly.

2020/04/10 00:44:02.688608 NAT_Device_IP:57808 -> Proxy_IP:5060
BYE sip:398@B2BUA_IP:5160 SIP/2.0
Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---ce36df02e8a80a48
Max-Forwards: 70
Route: 
Contact: 
To: ;tag=as5874901f
From: ;tag=9078f232
Call-ID: 103104NGU1NjkxNGZkYmM4MzA3Y2FkMzY1OGNkZTZmMTMyZDU
CSeq: 3 BYE
User-Agent: 
Authorization: Digest username= 
Content-Length: 0

-dan

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio as SBC for Teams

[Ovidiu Sas]

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 10, 2020 at 12:59 Karsten Horsmann  wrote:

> 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 Horsmann
>
> Sergiu Pojoga  schrieb am Fr., 10. Apr. 2020, 18:27:
>
>> 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 Kamailio.
>>
>> On Fri, Apr 10, 2020 at 12:00 PM Sergiu Pojoga  wrote:
>>
>>> 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 worse - they don't reply back suggesting what's
>>> wrong, no tools on their side to troubleshoot.
>>>
>>> Regardless, why do you have 3 RRs of Kamailio? Fix the RRs, try again,
>>> or don't, it's up to you.
>>>
>>> Good luck.
>>>
>>> --Sergiu
>>>
>>>
>>> On Fri, Apr 10, 2020 at 11:42 AM Aidar Kamalov 
>>> wrote:
>>>
 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,
> especially RR
>
> On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
> wrote:
>
>> 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,
>>> that's where your reply should go. You're sending to
>>> 52.114.7.24:1024 instead?
>>>
>>> Also, looks like you're missing "r2=on" on the other RR, only one
>>> has it.
>>>
>>> Cheers,
>>>
>>> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov <
>>> aidar.kama...@gmail.com> wrote:
>>>
 Hello,

 I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying
 to use kamailio for teams.
 But I faced that MS not responding ACK to my 200OK. Somethin is
 wrong, but I don't know what. I call from teams to kamailio.
 Can you help me please

 This is initial INVITE from Teams:
 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
 INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
 SIP/2.0
 FROM: Aidar Kamalov>>> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
 TO: 
 CSEQ: 1 INVITE
 CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
 MAX-FORWARDS: 70
 VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
 RECORD-ROUTE: >>> ;transport=tls;lr>
 CONTACT: >>> ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
 CONTENT-LENGTH: 2426
 USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
 CONTENT-TYPE: application/sdp
 ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

 v=0
 o=- 0 0 IN IP4 52.114.252.146
 s=session
 c=IN IP4 52.114.252.146
 b=CT:5
 t=0 0
 m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
 a=rtcp:52925
 a=ice-ufrag:rKBm
 a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
 a=rtcp-mux
 a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
 31.13.144.55 rport 57780
 a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
 31.13.144.55 rport 57781
 a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
 a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
 a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
 a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
 a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
 100.78.247.179 rport 

Re: [SR-Users] kamailio as SBC for Teams

[Karsten Horsmann]

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 Horsmann

Sergiu Pojoga  schrieb am Fr., 10. Apr. 2020, 18:27:

> 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 Kamailio.
>
> On Fri, Apr 10, 2020 at 12:00 PM Sergiu Pojoga  wrote:
>
>> 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 worse - they don't reply back suggesting what's
>> wrong, no tools on their side to troubleshoot.
>>
>> Regardless, why do you have 3 RRs of Kamailio? Fix the RRs, try again, or
>> don't, it's up to you.
>>
>> Good luck.
>>
>> --Sergiu
>>
>>
>> On Fri, Apr 10, 2020 at 11:42 AM Aidar Kamalov 
>> wrote:
>>
>>> 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,
 especially RR

 On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
 wrote:

> 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, that's
>> where your reply should go. You're sending to 52.114.7.24:1024
>> instead?
>>
>> Also, looks like you're missing "r2=on" on the other RR, only one has
>> it.
>>
>> Cheers,
>>
>> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov <
>> aidar.kama...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to
>>> use kamailio for teams.
>>> But I faced that MS not responding ACK to my 200OK. Somethin is
>>> wrong, but I don't know what. I call from teams to kamailio.
>>> Can you help me please
>>>
>>> This is initial INVITE from Teams:
>>> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
>>> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
>>> SIP/2.0
>>> FROM: Aidar Kamalov>> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>>> TO: 
>>> CSEQ: 1 INVITE
>>> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
>>> MAX-FORWARDS: 70
>>> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
>>> RECORD-ROUTE: >> ;transport=tls;lr>
>>> CONTACT: >> ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
>>> CONTENT-LENGTH: 2426
>>> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
>>> CONTENT-TYPE: application/sdp
>>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>>>
>>> v=0
>>> o=- 0 0 IN IP4 52.114.252.146
>>> s=session
>>> c=IN IP4 52.114.252.146
>>> b=CT:5
>>> t=0 0
>>> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
>>> a=rtcp:52925
>>> a=ice-ufrag:rKBm
>>> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
>>> a=rtcp-mux
>>> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
>>> 31.13.144.55 rport 57780
>>> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
>>> 31.13.144.55 rport 57781
>>> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
>>> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
>>> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
>>> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
>>> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
>>> 100.78.247.179 rport 39182
>>> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
>>> 100.78.247.179 rport 39183
>>> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>>> 100.78.247.179 rport 41775
>>> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>>> 100.78.247.179 rport 41775
>>> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay
>>> raddr 31.13.144.55 rport 9761
>>> a=candidate:6 2 

Re: [SR-Users] kamailio as SBC for Teams

[Sergiu Pojoga]

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 Kamailio.

On Fri, Apr 10, 2020 at 12:00 PM Sergiu Pojoga  wrote:

> 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 worse - they don't reply back suggesting what's
> wrong, no tools on their side to troubleshoot.
>
> Regardless, why do you have 3 RRs of Kamailio? Fix the RRs, try again, or
> don't, it's up to you.
>
> Good luck.
>
> --Sergiu
>
>
> On Fri, Apr 10, 2020 at 11:42 AM Aidar Kamalov 
> wrote:
>
>> 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,
>>> especially RR
>>>
>>> On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
>>> wrote:
>>>
 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, that's
> where your reply should go. You're sending to 52.114.7.24:1024
> instead?
>
> Also, looks like you're missing "r2=on" on the other RR, only one has
> it.
>
> Cheers,
>
> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov 
> wrote:
>
>> Hello,
>>
>> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to
>> use kamailio for teams.
>> But I faced that MS not responding ACK to my 200OK. Somethin is
>> wrong, but I don't know what. I call from teams to kamailio.
>> Can you help me please
>>
>> This is initial INVITE from Teams:
>> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
>> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
>> SIP/2.0
>> FROM: Aidar Kamalov> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>> TO: 
>> CSEQ: 1 INVITE
>> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
>> MAX-FORWARDS: 70
>> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
>> RECORD-ROUTE: > ;transport=tls;lr>
>> CONTACT: > ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
>> CONTENT-LENGTH: 2426
>> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
>> CONTENT-TYPE: application/sdp
>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>>
>> v=0
>> o=- 0 0 IN IP4 52.114.252.146
>> s=session
>> c=IN IP4 52.114.252.146
>> b=CT:5
>> t=0 0
>> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
>> a=rtcp:52925
>> a=ice-ufrag:rKBm
>> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
>> a=rtcp-mux
>> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
>> 31.13.144.55 rport 57780
>> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
>> 31.13.144.55 rport 57781
>> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
>> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
>> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
>> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
>> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
>> 100.78.247.179 rport 39182
>> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
>> 100.78.247.179 rport 39183
>> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>> 100.78.247.179 rport 41775
>> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>> 100.78.247.179 rport 41775
>> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay
>> raddr 31.13.144.55 rport 9761
>> a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay
>> raddr 31.13.144.55 rport 9761
>> a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay
>> raddr 31.13.144.55 rport 9761
>> a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay
>> raddr 31.13.144.55 rport 9761
>> a=x-candidate-info:4 network-type=WWAN
>> a=x-candidate-info:1 network-type=WWAN
>> a=x-candidate-info:2 network-type=WWAN
>> a=x-candidate-info:3 network-type=WWAN
>> a=x-candidate-info:5 

Re: [SR-Users] kamailio as SBC for Teams

[Sergiu Pojoga]

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 worse - they don't reply back suggesting what's wrong, no
tools on their side to troubleshoot.

Regardless, why do you have 3 RRs of Kamailio? Fix the RRs, try again, or
don't, it's up to you.

Good luck.

--Sergiu


On Fri, Apr 10, 2020 at 11:42 AM Aidar Kamalov 
wrote:

> 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,
>> especially RR
>>
>> On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
>> wrote:
>>
>>> 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, that's
 where your reply should go. You're sending to 52.114.7.24:1024 instead?

 Also, looks like you're missing "r2=on" on the other RR, only one has
 it.

 Cheers,

 On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov 
 wrote:

> Hello,
>
> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to
> use kamailio for teams.
> But I faced that MS not responding ACK to my 200OK. Somethin is wrong,
> but I don't know what. I call from teams to kamailio.
> Can you help me please
>
> This is initial INVITE from Teams:
> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
> SIP/2.0
> FROM: Aidar Kamalov ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
> TO: 
> CSEQ: 1 INVITE
> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
> MAX-FORWARDS: 70
> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
> RECORD-ROUTE:  ;transport=tls;lr>
> CONTACT:  ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
> CONTENT-LENGTH: 2426
> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
> CONTENT-TYPE: application/sdp
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>
> v=0
> o=- 0 0 IN IP4 52.114.252.146
> s=session
> c=IN IP4 52.114.252.146
> b=CT:5
> t=0 0
> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
> a=rtcp:52925
> a=ice-ufrag:rKBm
> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
> a=rtcp-mux
> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
> 31.13.144.55 rport 57780
> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
> 31.13.144.55 rport 57781
> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
> 100.78.247.179 rport 39182
> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
> 100.78.247.179 rport 39183
> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
> 100.78.247.179 rport 41775
> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
> 100.78.247.179 rport 41775
> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay
> raddr 31.13.144.55 rport 9761
> a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay
> raddr 31.13.144.55 rport 9761
> a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=x-candidate-info:4 network-type=WWAN
> a=x-candidate-info:1 network-type=WWAN
> a=x-candidate-info:2 network-type=WWAN
> a=x-candidate-info:3 network-type=WWAN
> a=x-candidate-info:5 network-type=WWAN
> a=x-candidate-info:6 network-type=WWAN
> a=x-candidate-info:7 network-type=WWAN
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
> a=crypto:2 AES_CM_128_HMAC_SHA1_80
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
> a=crypto:3 AES_CM_128_HMAC_SHA1_80
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
> a=rtpmap:104 SILK/16000
> a=fmtp:104 useinbandfec=1; usedtx=0
> a=rtpmap:9 

Re: [SR-Users] kamailio as SBC for Teams

[Aidar Kamalov]

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,
> especially RR
>
> On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
> wrote:
>
>> 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, that's
>>> where your reply should go. You're sending to 52.114.7.24:1024 instead?
>>>
>>> Also, looks like you're missing "r2=on" on the other RR, only one has it.
>>>
>>> Cheers,
>>>
>>> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov 
>>> wrote:
>>>
 Hello,

 I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to
 use kamailio for teams.
 But I faced that MS not responding ACK to my 200OK. Somethin is wrong,
 but I don't know what. I call from teams to kamailio.
 Can you help me please

 This is initial INVITE from Teams:
 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
 INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
 SIP/2.0
 FROM: Aidar Kamalov>>> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
 TO: 
 CSEQ: 1 INVITE
 CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
 MAX-FORWARDS: 70
 VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
 RECORD-ROUTE: >>> ;transport=tls;lr>
 CONTACT: >>> ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
 CONTENT-LENGTH: 2426
 USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
 CONTENT-TYPE: application/sdp
 ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

 v=0
 o=- 0 0 IN IP4 52.114.252.146
 s=session
 c=IN IP4 52.114.252.146
 b=CT:5
 t=0 0
 m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
 a=rtcp:52925
 a=ice-ufrag:rKBm
 a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
 a=rtcp-mux
 a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
 31.13.144.55 rport 57780
 a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
 31.13.144.55 rport 57781
 a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
 a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
 a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
 a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
 a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
 100.78.247.179 rport 39182
 a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
 100.78.247.179 rport 39183
 a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
 100.78.247.179 rport 41775
 a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
 100.78.247.179 rport 41775
 a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
 31.13.144.55 rport 9761
 a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
 31.13.144.55 rport 9761
 a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
 31.13.144.55 rport 9761
 a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
 31.13.144.55 rport 9761
 a=x-candidate-info:4 network-type=WWAN
 a=x-candidate-info:1 network-type=WWAN
 a=x-candidate-info:2 network-type=WWAN
 a=x-candidate-info:3 network-type=WWAN
 a=x-candidate-info:5 network-type=WWAN
 a=x-candidate-info:6 network-type=WWAN
 a=x-candidate-info:7 network-type=WWAN
 a=crypto:1 AES_CM_128_HMAC_SHA1_32
 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
 a=crypto:2 AES_CM_128_HMAC_SHA1_80
 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
 a=crypto:3 AES_CM_128_HMAC_SHA1_80
 inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
 a=rtpmap:104 SILK/16000
 a=fmtp:104 useinbandfec=1; usedtx=0
 a=rtpmap:9 G722/8000
 a=rtpmap:111 SIREN/16000
 a=fmtp:111 bitrate=16000
 a=rtpmap:18 G729/8000
 a=rtpmap:0 PCMU/8000
 a=rtpmap:8 PCMA/8000
 a=rtpmap:103 SILK/8000
 a=fmtp:103 useinbandfec=1; usedtx=0
 a=rtpmap:97 RED/8000
 a=rtpmap:13 CN/8000
 a=rtpmap:118 CN/16000
 a=rtpmap:119 CN/24000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=ptime:20
 a=maxptime:200



 and my 200OK to MS is:

 2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024
 SIP/2.0 200 OK
 Record-Route:
 
 Record-Route:
 
 Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c
 

Re: [SR-Users] kamailio as SBC for Teams

[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,
especially RR

On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
wrote:

> 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, that's
>> where your reply should go. You're sending to 52.114.7.24:1024 instead?
>>
>> Also, looks like you're missing "r2=on" on the other RR, only one has it.
>>
>> Cheers,
>>
>> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov 
>> wrote:
>>
>>> Hello,
>>>
>>> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to use
>>> kamailio for teams.
>>> But I faced that MS not responding ACK to my 200OK. Somethin is wrong,
>>> but I don't know what. I call from teams to kamailio.
>>> Can you help me please
>>>
>>> This is initial INVITE from Teams:
>>> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
>>> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
>>> SIP/2.0
>>> FROM: Aidar Kamalov>> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>>> TO: 
>>> CSEQ: 1 INVITE
>>> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
>>> MAX-FORWARDS: 70
>>> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
>>> RECORD-ROUTE: >> ;transport=tls;lr>
>>> CONTACT: >> ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
>>> CONTENT-LENGTH: 2426
>>> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
>>> CONTENT-TYPE: application/sdp
>>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>>>
>>> v=0
>>> o=- 0 0 IN IP4 52.114.252.146
>>> s=session
>>> c=IN IP4 52.114.252.146
>>> b=CT:5
>>> t=0 0
>>> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
>>> a=rtcp:52925
>>> a=ice-ufrag:rKBm
>>> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
>>> a=rtcp-mux
>>> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
>>> 31.13.144.55 rport 57780
>>> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
>>> 31.13.144.55 rport 57781
>>> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
>>> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
>>> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
>>> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
>>> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
>>> 100.78.247.179 rport 39182
>>> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
>>> 100.78.247.179 rport 39183
>>> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>>> 100.78.247.179 rport 41775
>>> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>>> 100.78.247.179 rport 41775
>>> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
>>> 31.13.144.55 rport 9761
>>> a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
>>> 31.13.144.55 rport 9761
>>> a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
>>> 31.13.144.55 rport 9761
>>> a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
>>> 31.13.144.55 rport 9761
>>> a=x-candidate-info:4 network-type=WWAN
>>> a=x-candidate-info:1 network-type=WWAN
>>> a=x-candidate-info:2 network-type=WWAN
>>> a=x-candidate-info:3 network-type=WWAN
>>> a=x-candidate-info:5 network-type=WWAN
>>> a=x-candidate-info:6 network-type=WWAN
>>> a=x-candidate-info:7 network-type=WWAN
>>> a=crypto:1 AES_CM_128_HMAC_SHA1_32
>>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
>>> a=crypto:2 AES_CM_128_HMAC_SHA1_80
>>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
>>> a=crypto:3 AES_CM_128_HMAC_SHA1_80
>>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
>>> a=rtpmap:104 SILK/16000
>>> a=fmtp:104 useinbandfec=1; usedtx=0
>>> a=rtpmap:9 G722/8000
>>> a=rtpmap:111 SIREN/16000
>>> a=fmtp:111 bitrate=16000
>>> a=rtpmap:18 G729/8000
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:103 SILK/8000
>>> a=fmtp:103 useinbandfec=1; usedtx=0
>>> a=rtpmap:97 RED/8000
>>> a=rtpmap:13 CN/8000
>>> a=rtpmap:118 CN/16000
>>> a=rtpmap:119 CN/24000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=ptime:20
>>> a=maxptime:200
>>>
>>>
>>>
>>> and my 200OK to MS is:
>>>
>>> 2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024
>>> SIP/2.0 200 OK
>>> Record-Route:
>>> 
>>> Record-Route:
>>> 
>>> Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c
>>> Record-Route:
>>> 
>>> Record-Route:
>>> 
>>> Record-Route:
>>> 
>>> Record-Route:
>>> 
>>> Record-Route: >> ;transport=tls;lr>
>>> To: >> :5061;user=phone>;tag=3795432917-393759697
>>> From: >> 

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Luis Rojas G.]

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 available here? It almost sounds like something 
which would occur with maybe 1 or 2 CPUs being contended over. Perhaps 
the simplest thing for this kind of call volume is to run Kamailio on 
a host with 8 or 12+ CPU cores?


— Alex

—
Sent from my iPad

On Apr 10, 2020, at 2:20 AM, Luis Rojas G.  
wrote:



Hello,

I have a lot of experience developing mutithreaded applications, and 
I don't see it so unlikely at all that a process loses cpu just after 
recvfrom(). It's just as probable as to lose it just before, or when 
writing on a cache or just before of after sendto(). If there are 
many messages going through, some of them will fall in this scenario. 
if I try sending a burst of 100 messages, I see two or three 
presenting the scenario.


Just forward() with a single process does not give the capacity. I'm 
getting almost 1000caps. More than that and start getting errores, 
retransmissions, etc. And this is just one way. I need to receive the 
call to go back to the network (our application is a B2BUA), so I 
will be down to 500caps, with a simple scenario, with no reliable 
responses, reinvites, updates, etc. I will end up having as many 
standalone kamailio processes as the current servers I do have now.


I really think the simplest way would be to add a small delay to 200 
OK. Very small, like 10ms, should be enough. Simple and it should 
work. As Alex Balashov commented he did for the case with ACK-Re-Invite.


I have to figure out how to make async_ms_sleep() work in reply_route().

Thanks for all the comments and ideas

Best regards,

Luis



. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:



mico...@gmail.com appears similar to someone who previously sent you 
email, but may not be that person. Learn why this could be a risk 


Feedback 

Hello,

then the overtaking is in between reading from the socket and 
getting to parsing the call-id value -- the cpu is lost by first 
reader after recvfrom() and the second process get enough cpu time 
to go ahead further. I haven't encountered this case, but as I said 
previously, it is very unlikely, but still possible. I added the 
route_locks_size because in the past I had cases when processing of 
some messages took longer executing config (e.g., due to 
authentication, accounting, ..) and I needed to be sure they are 
processed in the order they enter config execution.


Then the option is to see if a single process with stateless sending 
out (using forward()) gives the capacity, if you don't do any other 
complex processing. Or if you do more complex processing, use a 
dispatcher process with forwarding to local host or in a similar 
manner try to use mqueue+rtimer for dispatching using shared memory 
queues.


Of course, it is open source and there is also the C coding way, to 
add a synchronizing mechanism to protect against parallel execution 
of the code from recvfrom() till call-id lock is acquired.


Cheers,
Daniel

On 09.04.20 17:37, Luis Rojas G. wrote:

Hello,

Well, it did not work at all. Exactly same behavior, with random 
out of order messages.


Best regards,

Luis

On 4/9/20 11:28 AM, Daniel-Constantin Mierla wrote:



mico...@gmail.com appears similar to someone who previously sent 
you email, but may not be that person. Learn why this could be a 
risk 

Feedback 

Hello,

the sip messages belonging to the same dialog have the same value 
for Call-Id header. The locking is done based on hashing the 
Call-Id, so it doesn't need at all the dialog module for its purpose.


Cheers,
Daniel

On 09.04.20 14:19, Luis Rojas G. wrote:

Hello, Daniel,

I am not so sure. I first tried adding that parameter, but it did 
not work at all.  Same behavior. Then I read the documentation 
more carefully :


https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size


  route_locks_size

Set the number of mutex locks to be used for synchronizing the 
execution of messages sharing the same Call-Id. In other words, 
enables Kamailio to execute the config script sequentially for 
the requests and replies received *within the same dialog* – a 
new message received *within the same dialog* waits until the 
previous one is routed out.


Locks to execute sequentially messages belonging to same dialog. 
How will Kamailio be aware that messages belong to same dialog, 
without the dialog module?. With just stateless proxy it has no 
idea about dialogs, it just forwards messages. I guess that's why 
just adding that parameter did not work.


Am I wrong?

Luis

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Alex Balashov]

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 thing for this kind of 
call volume is to run Kamailio on a host with 8 or 12+ CPU cores?

— Alex

—
Sent from my iPad

> On Apr 10, 2020, at 2:20 AM, Luis Rojas G.  wrote:
> 
> 
> Hello,
> 
> I have a lot of experience developing mutithreaded applications, and I don't 
> see it so unlikely at all that a process loses cpu just after recvfrom(). 
> It's just as probable as to lose it just before, or when writing on a cache 
> or just before of after sendto(). If there are many messages going through, 
> some of them will fall in this scenario. if I try sending a burst of 100 
> messages, I see two or three presenting the scenario.
> 
> Just forward() with a single process does not give the capacity. I'm getting 
> almost 1000caps. More than that and start getting errores, retransmissions, 
> etc. And this is just one way. I need to receive the call to go back to the 
> network (our application is a B2BUA), so I will be down to 500caps, with a 
> simple scenario, with no reliable responses, reinvites, updates, etc. I will 
> end up having as many standalone kamailio processes as the current servers I 
> do have now.
> 
> I really think the simplest way would be to add a small delay to 200 OK. Very 
> small, like 10ms, should be enough. Simple and it should work. As Alex 
> Balashov commented he did for the case with ACK-Re-Invite.  
> 
> I have to figure out how to make async_ms_sleep() work in reply_route().
> 
> Thanks for all the comments and ideas
> 
> Best regards,
> 
> Luis
> 
> 
> 
> . On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:
>> 
>> 
>> mico...@gmail.com appears similar to someone who previously sent you email, 
>> but may not be that person. Learn why this could be a risk
>> Feedback
>> Hello,
>> 
>> then the overtaking is in between reading from the socket and getting to 
>> parsing the call-id value -- the cpu is lost by first reader after 
>> recvfrom() and the second process get enough cpu time to go ahead further. I 
>> haven't encountered this case, but as I said previously, it is very 
>> unlikely, but still possible. I added the route_locks_size because in the 
>> past I had cases when processing of some messages took longer executing 
>> config (e.g., due to authentication, accounting, ..) and I needed to be sure 
>> they are processed in the order they enter config execution.
>> 
>> Then the option is to see if a single process with stateless sending out 
>> (using forward()) gives the capacity, if you don't do any other complex 
>> processing. Or if you do more complex processing, use a dispatcher process 
>> with forwarding to local host or in a similar manner try to use 
>> mqueue+rtimer for dispatching using shared memory queues.
>> 
>> Of course, it is open source and there is also the C coding way, to add a 
>> synchronizing mechanism to protect against parallel execution of the code 
>> from recvfrom() till call-id lock is acquired.
>> 
>> Cheers,
>> Daniel
>> 
>> On 09.04.20 17:37, Luis Rojas G. wrote:
>>> Hello,
>>> 
>>> Well, it did not work at all. Exactly same behavior, with random out of 
>>> order messages.
>>> 
>>> Best regards,
>>> 
>>> Luis
>>> 
>>> On 4/9/20 11:28 AM, Daniel-Constantin Mierla wrote:
 
 
 mico...@gmail.com appears similar to someone who previously sent you 
 email, but may not be that person. Learn why this could be a risk
 Feedback
 Hello,
 
 the sip messages belonging to the same dialog have the same value for 
 Call-Id header. The locking is done based on hashing the Call-Id, so it 
 doesn't need at all the dialog module for its purpose.
 
 Cheers,
 Daniel
 
 On 09.04.20 14:19, Luis Rojas G. wrote:
> Hello, Daniel,
> 
> I am not so sure. I first tried adding that parameter, but it did not 
> work at all.  Same behavior. Then I read the documentation more carefully 
> :
> 
> https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size
> route_locks_size
> 
> Set the number of mutex locks to be used for synchronizing the execution 
> of messages sharing the same Call-Id. In other words, enables Kamailio to 
> execute the config script sequentially for the requests and replies 
> received within the same dialog – a new message received within the same 
> dialog waits until the previous one is routed out. 
> 
> Locks to execute sequentially messages belonging to same dialog. How will 
> Kamailio be aware that messages belong to same dialog, without the dialog 
> module?. With just stateless proxy it has no idea about dialogs, it just 
> forwards messages. I guess that's why just adding that parameter did not 
> 

Re: [SR-Users] kamailio as SBC for Teams

[Aidar Kamalov]

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, that's
> where your reply should go. You're sending to 52.114.7.24:1024 instead?
>
> Also, looks like you're missing "r2=on" on the other RR, only one has it.
>
> Cheers,
>
> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov 
> wrote:
>
>> Hello,
>>
>> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to use
>> kamailio for teams.
>> But I faced that MS not responding ACK to my 200OK. Somethin is wrong,
>> but I don't know what. I call from teams to kamailio.
>> Can you help me please
>>
>> This is initial INVITE from Teams:
>> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
>> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
>> SIP/2.0
>> FROM: Aidar Kamalov> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>> TO: 
>> CSEQ: 1 INVITE
>> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
>> MAX-FORWARDS: 70
>> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
>> RECORD-ROUTE: > ;transport=tls;lr>
>> CONTACT: > ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
>> CONTENT-LENGTH: 2426
>> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
>> CONTENT-TYPE: application/sdp
>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>>
>> v=0
>> o=- 0 0 IN IP4 52.114.252.146
>> s=session
>> c=IN IP4 52.114.252.146
>> b=CT:5
>> t=0 0
>> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
>> a=rtcp:52925
>> a=ice-ufrag:rKBm
>> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
>> a=rtcp-mux
>> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
>> 31.13.144.55 rport 57780
>> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
>> 31.13.144.55 rport 57781
>> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
>> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
>> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
>> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
>> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
>> 100.78.247.179 rport 39182
>> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
>> 100.78.247.179 rport 39183
>> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>> 100.78.247.179 rport 41775
>> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
>> 100.78.247.179 rport 41775
>> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
>> 31.13.144.55 rport 9761
>> a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
>> 31.13.144.55 rport 9761
>> a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
>> 31.13.144.55 rport 9761
>> a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
>> 31.13.144.55 rport 9761
>> a=x-candidate-info:4 network-type=WWAN
>> a=x-candidate-info:1 network-type=WWAN
>> a=x-candidate-info:2 network-type=WWAN
>> a=x-candidate-info:3 network-type=WWAN
>> a=x-candidate-info:5 network-type=WWAN
>> a=x-candidate-info:6 network-type=WWAN
>> a=x-candidate-info:7 network-type=WWAN
>> a=crypto:1 AES_CM_128_HMAC_SHA1_32
>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
>> a=crypto:2 AES_CM_128_HMAC_SHA1_80
>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
>> a=crypto:3 AES_CM_128_HMAC_SHA1_80
>> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
>> a=rtpmap:104 SILK/16000
>> a=fmtp:104 useinbandfec=1; usedtx=0
>> a=rtpmap:9 G722/8000
>> a=rtpmap:111 SIREN/16000
>> a=fmtp:111 bitrate=16000
>> a=rtpmap:18 G729/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:103 SILK/8000
>> a=fmtp:103 useinbandfec=1; usedtx=0
>> a=rtpmap:97 RED/8000
>> a=rtpmap:13 CN/8000
>> a=rtpmap:118 CN/16000
>> a=rtpmap:119 CN/24000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=ptime:20
>> a=maxptime:200
>>
>>
>>
>> and my 200OK to MS is:
>>
>> 2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024
>> SIP/2.0 200 OK
>> Record-Route:
>> 
>> Record-Route:
>> 
>> Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c
>> Record-Route:
>> 
>> Record-Route:
>> 
>> Record-Route:
>> 
>> Record-Route:
>> 
>> Record-Route: > ;transport=tls;lr>
>> To: > :5061;user=phone>;tag=3795432917-393759697
>> From: > ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>> Call-ID: 3d5ad3cdd01457be94d127fa20478cf1
>> CSeq: 1 INVITE
>> Allow:
>> PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
>> Content-Type: application/sdp
>> Accept: application/sdp
>> Content-Length: 282
>> User-Agent: MY_DOMAIN
>> Contact:
>> 
>>
>> v=0
>> o=ETPI-MSX1 0 0 IN IP4 KAMAILIO_IP
>> s=sip call
>> c=IN IP4 KAMAILIO_IP
>> t=0 0
>> m=audio 

Re: [SR-Users] Callee BYE routing issue

[Sergiu Pojoga]

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?
>
>
>
> Topology:
>
>
>
> UA1  <-> NAT device 1 <-> Proxy1 <-> Registrar/B2BUA <-> Proxy1 <-> NAT
> device 1 <-> UA2
>
>
>
> All UA to UA calls flow through B2BUA.
>
>
>
> All IP’s are public except for UA1 and UA2.
>
>
>
> -Both endpoints can call each other.
>
> -If the caller hangs up first, BYE is routed properly.
>
> -If the callee hangs up first, BYE causes proxy to send 478.
>
>
>
> On calls where BYE results in 478:
>
> if(!isdsturiset()) {
>
> ………..not executed
>
> handle_ruri_alias()
>
> }
>
> return;
>
>
>
> Example issue call: UA2 to UA1, UA1 hang-up.
>
>
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} ***
> cfgtrace:dbg_cfg_trace(): request_route=[DLGURI]
> c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=16 n=if
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} ***
> cfgtrace:dbg_cfg_trace(): request_route=[DLGURI]
> c=[/usr/local/etc/kamailio/kamailio.cfg] l=532 a=24 n=isdsturiset
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} ***
> cfgtrace:dbg_cfg_trace(): request_route=[DLGURI]
> c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=2 n=return
>
> ………..
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [ut.h:245]:
> uri2dst2(): bad_uri: [sip::;transport=]
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [t_fwd.c:1732]:
> t_forward_nonack(): failure to add branches
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} ***
> cfgtrace:dbg_cfg_trace(): request_route=[RELAY]
> c=[/usr/local/etc/kamailio/kamailio.cfg] l=275 a=24 n=sl_reply_error
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} sl [sl_funcs.c:401]:
> sl_reply_error(): stateless error reply used: Unresolvable destination
> (478/SL)
>
> Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE
> 24dc84a4592515245177483c2a657042@B2BUA_IP:5160} ***
> cfgtrace:dbg_cfg_trace(): request_route=[RELAY]
> c=[/usr/local/etc/kamailio/kamailio.cfg] l=277 a=2 n=exit
>
>
>
> 2020/04/10 00:31:28.625060 NAT_Device_IP:57808 -> Proxy_IP:5060
>
> BYE sip:398@B2BUA_IP:5160 SIP/2.0
>
> Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---43b5f31829f20952
>
> Max-Forwards: 70
>
> Route: 
>
> Contact: 
>
> To: "Dan Test" ;tag=as78671fd9
>
> From:  :52884;rinstance=705e0af5f4be485c;alias=NAT_Device_IP:~57808~1>;tag=64f4b712
>
> Call-ID: 24dc84a4592515245177483c2a657042@B2BUA_IP:5160
>
> CSeq: 2 BYE
>
> User-Agent: 
>
> Content-Length: 0
>
>
>
> #
>
>
>
> For comparison, here is a BYE from another test call: *UA1 to UA2, UA1
> hang-up.*
>
>
>
> This BYE was routed correctly.
>
>
>
> 2020/04/10 00:44:02.688608 NAT_Device_IP:57808 -> Proxy_IP:5060
>
> BYE sip:398@B2BUA_IP:5160 SIP/2.0
>
> Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---ce36df02e8a80a48
>
> Max-Forwards: 70
>
> Route: 
>
> Contact: 
>
> To: ;tag=as5874901f
>
> From: ;tag=9078f232
>
> Call-ID: 103104NGU1NjkxNGZkYmM4MzA3Y2FkMzY1OGNkZTZmMTMyZDU
>
> CSeq: 3 BYE
>
> User-Agent: 
>
> Authorization: Digest username= 
>
> Content-Length: 0
>
>
>
> -dan
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users