Hi, The sips: scheme is effectively dead, since the RFC requires that a sips: next-hop guarantee end-to-end security, which it cannot. It has been effectively replaced by use of ;transport=TLS. On Fri, Feb 22, 2019 at 02:58:05PM +1300, David Cunningham wrote: someone [sl_funcs.c:387]: which doesn't -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

No, it’s not “actually” dead in that sense. — Sent from mobile, with due apologies for brevity and errors. On Feb 21, 2019, at 10:01 PM, David Cunningham <dcunningham(a)voisonics.com> wrote: Hi Alex, Is it actually dead, as in unsupported by the RFC or Kamailio? If so would that explain why Kamailio gives that error and doesn't appear to process it? We certainly don't have end-to-end security as Kamailio is acting as a proxy between the device and Asterisk. Thanks for your advice! On Fri, 22 Feb 2019 at 15:08, Alex Balashov <abalashov(a)evaristesys.com> wrote: -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b

;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b

;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b

;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b

Hello, if you have kamailio 5.2, you should enable ignore of sips in rr: - https://www.kamailio.org/docs/modules/stable/modules/rr.html#rr.p.ignore_si… If you have an older version, just before use of record_route inside kamailio.cfg, do: if (uri=~"^sips:") { $ru = "sip:" + $(ru{s.substr,5,0}); } The presence of sips in r-uri of invite forces rr to set record-route with sips, but this results in some UAs just clone the uri scheme, not really understanding its purpose, anyhow, as already mentioned here, sips is a mess over all, so disabling it is safer. That's why I started to add options to kamailio to just ignore it. Cheers, Daniel On 24.02.19 23:31, David Cunningham wrote: Hi Daniel, Certainly, here is the sequence including INVITE and 200 OK. I note that the Contact on the 200 OK doesn't mention TLS, but the Record-Route header does. Thank you. Session Initiation Protocol (INVITE) Request-Line: INVITE sips:105@es8.example.com:5061 SIP/2.0 Message Header Via: SIP/2.0/TLS 50.78.xx.xx:5061;branch=z9hG4bK1836763299 Route: <sip:70.42.yy.yy:5061;transport=tls;lr> From: ES8 Test 102 <sips:111111@es8.example.com To: <sips:105@es8.example.com:5061> Call-ID: 222222(a)50.78.xx.xx CSeq: 94679 INVITE Contact: <sips:111111@50.78.xx.xx:5061;transport=tls> <sips:111111@50.78.xx.xx:5061;transport=tls> Supported: 100rel Proxy-Authorization: Digest username="111111", realm=" es8.example.com", nonce="XG71VFxu9CjpZnZTIQhhf5V1KmKWmQes", uri=" sip:105@192.168.3.1;user=phone", response="60059b561416f1a184d556d5cf116014", algorithm=MD5 Max-Forwards: 70 User-Agent: ewb2bua/15.3.0 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE Content-Type: application/sdp Content-Length: 387 Message Body Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/TLS 50.78.xx.xx:5061;rport=43290;branch=z9hG4bK1836763299 Record-Route: <sips:70.42.yy.yy;r2=on;lr=on> Record-Route: <sips:70.42.yy.yy:5061;transport=tls;r2=on;lr=on> From: ES8 Test 102 <sips:111111@es8.example.com To: <sips:105@es8.example.com:5061>;tag=as7a72b209 Call-ID: 222222(a)50.78.xx.xx CSeq: 94679 INVITE Server: ES8 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sips:105@70.42.yy.yy:5070> <sips:105@70.42.yy.yy:5070> Content-Type: application/sdp Content-Length: 337 Message Body Session Initiation Protocol (ACK) Request-Line: ACK sips:105@70.42.xx.xx:5070 SIP/2.0 Message Header Via: SIP/2.0/TLS 50.78.yy.yy:5061;branch=z9hG4bK741961203 Route: <sips:70.42.xx.xx:5061;transport=tls;r2=on;lr=on> Route: <sips:70.42.xx.xx;r2=on;lr=on> From: ES8 Test 102 <sips:111111@es8.example.com To: <sips:105@es8.example.com:5061>;tag=as7a72b209 Call-ID: 222222(a)50.78.yy.yy CSeq: 94679 ACK Contact: <sips:111111@50.78.yy.yy:5061;transport=tls> <sips:111111@50.78.yy.yy:5061;transport=tls> Max-Forwards: 70 User-Agent: ewb2bua/15.3.0 Content-Length: 0 On Fri, 22 Feb 2019 at 20:16, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote: > Hello, > > do you have the INVITE and the 200ok corresponding to this ACK? I need to > see the R-URI of INVITE as well as the contact in 200ok in order to analyze > why sips appears in ACK. > > SIPS requirements are sort of a mess, probably the best would be to let > it for config to decide when to allow forwarding or not in case of sips URI. > > Cheers, > Daniel > On 22.02.19 02:58, David Cunningham wrote: > > Hello all, > > We're having an issue with Kamailio not processing an ACK and hope > someone can help. A PCAP shows that Kamailio is receiving the ACK, and we > believe these log messages are directly related to it: > > Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [ut.h:279]: > uri2dst2(): ERROR: uri2dst: bad transport for sips uri: 1 > Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [t_fwd.c:1777]: > t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches > Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: sl > [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: > Unresolvable destination (478/SL) > > The ACK is as follows. It's from telephone 111111 which is using TLS, > which Kamailio listens for on port 5061. > Does anyone know which URI has the bad transport as per the error above? > Might it be the From URI "sips:111111@es8.example.com" because it > doesn't specify port 5061? > Thank you in advance. > > Session Initiation Protocol (ACK) > Request-Line: ACK sips:105@70.42.xx.xx:5070 SIP/2.0 > Message Header > Via: SIP/2.0/TLS 50.78.yy.yy:5061;branch=z9hG4bK741961203 > Route: <sips:70.42.xx.xx:5061;transport=tls;r2=on;lr=on> > Route: <sips:70.42.xx.xx;r2=on;lr=on> > From: ES8 Test 102 <sips:111111@es8.example.com >> To: <sips:105@es8.example.com:5061>;tag=as7a72b209 > Call-ID: 222222(a)50.78.yy.yy > CSeq: 94679 ACK > Contact: <sips:111111@50.78.yy.yy:5061;transport=tls> > <sips:111111@50.78.yy.yy:5061;transport=tls> > Max-Forwards: 70 > User-Agent: ewb2bua/15.3.0 > Content-Length: 0 > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ > USA: +1 213 221 1092 > New Zealand: +64 (0)28 2558 3782 > > _______________________________________________ > Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com > > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 _______________________________________________ Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com