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:bog...@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@192.168.131.203"<mailto:sip:$tU@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@lists.opensips.org<mailto:Users@lists.opensips.org>

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


--
Scanned by Total Defense Email Cloud Security http://cloud.totaldefense.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to