7 Nov
2014
7 Nov
'14
7:02 p.m.
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@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@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@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@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@10.10.10.4:57160;transport=tls
Any thoughts?
cheers,
Jon
7 Nov
7 Nov
7:21 p.m.
Hello,
I think the rule is that if the r-uri is enforcing sips, then record
route has to be sips.
In general, sips is a mess, because the rule is: it has to be
transmitted over something secure (which can be udp via vpn, or udp in a
private network, etc.).
You can probably fix it in the config. After loose_route(), the next hop
is $du or $ru -- $du has priority if it is set, so you can try something
like:
if($du!=$null) {
if($du=~"^sips:") {
$du = "sip:" + $(du{s.subst,5,0});
}
}
Alternative, for the initial invite, if it is sips in r-uri, then back
it in a variable, store some dummy sip uri, do record_route() and put
back the URI.
As an update in the code, it may be useful to add a mod param to control
if sips should be ignored or not.
Cheers,
Daniel
On 07/11/14 18:02, Jon Bonilla (Manwe) 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@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@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@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@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@10.10.10.4:57160;transport=tls
Any thoughts?
cheers,
Jon
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
8:17 p.m.
On 07 Nov 2014, at 18:02, Jon Bonilla (Manwe) <manwe(a)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@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@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@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@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@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
3672
days inactive
3672
days old
2 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Jon Bonilla (Manwe) -
Olle E. Johansson