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
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
:-)
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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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.
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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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...
On 24 Sep 2018, at 23:04, Alex Balashov abalashov@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.
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_doubl... .
Best regards,
Federico
On Tue, Sep 25, 2018 at 12:24 AM Ben Hood ben@relops.com wrote:
On 24 Sep 2018, at 23:04, Alex Balashov abalashov@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Ben Hood -
Federico Cabiddu