[Spce-user] No rewrite on T.38 INVITE
tdelsol at qfast.nl
Thu Aug 20 10:15:22 EDT 2015
The reason is that the interconnect with our telco is tripping over our
contact-header of ngcplb@<ip> only with T.38, because of the re-invite.
They hide behind the fact that they have a spec for the interconnect
that only wants phonenumber@<ip>or<dns> in the contact-header.
On 20-08-15 16:05, Daniel Grotti wrote:
> any reason for that ?
> The callee should reply 488, not the server.
> Anyway, I remember some old threasd about that:
> Maybe this could help.
> Daniel Grotti
> VoIP Engineer
> Sipwise GmbH
> Europaring F15 | 2345 Brunn am Gebirge, Austria | www.sipwise.com
> On 08/20/2015 03:41 PM, Tristan Delsol wrote:
>> Back again on this :)
>> One more thing. Would it be possible to disable T.38 support somehow. So
>> that if the RE-INVITE comes in that we send back a 488?
>> Or maybe I can set it up for certain subscriber numbers?
>> On 17-08-15 17:01, Tristan Delsol wrote:
>>> Thanks for the info. I will experiment with that to see if it works.
>>> Then I will check if we would really want that or not.
>>> On 17-08-15 16:58, Andrew Pogrebennyk wrote:
>>>> On 08/17/2015 03:39 PM, Tristan Delsol wrote:
>>>>> 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”.
>>>>> 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?
>>>> Unfortunately this is not something you can easily achieve, but if you
>>>> have some understanding of kamailio config scripts you can try to modify
>>>> and disable the Contact masking completely, e.g. comment out all calls
>>>> of ROUTE_MASK_CONTACT and ROUTE_UNMASK_CONTACT as a starting point.
>>>> Then each side will receive the internal IP of b2b as Contact:
>>>> sip:127.0.0.1:5080, which exposes your topology a bit to outside but
>>>> still doesn't break the protocol. But we are not sending the number part
>>>> which might be a problem for them (they didn't say that the number part
>>>> is optional). Sorry I can't help you out more at this time.
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
> Spce-user mailing list
> Spce-user at lists.sipwise.com
More information about the Spce-user