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

[Tristan Delsol]

Hi Andrew,

That INVITE is really weird indeed. I will have a check and see why they 
are sending that.

Cheers,
Tristan

On 17-08-15 09:50, Andrew Pogrebennyk wrote:
> 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
>