[OpenSIPS-Users] remove_hf doesn't seem to work in route[b2b_reply]
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Nov 18 10:59:05 CET 2015
Louis,
Please open a feature request on the opensips GITHUB tracker and
probably it will be an easy one to do directly in the C code.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.11.2015 22:35, Louis Rochon wrote:
>
> 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/20151118/416c333e/attachment-0001.htm>
More information about the Users
mailing list