[OpenSIPS-Users] remove_hf doesn't seem to work in route[b2b_reply]

[Louis Rochon]

Bogdan,

Thank you for the detailed reply. Your test with remove_hf()+append_hf() confirms my observations.

And yes, my goal is to preserve the username part in B2B Contact, while retaining the top hiding function by substituting the host part - which it does already.

Any idea how to accomplish this?

Louis


From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
Sent: Wednesday, October 28, 2015 12:09 PM
To: OpenSIPS users mailling list; Louis Rochon
Subject: Re: [OpenSIPS-Users] remove_hf doesn't seem to work in route[b2b_reply]

Hi Louis,

The b2b_reply route is invoked for int incoming reply. This reply is internally consumed and another one is generated on the other side of the B2B (basically there are two back 2 back transactions).

The new reply (on A side) is built based on information from the incoming reply (on B side) - considering that the original INVITE went from A to B.

So, any change you do on incoming rely will be discards because a new reply is to be built on the other side. Headers (as a whole) may propagate via "custom_headers" parameters. Otherwise, whatever append_hf() you do in b2b_reply will be lost (not translated to the other side).

Even more, the Contact has a special treatment as it is completely rebuilt by the B2B - old Contact hdr is discarded and a new one (pointing to B2B) is added in the outbound reply. So your changes over the incoming contact do conflict with the changed the B2B module does over the contact.

In my test, having "contact" in the "custom_headers" and doing remove_hf()+append_hf() on a contact on b2b_reply, results in two Contact headers :
    - the one removed, added and carried via custom header (from the incoming reply)
    - the one built and added internally by the B2B, pointing to it self

So, remove_hf() actually works, but you end up with that conflict in having you and the B2B changing both the Contact hdr.

As I understand, your goal is to preserve the username part in B2B right ?

Best regards,


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer

http://www.opensips-solutions.com
On 15.10.2015 21:40, Louis Rochon wrote:
remove_hf doesn't seem to work in route[b2b_reply]....Running OpenSIPS 1.11.5 on CentOS 6.

This problem started when I discovered that b2b_init_requests removes the user part of the URI in the Contact: field.

To correct that, did a bit of scripting to correct the outgoing invite:

First, handle contacts manually:
modparam("b2b_logic", "custom_headers", "Priority;Calluid;Geolocation;Geolocation-Routing;Contact")

Second, check out the incoming INVITE, and modify the host part to be the OpenSIPs server itself (192.168.130.105):
$var(ContactURI)=$ct.fields(uri);
$var(ContactURIHost)=$(var(ContactURI){uri.host});
$var(ContactURIUser)=$(var(ContactURI){uri.user});
$var(regedit)="/"+$(var(ContactURIHost))+"/192.168.130.105/g";
$var(URIwSub)=$(var(ContactURI){re.subst,$var(regedit)});

Third, in local_route, remove the incoming contact and replace with my own:
remove_hf("Contact");
append_hf("Contact: $var(URIwSub)\r\n");

Fourth, send off the invite downstream (to 192.168.131.203):
b2b_init_request("FailOver", "sip:$tU at 192.168.131.203"<mailto:sip:$tU at 192.168.131.203>);

All this works! Great, but the reply route, not:
route[b2b_reply] {
          xlog("b2b_reply Route ($ci)\n");
###Debug Code
xlog(">>>>>B2BRR:Protocol of received message: $pr\n");
xlog(">>>>>B2BRR:Body of request/reply: $rb\n");
xlog(">>>>>B2BRR:Return Code: $rc\n");
xlog(">>>>>B2BRR:Request Method: $rm\n");
xlog(">>>>>B2BRR:Reply Reason: $rr\n");
xlog(">>>>>B2BRR:Reply Status: $rs\n");
xlog(">>>>>B2BRR:Transport protocol of original R-URI: $oP\n");
xlog(">>>>>B2BRR:Transport protocol of R-URI: $rP\n");
xlog(">>>>>B2BRR:Transport protocol of destination uri: $dP\n");
xlog(">>>>>B2BRR:Destination set: $ds\n");
xlog(">>>>>B2BRR:Destination uri: $du\n");
xlog(">>>>>B2BRR:URI of From header: $fu\n");
xlog(">>>>>B2BRR:Domain in request's original R-URI: $od\n");
xlog(">>>>>B2BRR:Request's original URI: $ou\n");
xlog(">>>>>B2BRR:Username in request's original URI: $oU\n");
xlog(">>>>>B2BRR:Domain in URI of 'To' header: $td\n");
xlog(">>>>>B2BRR:Complete Request URI: $ru\n");
xlog(">>>>>B2BRR:Username in Request URI: $rU\n");
xlog(">>>>>B2BRR:Username in URI of 'To' header: $tU\n");
xlog(">>>>>B2BRR:Surname in URI of 'From' header : $fU\n");
xlog(">>>>>B2BRR:Contact name:$ct.fields(name)\n");
xlog(">>>>>B2BRR:Contact uri:$ct.fields(uri)\n");
xlog(">>>>>B2BRR:Contact q param:$ct.fields(q)\n");
xlog(">>>>>B2BRR:Contact expires:$ct.fields(expires)\n");
xlog(">>>>>B2BRR:Contact methods:$ct.fields(methods)\n");
xlog(">>>>>B2BRR:Contact params:$ct.fields(params)\n");

$var(ContactURIRR)=$ct.fields(uri);
$var(ContactURIHostRR)=$(var(ContactURIRR){uri.host});
$var(regeditRR)="/"+$(var(ContactURIHostRR))+"/192.168.130.105/g";
$var(URIwSubRR)=$(var(ContactURIRR){re.subst,$var(regeditRR)});
if(remove_hf("Contact"))
{
xlog(">>>>>B2BRR:removed Contact\n");
} else {
xlog(">>>>>B2BRR:DID NOT removed Contact\n");
};
#
# xlog("Substituted Contact URI Variable Reply Route:$var(URIwSubRR)\n");
append_hf("Contact: $var(URIwSubRR)\r\n");
#replace_body_all("Contact", "BlaBla");
}

So in route[b2b_reply], do the same treatment as in the invite. The xlog says that it did remove the Contact, but it's still there, according to wireshark. The append_hf works fine, but the remove_hf never works. I end up with 2 Contact.

Any ideas?



Louis Rochon
Senior Systems Designer
Solacom Technologies
819 205 8100 ext. 274
http://www.solacom.com<http://www.solacom.com/>

IMPORTANT EMAIL / FAX INFORMATION
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender, at (613) 693-0641 and dispose of this email.  Thanks !

MISE EN GARDE CONCERNANT LA CONFIDENTIALITE DES RENSEIGNEMENTS CONTENUS DANS CE FAX/COURRIEL
La présente communication est confidentielle et transmise sous le sceau du secret professionnel et destiné au destinataire seulement.. Il est expressément interdit d'en dévoiler la teneur, de la copier, de la distribuer ou de prendre quelque mesure fondée sur l'information qui y est contenue. Si vous avez reçu cette communication par erreur, veillez S.V.P. la détruire et nous en aviser immédiatement par téléphone, au (613) 693-0641. Merci !





_______________________________________________

Users mailing list

Users at lists.opensips.org<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Scanned by Total Defense Email Cloud Security http://cloud.totaldefense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151117/6496c57f/attachment-0001.htm>