[SR-Users] rr problem: sips instead of sip

[Olle E. Johansson]

On 07 Nov 2014, at 18:02, Jon Bonilla (Manwe) <manwe at aholab.ehu.es> wrote:

> Hi all
> 
> I'm experiencing a problem while using a mobile client on a NGCP mr3.5.1 (based
> on kamailio 4.1.6)
> 
> The problem is as follows:
> 
> A custom mobile client
> B blink for linux
> 
> The path of a call from B to A would be this one:
> 
> B --> Kamailio LB --> Kamailio proxy --> Sems --> Kamailio LB --> A
> 
> 
> Kamailio LB is a stateless proxy. Kamailio proxy is a stateful proxy and
> registrar and sems acts as B2BUA.
> 
> Kamailio LB listens tcp,udp and tls to the outside and speaks udp to the
> inside.
> Kamailio proxy and sems only listen udp localhost (ports 5062 ans 5080).
> 
> 
> My problem comes when the ACK from B to A (to the INVITE-200) doesn't leave the
> Kamailio LB to the proxy. The problem is that the kamailio proxy added itself
> as sips in the record-route header:
> 
> 
> U 2014/11/06 19:22:20.447717 127.0.0.1:5062 -> 127.0.0.1:5080
> 
> INVITE sips:test1 at 10.0.1.5:41956;rinstance=145658D8;transport=tcp SIP/2.0'
> 
> Record-Route:
> <sips:127.0.0.1:5062;lr=on;ftag=3Kwc9Aj.elAwdwWtB5yAXqdxR8rsyWi3;did=3e6.48e1;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=aHRBd2tQQ3VhVkZGamdrN2lhanhodEF3aw-->'
> 
> Record-Route:
> <sip:127.0.0.1;r2=on;lr=on;ftag=3Kwc9Aj.elAwdwWtB5yAXqdxR8rsyWi3;nat=yes;ngcplb=yes;socket=udp:XX.XX.XX.XX:5060>'
> 
> Record-Route:
> <sip:XX.XX.XX.XX;r2=on;lr=on;ftag=3Kwc9Aj.elAwdwWtB5yAXqdxR8rsyWi3;nat=yes;ngcplb=yes;socket=udp:XX.XX.XX.XX:5060>'
> 
> Via: SIP/2.0/UDP
> 127.0.0.1:5062;branch=z9hG4bKc36a.b42be7e4a4db27ac699a52fda7fb5fe0.0' Route:
> <sip:lb at 127.0.0.1;lr;received=sip:YY.YY.YY.YY:41956%3Btransport%3Dtls;socket=sip:XX.XX.XX.XX:5061>'
> 
> Via: SIP/2.0/UDP
> 127.0.0.1;branch=z9hG4bKc36a.a58b9955ce93726b17c0240a555011f2.0' 
> 
> Via: SIP/2.0/UDP
> 10.10.10.4:47879;received=ZZ.ZZ.ZZ.ZZ;rport=47879;branch=z9hG4bKPj6UmIovzyxDRCgcuz-VoXHEyJHRpA712x'
> 
> 
> When the ACK arrives to the LB from B, it can't relay it to the Kamailio proxy:
> 
> NOTICE: <script>: New request on lb - M=ACK
> R=sip:ngcp-lb at XX.XX.XX.XX;ngcpct=7369703a3132372e302e302e313a353038303b707278726f7574653d31
> 
> NOTICE: <script>: Relaying request,
> du='sips:127.0.0.1:5062;lr;ftag=3Kwc9Aj.elAwdwWtB5yAXqdxR8rsyWi3;did=3e6.48e1;mpd=ii;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=aHRBd2tQQ3VhVkZGamdrN2lhanhodEF3aw--',
> fs='udp:127.0.0.1:5060' - R=sip:127.0.0.1:5080;prxroute=1
> 
> WARNING:
> <core> [forward.c:264]: get_send_socket2(): WARNING: get_send_socket:
> protocol/port mismatch (forced udp:127.0.0.1:5060, to tls:127.0.0.1:5062)
> 
> 
> 
> 
> I think the problem might be in the way the client registers? This is the
> registration info where it uses sips in the contact:
> 
> contact: sips:test1 at 10.0.1.5:41956;rinstance=145658D8;transport=tcp
> 
> 
> If I try the same calling blink, which has the following contact in the
> registration it works without issues as the proxy doesn't insert sips in the
> Record-Route header:
> 
> contact: sip:91807432 at 10.10.10.4:57160;transport=tls
> 
> 
> 
> Any thoughts? 
> 

General thoughts - we had a lot of discussion about this at SIPit.

Using sips: in the contact is bad. We're trying to deprecate all use of SIPS: - in fact at IETF Cullen Jennings thought we already had.

Adding "transport=tls" in a contact with an IP address does not make much sense. That contact is as 
useful as a WebSocket contact - if the client doesn't have a certificate with a SubjAltName IPaddress we
can't use the contact.

The only way for TLS to work from UAs is using SIP outbound. Period. SIP Outbound is the future!
With SIP outbound the UA connects to the TLS ingress proxy and stays connected. In fact, it connects
to TWO proxys and keeps two connections always open. If one dies - which takes time to discover,
there's already another connection available. If the UA needs to set up a new TLS connection, which
takes a couple of roundtrips, there's another active connection available.

SIP outbound rocks.

Any thoughts?
/O