[Spce-user] No rewrite on T.38 INVITE
tdelsol at qfast.nl
Mon Aug 17 06:07:22 EDT 2015
That INVITE is really weird indeed. I will have a check and see why they
are sending that.
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 188.8.131.52:5060;ngcpct=7369703a3132372e302e302e313a353038303b707278726f7574653d31
>> The forwarded ACK of the SPCE is then send with a Contact
>> <sip:ngcp-lb at 184.108.40.206: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
> 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 220.127.116.11:5060;ngcpct=7369703a3132372e302e302e313a35303830
> 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:
> sip:ngcp-lb at 18.104.22.168:5060;ngcpct=7369703a3132372e302e302e313a35303830
> Hope this helps,
More information about the Spce-user