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

[Tristan Delsol]

Hi Andrew,

I checked this with the telco.
They state that they don't support that format for the contact header. 
They have it in the specs for the interconnect that the contact header 
can only contain the following:
sip:+«ISN»@«ip-address/URL»:«port» with optional user=”phone”, so for 
example sip:+31703434343 at domain.net:5060;user=”phone”.

Where
ISN: International Subscriber Number
port: UDP portnumber;
URL: Uniform Resource Locator: domain name;

Is it possible I can adjust the contact header for this kind of request 
to keep the format as needed?

Thanks in advance.

Tristan


On 17-08-15 12:07, Tristan Delsol wrote:
> 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
>>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user