[SR-Users] t_relay dying ?

[Jean Cérien]

Many thanks, I've managed to handle a call properly.

I really want to thank Daniel, and all that have helped on this subject.

Regards
J.

On Mon, Jan 8, 2018 at 11:42 PM, Joel Serrano <joel at gogii.net> wrote:

> Just a hint here, try setting $du and then t_relay...
>
> On Mon, Jan 8, 2018 at 11:55 Jean Cérien <cerien.jean at gmail.com> wrote:
>
>>
>> Hi
>>
>> While I'm trying to get the provider fix the SBC, I am implementing the
>> workaround.
>>
>> Almost done here, storing and retrieving the correct address is fine, but
>> when I set my $ru to the corrected value (asterisk IP), the t_relay still
>> sends the packet to the kamailio IP -
>>
>> $ru="sip:number at asteriskip:5060";
>> if (!t_relay()) {
>> ....
>>
>> Why would the t_relay forward to the kamailio IP and not the asterisk ?
>>
>> Rgds
>> J
>>
>>
>> On Mon, Jan 8, 2018 at 11:49 AM, Jean Cérien <cerien.jean at gmail.com>
>> wrote:
>>
>>> Many, many thanks !
>>>
>>> I've posted the full dialog unredacted here: https://pastebin.com/
>>> EE9iwgZf
>>>
>>> The OK from Kamailio back to VOIP provider has
>>> Record-Route: <sip:KAMAILIOIP;lr=on;ftag=SD2rbta01-8dd0e72b-0016-0379-
>>> 0000-0000;did=e0c.e0a1>
>>> Contact: <sip:NUMBER at ASTERISKIP:5060>
>>>
>>> So my understanding is that the ACK should be
>>> ACK sip:NUMBER at ASTERISKIP:5060 SIP/2.0
>>> ....
>>> and not
>>> ACK sip:NUMBER at KAMAILIOIP:5060 SIP/2.0
>>>
>>> Am I understanding correctly ?
>>>
>>> Rgds
>>> J
>>>
>>> On Mon, Jan 8, 2018 at 11:28 AM, Sebastian Damm <damm at sipgate.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien <cerien.jean at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Thanks for this answer. The voip provider is not really eager to alter
>>>>> its SBC as it considers that the contact field is not mandatory in the ACK.
>>>>> The RFC states (section 8.1.1.8)
>>>>>
>>>>
>>>> The problem is not that the ACK doesn't carry a Contact header. The
>>>> problem is that the ACK is constructed incorrectly. This is what the RfC
>>>> says to UAC behavior (section 12.1.2):
>>>>
>>>> The route set MUST be set to the list of URIs in the Record-Route
>>>> header field from the response, taken in reverse order and preserving all
>>>> URI parameters. If no Record-Route header field is present in the response,
>>>> the route set MUST be set to the empty set. This route set, even if empty,
>>>> overrides any pre-existing route set for future requests in this dialog. *The
>>>> remote target MUST be set to the URI from the Contact header field of the
>>>> response.*
>>>>
>>>> This is what the carrier's SBC gets wrong. It doesn't address your
>>>> Asterisk but instead addresses your Kamailio, although the Contact of your
>>>> 200 OK (hopefully) contains the Asterisk IP.
>>>>
>>>> Please verify that your 200 OK going to the carrier actually does carry
>>>> a Contact header with the Asterisk IP, but if it does, section 12.1.2 of
>>>> the SIP RfC could help when arguing with the carrier.
>>>>
>>>> Regards
>>>> Sebastian
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180109/2f5c5ddb/attachment.html>