[Spce-user] No rewrite on T.38 INVITE

[Andrew Pogrebennyk]

On 08/16/2015 03:36 PM, Tristan Delsol wrote:
> I see where things are going bad.
> The MP112 sends an ACK in response to the 200 OK and in the ACK the to
> address is
> sip:ngcp-lb at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a353038303b707278726f7574653d31
> SIP/2.0.
> The forwarded ACK of the SPCE is then send with a Contact
> <sip:ngcp-lb at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830>.
>
> Then the RE-INVITE has a destination of ngcp-lb which is not a
> subscriber ofcourse. 

You don't have to worry about the destination of the re-INVITE. The
From/To-tags, Routes and Call-ID is also that matters for re-INVITE. It
is sent within the established dialog, no suscriber lookup and no
rewrite rules needed. The caller sends the ACK with the Contact of NGCP,
right, then kamailio lb decodes the ngcpct string and forwards it
through proxy to the sems B2B, which does topology hiding for the other
leg..

I think the problem is on the callee side. The callee (Alcatel-Lucent)
sends INVITE
sip:ngcp-lb;tgrp=9752;trunk-context=ipic.imscore.net at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830
SIP/2.0
If you look at the BYE sent by the Alcatel-Lucent, you'll see that it
could not be routed due to the same reason.
This is not the format of R-URI we support and it does not match the
NGCP Contact that was advertised to the callee.
In order to be RFC-compliant, the INVITE (and BYE) should have looked
like this:
INVITE
sip:ngcp-lb at 87.239.101.193:5060;ngcpct=7369703a3132372e302e302e313a35303830

Hope this helps,
Andrew