On Tue, Jan 3, 2023 at 1:58 PM Alex Balashov <abalashov@evaristesys.com> wrote:

Path support in upstream PJSIP is broken, from what I'm given to understand. This is a regression from a capability that was (finally) added to chan_sip in Asterisk 12.

Digium/Sangoma have clearly stated that they have no interest to fix:

https://issues.asterisk.org/jira/browse/ASTERISK-28211

As stated in the comments on that JIRA issue, "There is no timeline." I'm not sure what the logic is. I think it's something like, "Nobody uses proxies" ?? Not sure.

Our generally accepted "fix" for this is to hack the Path hop into the Contact header of the registrant before relaying the REGISTER upstream, so that registrations appear to Asterisk to come "from" Kamailio. This requires careful management and stateful reversion of the Contact value (i.e. in the RURI of incoming requests), making it a brittle and suboptimal solution. But when "there is no timeline", what can you do?

========

modparam("htable", "htable", "contacts=>size=18;autoexpire=300;")

request_route {
...

if(method == "REGISTER") {
...
route(CONTACT_SPOOF_ENCODE);
t_on_reply("REGISTER_REPLY_FROM_PBX");
}

else if(src == PBX) {
# Request destined for registrant, e.g. INVITE.

route(CONTACT_SPOOF_DECODE);
}
}

onreply_route[REGISTER_REPLY_FROM_PBX] {
if(!method == "REGISTER")
return;

# If we are channeling a 200 OK for a register, it is very important to
# restore the exact Contact binding registered by the UA, together with
# all of its parameters, so that the UA comes to believe the binding
# has been properly established.

if($rs == 200)
route(CONTACT_SPOOF_DECODE);
}

# This routine gets around the lack of Path support in upstream registrars by
# encoding the original Contact domain as a supplementary parameter and attaching
# it to the Contact binding. This can then be recovered on inbound requests.

route[CONTACT_SPOOF_ENCODE] {
$var(hash_key) = $(ct{s.sha256});
$sht(contacts=>$var(hash_key)) = $ct;
remove_hf("Contact");
append_hf("Contact: <sip:gateway@$Ri:$Rp;cthash=$var(hash_key)>\r\n");
}

# Use `cthash` parameter to retrieve original contact from `htable` if present,
# and replace. We do this in a contextually sensitive way, extracting `cthash`
# from the Contact header in a reply and from the RURI if it is a request.

route[CONTACT_SPOOF_DECODE] {
$var(ct) = $null;

if(t_is_request_route())
$var(ct) = $ru;
else if(t_is_reply_route())
$var(ct) = $(ct{nameaddr.uri}); # Unbracket the URI field.

if(strempty($(var(ct){param.value,cthash}))) {
if(t_is_request_route())
sl_send_reply("500", "Internal server error - missing ct");

xlog("L_INFO", "[R-CONTACT-SPOOF-DECODE:$ci] !> Unable to extract 'cthash' URI parameter\n");
exit;
}

$var(ct_key) = $(var(ct){param.value,cthash});

# Likewise error out if we cannot translate to the real contact, since there's
# no point in sending an adulterated contact to the UA.

if($sht(contacts=>$var(ct_key)) eq $null) {
if(t_is_request_route())
sl_send_reply("500", "Internal server error - cannot map ct");

xlog("L_INFO", "[R-CONTACT-SPOOF-DECODE:$ci] !> cthash key does not map to a contact!\n");
exit;
}

if(t_is_request_route())
$ru = $(sht(contacts=>$var(ct_key)){nameaddr.uri});
else {
remove_hf("Contact");
append_hf("Contact: $sht(contacts=>$var(ct_key))\r\n");
}
}

-- Alex

> On Jan 3, 2023, at 1:17 PM, nutxase <nutxase@proton.me> wrote:
>
> Using chan_pjsip
>
>
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, January 3rd, 2023 at 5:36 PM, Alex Balashov <abalashov@evaristesys.com> wrote:
>
>
>> Are you using chan_pjsip or chan_sip in Asterisk?
>>
>>> On Jan 3, 2023, at 12:26 PM, nutxase nutxase@proton.me wrote:
>>>
>>> Hi All
>>>
>>> I have setup kamailio using dispatcher to proxy registrations from the UAC to asterisk
>>> but when asterisk sends an incoming call it does not seem to keep the path header and therefore kamailio sends 404
>>> is there anyway around this?
>>>
>>> Thanks
>>>
>>> Sent with Proton Mail secure email.
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>> Edit mailing list options or unsubscribe:
>>
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-leave@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe: