<div dir="ltr"><div>Good day Vinayak.</div><div><br></div><div>Firstly you'd better take into account that a sequence for processing REFER is much different from how the INVITE method is being processed.</div><div>So it's known that so called hand-shake consists of the following messages exchange: INVITE - 100 - 180/183 (optionally) - 200OK/202 Accepted - ACK</div><div>There is no complexity here and the way how it works is clear.<br></div><div><br></div><div>Now getting to the REFER method.</div><div>The REFER method likely falls in the category of in-dialog requests.</div><div>And in the predominant majority of cases can only be used within the existing dialog (to implement an attended/unattended transfer).</div><div><br></div><div>The superficial view/sequence of messages will be as follows:</div><div>- firstly A side (who makes a transfer) sends REFER (to local proxy/B2B) and awaits the arrival of 202.<br></div><div>(and by doing this also subscribes for an event)<br></div><div>- secondly local proxy/B2B invites a third party into the call (the further behavior depends on if this is an attended/unattended transfer)</div><div>- (let's say it's unattended) then as soon as third party takes a call, local proxy/B2B notifies (with NOTIFY method) the A party about the happened event.</div><div>So: NOTIFY - 200OK<br></div><div>Which begets in its turn a normal call clearing from the A side (BYE - 200OK)</div><div>- while A side was processing the happened event, local proxy/B2B took charge of re-invitation of the B party (with newer signaling/media information).</div><div>- a call between B and C side is now established (through the proxy/B2B)<br></div><div><br></div><div>You might as well read this RFC document: <a href="https://tools.ietf.org/html/rfc3515">https://tools.ietf.org/html/rfc3515</a></div><div>which is dedicated to the REFER method in particular.</div><div><br></div><div>Personally I haven't ever faced such a scenario, which would require such a conversion of REFER to INVITE.</div><div>Is there a good reason for doing that?</div><div><br></div><div>It sounds entirely quite tricky, since a normal logic for processing REFER already entails usage of INVITE.</div><div>But not to convert REFER into INVITE, but to engage a third party into the call. Meanwhile REFER method keeps on doing its job.<br></div><div><br></div><div>Even if you still want to do that,</div><div> you need to write an OpenSIPS logic, which would be capable of handling the full sequence for the REFER method (your leg with FreeSWITCH).</div><div>Keep it proper all the way during the call.</div><div>And on the other hand would be capable of conversion and processing the usual INVITE sequence (the leg with A side).<br></div><div>Which doesn't look to me like a simple thing to do.</div><div><br></div><div>Best regards<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 9:13 AM Vinayak Makwana <<a href="mailto:vinayak.makwana@ecosmob.com">vinayak.makwana@ecosmob.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Everyone,<br> I would like to manage REFER packet with opensips script <br> In my case i want manage REFER packet like whenever i opensips proxy getting REFER packet from freeswitch at that time i need to convert this REFER packet into INVITE packet from opensips script and send to the endpoint.<br>Is their any possibilities where I can manage this thing in opensips 3.1.x ?<br>Please suggest me.<div><br><div>My scenario like this:<br><div><br></div><div>A opensips B(Freswitch)</div><div> | -----INVITE -------> | -------INVITE------> | </div><div> | <-----200OK ------- | <-------200OK------ | <br></div><div> | <-----<span id="gmail-m_5757837463122478124gmail-docs-internal-guid-d3012b6f-7fff-7b34-5195-4686b4524475"><span style="font-size:11pt;font-family:"Times New Roman";color:rgb(0,0,0);background-color:rgb(255,255,0);font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">INVITE</span></span> ------- | <-------<font face="Times New Roman" color="#000000"><span style="font-size:14.6667px;white-space:pre-wrap;background-color:rgb(255,255,0)">REFER</span></font>---- |<br></div></div></div></div>
<br>
<div><font style="background-color:white" size="2" face="Arial" color="#808080"><b>Disclaimer</b></font></div><div><div><span style="background-color:white;color:rgb(128,128,128);font-family:Arial;font-size:small">In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded.</span></div></div><div><span style="background-color:white;color:rgb(128,128,128);font-family:Arial;font-size:small"><br></span></div><div><font style="background-color:white" size="2" face="Arial" color="#808080"><b>Confidentiality</b></font></div><div><font style="background-color:white" size="2" face="Arial" color="#808080">This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error.</font></div><div><font style="background-color:white" size="2" face="Arial" color="#808080"><br></font></div><div><span style="background-color:white;color:rgb(128,128,128);font-family:Arial;font-size:small"><b>Caution for viruses, malware etc.</b></span></div><div><font style="background-color:white" size="2" face="Arial" color="#808080">This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. </font></div>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Best regards,<br></font></div><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Donat Zenichev<br><br></font></div></div></div></div></div></div></div></div>