24 Sep
2018
24 Sep
'18
7:54 p.m.
Hi,
I’m wondering how to use subst_hf() properly.
I’m trying to debug a broken flow by manually rewriting the contact header from
Contact: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
to
Contact: <sip:2018092417381900003@81.x.x.x>
by using
$var(ctct) = "<sip:2018092417381900003@81.x.x.x>";
subst_hf("Contact", “/\<.+\>/$var(ctct)\r\n/", "a”);
but the result is
Contact: <sip:2018092417381900003@81.x.x.x>
sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
Testing the regex with an external tool appears to match all of the original header, so
I’m wondering why subst_hf doesn’t appear to rewrite the entire header.
Is there something I’m doing wrong?
TIA,
Ben
24 Sep
24 Sep
8:02 p.m.
The real question is, why are you rewriting a Contact header? :-) That
might be what you're really doing wrong ...
On Mon, Sep 24, 2018 at 05:54:04PM +0100, Ben Hood wrote:
Hi,
I’m wondering how to use subst_hf() properly.
I’m trying to debug a broken flow by manually rewriting the contact header from
Contact: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
to
Contact: <sip:2018092417381900003@81.x.x.x>
by using
$var(ctct) = "<sip:2018092417381900003@81.x.x.x>";
subst_hf("Contact", “/\<.+\>/$var(ctct)\r\n/", "a”);
but the result is
Contact: <sip:2018092417381900003@81.x.x.x>
sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
Testing the regex with an external tool appears to match all of the original header, so
I’m wondering why subst_hf doesn’t appear to rewrite the entire header.
Is there something I’m doing wrong?
TIA,
Ben
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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/
8:27 p.m.
:-)
The real reason is because I am not getting an ACK back from a 200 OK and I suspected that
the remote peer doesn’t like the contact header I’m sending back:
2018/09/24 16:38:19.089883 81.187.30.116:5060 -> 10.10.10.14:5080
INVITE sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@provider:5060 SIP/2.0
Via: SIP/2.0/UDP 81.187.30.116;branch=z9hG4bK2018092417381900003-1;rport
CSeq: 1 INVITE
Max-Forwards: 68
User-Agent: FireBrick/1.49.016
Call-ID: 2018092417381900003@2700-0344-0103-359
From: "07858 592563" <sip:07858592563@provider>;tag=2018092417381900003
To: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@provider:5060>
Contact: <sip:2018092417381900003@81.x.x <sip:2018092417381900003@81.x.x>.x>
Content-Type: application/sdp
Content-Length: 188
The 200 that gets no ACK looks like this:
2018/09/24 16:38:20.774332 10.10.10.14:5080 -> 81.x.x.x:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
81.x.x.x.x;received=81.x.x.x;branch=z9hG4bK2018092417381900003-1;rport=5060
Record-Route: <sip:10.10.10.14:5080;lr;ftag=2018092417381900003>
From: "07858 xxxxxx" <sip:07858xxxxxx@provider>;tag=2018092417381900003
To: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@provider:5060>;tag=22v0rKN4eeN7Q
Call-ID: 2018092417381900003@2700-0344-0103-359
CSeq: 1 INVITE
Contact: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
<sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>>
User-Agent: FreeSWITCH-mod_sofia/1.6.13+git~20161129T154639Z~e755b430da~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 224
This is after invoking fix_nated_contact() on the reply.
So I thought I’d try to break the problem down and send back the exact same contact header
in the 200 as I received in the original INVITE.
And to do that, I thought the easiest way to just hack this in temporarily was to with
subst_hf().
I thought if I can craft the contact header manually and see if that makes a difference.
On 24 Sep 2018, at 18:02, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
The real question is, why are you rewriting a Contact header? :-) That
might be what you're really doing wrong ...
On Mon, Sep 24, 2018 at 05:54:04PM +0100, Ben Hood wrote:
Hi,
I’m wondering how to use subst_hf() properly.
I’m trying to debug a broken flow by manually rewriting the contact header from
Contact: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
to
Contact: <sip:2018092417381900003@81.x.x.x>
by using
$var(ctct) = "<sip:2018092417381900003@81.x.x.x>";
subst_hf("Contact", “/\<.+\>/$var(ctct)\r\n/", "a”);
but the result is
Contact: <sip:2018092417381900003@81.x.x.x>
sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
Testing the regex with an external tool appears to match all of the original header, so
I’m wondering why subst_hf doesn’t appear to rewrite the entire header.
Is there something I’m doing wrong?
TIA,
Ben
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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 (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
9:25 p.m.
On Mon, Sep 24, 2018 at 06:27:51PM +0100, Ben Hood wrote:
Contact: <sip:2018092417381900003@81.x.x
<sip:2018092417381900003@81.x.x>.x>
Is this literally your Contact header? If so, it is definitely not
grammatically valid, and you are entirely right to assume that the
end-to-end ACK, along with any other in-dialog messages, will not be
routed from the caller correctly.
--
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/
25 Sep
25 Sep
12:46 a.m.
The literal contact header (after subst_hf mangling) became
Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
<sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
Which is completely bogus.
I was trying (as a temporary hack) to mangle this to become
Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
Which would have matched the contact header from the INVITE and then I would have seen
whether this affects the subsequent ACK for the 200 OK.
But my usage of subst_hf() turned this (syntactically correct yet uninterpretable) header
Contact: <sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
into
Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp
<sip:b73c6f29-0101-4802-afcd-efb63f1e6d8f@10.10.10.12:5090;transport=udp>
The code for the mangling is this:
$var(ctct) = "<sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>";
subst_hf("Contact", “/\<.+\>/$var(ctct)\r\n/", "a”);
Which is why I originally asked about how to use subst_hf just to debug the missing ACK.
On 24 Sep 2018, at 19:25, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
On Mon, Sep 24, 2018 at 06:27:51PM +0100, Ben Hood wrote:
Contact: <sip:2018092417381900003@81.x.x
<sip:2018092417381900003@81.x.x>.x>
Is this literally your Contact header? If so, it is definitely not
grammatically valid, and you are entirely right to assume that the
end-to-end ACK, along with any other in-dialog messages, will not be
routed from the caller correctly.
--
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 (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1:04 a.m.
On Mon, Sep 24, 2018 at 10:46:44PM +0100, Ben Hood wrote:
I was trying (as a temporary hack) to mangle this to
become
Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
But that's not grammatically valid...
--
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/
1:24 a.m.
On 24 Sep 2018, at 23:04, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
On Mon, Sep 24, 2018 at 10:46:44PM +0100, Ben Hood wrote:
You are absolutely correct, but I don’t think that is what I wrote (might be a typo from
me?). I was trying to produce:
Contact: <sip:2018092423082500003@81.x.x.x>
Which I have now achieved by adding
msg_apply_changes();
after the invocation of subst_hf().
Seems that the SIP buffer needs to be explicitly finalised before transport.
However, my theory about patching the Contact header to make the remote system happy is
wrong - the 200 OK is still not ACK’ed. So I need to look into the NAT’ing a bit more to
see what might be going on - but this is a different question to how to use subst_hf().
Many thanks for helping me out with this, very much appreciated.
I was trying (as a temporary hack) to mangle this
to become
Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
But that's not grammatically valid… 
27 Sep
27 Sep
4:50 p.m.
Hi,
first of all you definitely do not want to put the contact received in the
INVITE in the 200 OK, since you will, in the best case generate a loop of
the UAC sending the ACK to itself.
About having to call msg_apply_changes this comes probably by the fact that
you've already manipulated the header with fix_nated_contact(). Due to
kamailio's internals you cannot change the headers twice in a row without
invoking msg_apply_changes().
For your main problem with the ACK, I'd rather look at the Record-Route. I
see in the 200 OK that Record-Route has a private IP. Unless the caller is
on the same network or on a network that can communicate with your server,
you need to have there a public address (or a double Record-Route if your
server is running on two interfaces).
Have a look at "advertise" parameter of listen directive and to
http://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.p.enable_doub…
.
Best regards,
Federico
On Tue, Sep 25, 2018 at 12:24 AM Ben Hood <ben(a)relops.com> wrote:
On 24 Sep 2018, at 23:04, Alex Balashov
<abalashov(a)evaristesys.com>
wrote:
On Mon, Sep 24, 2018 at 10:46:44PM +0100, Ben Hood wrote:
> I was trying (as a temporary hack) to mangle this to become
>
> Contact: <sip:2018092417381900003@81.x.x.x
<sip:2018092417381900003@81.x.x.x>>
But that's not grammatically valid…
You are absolutely correct, but I don’t think that is what I wrote (might
be a typo from me?). I was trying to produce:
Contact: <sip:2018092423082500003@81.x.x.x>
Which I have now achieved by adding
msg_apply_changes();
after the invocation of subst_hf().
Seems that the SIP buffer needs to be explicitly finalised before
transport.
However, my theory about patching the Contact header to make the remote
system happy is wrong - the 200 OK is still not ACK’ed. So I need to look
into the NAT’ing a bit more to see what might be going on - but this is a
different question to how to use subst_hf().
Many thanks for helping me out with this, very much appreciated.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2254
days inactive
2257
days old
7 comments
3 participants
participants (3)
-
Alex Balashov -
Ben Hood -
Federico Cabiddu