[OpenSIPS-Users] Transfer issue

Anca Vamanu anca at opensips.org
Mon Nov 9 15:17:03 CET 2009


Hi Jeff,


Jeff Kronlage wrote:
> Anca,
>
> The key pieces of my config file are:
>
> Loadmodule "tm.so"
> loadmodule "b2b_entities.so"
> loadmodule "b2b_logic.so"
>
> modparam("tm", "pass_provisional_replies", 1)
> modparam("b2b_entities","server_address","sip:opensips at myproxyabc.com")
> modparam("b2b_logic", "script_scenario", "/usr/local/etc/opensips/refer_script.xml")
> modparam("b2b_entities", "script_req_route", "b2b_request")
> modparam("b2b_entities", "script_reply_route", "b2b_reply")
>
> ...and down in route[1], just prior to where I would normally call t_relay():
>
> if (is_method("REFER")) {
> 	b2b_init_request("refer");
> 	exit;
> }
>
>   
No, no, no, you should no  call b2b_init_request for REFER but for the 
initial INVITE - since the B2BUA must but itself in the middle of the 
call from the beginning.


> The contents of /usr/local/etc/opensips/refer_script.xml:
>
> <?xml version="1.0"?>
> <scenario id="refer" name="Handle refer at server" param="0" type="script">
>   <init>
>     <bridge>
>       <server>
>         <id>server1</id>
>       </server>
>       <client>
>         <id>client1</id>
>         <type>message</type>
>         <destination>
>           <value type="initial">server1</value>
>         </destination>
>       </client>
>     </bridge>
>   </init>
>
>   <rules>
>      <request>
>        <refer>
>          <rule id="1">
>            <action>
>              <send_reply>
>                <code>202</code>
>                <reason>Accepted</reason>
>              </send_reply>
>              <end_dialog_leg/>
>              <bridge>
>                <client>
>                  <peer/>
>                </client>
>                <client>
>                  <id>client2</id>
>                  <destination>
>                    <value type="header">Refer-To</value>
>                  </destination>
>                </client>
>              </bridge>
>            </action>
>          </rule>
>        </refer>
>     </request>
>   </rules>
> </scenario>
>
> So I believe I've done everything you've suggested?  The only thing that was a little strange is that when I compiled from the svn, I had to edit /parser/parse_fline.h.  I had found items such as INVITE_LEN in there, and my compiler complained that REFER_LEN, as well as several other variables, were undefined.  I modified this section of parse_fline.h to the following:
>
> #define INVITE  "INVITE"
> #define CANCEL  "CANCEL"
> #define ACK             "ACK"
> #define BYE             "BYE"
> #define INFO    "INFO"
> #define PRACK   "PRACK"
> #define REFER   "REFER"
> #define SUBSCRIBE       "SUBSCRIBE"
> #define NOTIFY  "NOTIFY"
> #define MESSAGE "MESSAGE"
>
> #define INVITE_LEN 6
> #define CANCEL_LEN 6
> #define ACK_LEN 3
> #define BYE_LEN 3
> #define INFO_LEN 4
> #define PRACK_LEN 5
> #define REFER_LEN 5
> #define SUBSCRIBE_LEN 9
> #define NOTIFY_LEN 6
> #define MESSAGE_LEN 7
>
>   
I forgot to commit the parse_fline.h file on friday. I have commited it 
today. You can delete yours and update from svn.

Regards,
Anca
> Please advise,
>
> Jeff
>
> -----Original Message-----
> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Anca Vamanu
> Sent: Monday, November 09, 2009 2:34 AM
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Transfer issue
>
> Hi Jeff,
>
>
> It seems that the b2b module just does simple forward of REFER request 
> in your setup.
> Have you loaded the refer scenario? You can find it here: 
> http://www.opensips.org/Resources/B2buaTutorial#toc15. You have to put 
> in in a file and then set the 'script_scenario' parameter to the path of 
> the file:
>
> modparam("b2b_logic", "script_scenario", "path_to_scenario_refer.xml")
>
> The you have to call the b2b_init_request function with the "refer" 
> parameter:
> b2b_init_request("refer");
>
> Regards,
> Anca
>
>
> Jeff Kronlage wrote:
>   
>> Anca,
>>
>> Thanks again for your work on this.  I've gotten the b2b modules working and I'm attempting to use the REFER scenario, but I'm having some confusion regarding how a REFER with a B2BUA should be handled.
>>
>> My test environment looks like this:
>>
>> UA1 (softphone) ---INVITE--> [Opensips] ---PSTN_GATEWAY(UA2)--> POTS Phone
>> ..... (Session progress/OK/etc) ....
>> UA1 (softphone) ---ACK-->    [Opensips] ---> PSTN_GATEWAY(UA2)
>>
>> At this point, the first call is setup.
>>
>> UA1 (softphone) ---REFER UA2 to UA3-->  [Opensips] **b2b module called**
>> B2B             ---REFER B2B to UA3-->  PSTN_GATEWAY (UA2)
>> B2B             <--404 NOT FOUND--  PSTN_GATEWAY (UA2)
>> B2B             ---404 NOT FOUND->  UA1 (softphone) 
>>
>> Obviously this fails.  Note this same problem occurs on two completely separate gateways with different hardware. My questions are:
>>
>> 1) Shouldn't the b2b scenario send an INVITE off to UA3, wait for the OK/ACK, then simply REFER UA2 to UA3?  It seems to me that a B2B -> UA3 refer (which is what I appear to be getting) is out-of-dialog, and many gateways can't start a dialog with a REFER anyway.
>> 2) If not, any ideas on what I'm doing wrong?
>>
>> The pertinent parts of my sip dump are below, beginning with the first REFER, are below:
>>
>>         REFER sip:18002441111 at 208.94.157.10:5060;transport=udp SIP/2.0
>>         Via: SIP/2.0/UDP 70.57.173.114:63390;branch=z9hG4bK-d8754z-501a700165366947-1---d8754z-;rport
>>         Max-Forwards: 70
>>         Route: <sip:64.111.16.50;lr;ftag=a837e85e;did=847.0253b4b4>
>>         Contact: <sip:7194760273 at 70.57.173.114:63390>
>>         To: <sip:18002441111 at myproxyabc:5060>;tag=b9d5ed0-13c4-4af6e7b5-46585e8b-24ef0427
>>         From: "3CXPhone"<sip:7194760273 at myproxyabc.com:5060>;tag=a837e85e
>>         Call-ID: NDY4YWZhMzRjMDQzZmM2MTU0YTg5YzRlZmFlMzU5NDc.
>>         CSeq: 4 REFER
>>         Proxy-Authorization: <omitted>
>>         User-Agent: 3CXVoipPhone 4.0.9530.0
>>         Refer-To: <sip:18887779569 at prxdev.sip.data102.com:5060>
>>         Referred-By: "3CXPhone"<sip:7194760273 at prxdev.sip.data102.com:5060>
>>         Content-Length: 0
>>
>>         SIP/2.0 100 Trying
>>         Via: SIP/2.0/UDP 70.57.173.114:63390;branch=z9hG4bK-d8754z-501a700165366947-1---d8754z-;rport=63390
>>         To: <sip:18002441111 at myproxyabc.com:5060>;tag=b9d5ed0-13c4-4af6e7b5-46585e8b-24ef0427
>>         From: "3CXPhone"<sip:7194760273 at myproxyabc.com:5060>;tag=a837e85e
>>         Call-ID: NDY4YWZhMzRjMDQzZmM2MTU0YTg5YzRlZmFlMzU5NDc.
>>         CSeq: 4 REFER
>>         Server: OpenSIPS (1.6.1-notls (i386/linux))
>>         Content-Length: 0
>>
>>         REFER sip:18002441111 at 208.94.157.10:5060 SIP/2.0
>>         Via: SIP/2.0/UDP 64.111.16.50;branch=z9hG4bK7ea5.271c79b2.0
>>         To: sip:18002441111 at 208.94.157.10:5060
>>         From: <sip:7194760273 at myproxyabc.com:5060>;tag=b9952cfdcb0f3026fcffe5bf74779956-dca7
>>         CSeq: 2 REFER
>>         Call-ID: B2B.462.0.1257695261
>>         Content-Length: 0
>>         User-Agent: OpenSIPS (1.6.1-notls (i386/linux))
>>         Contact: <sip:opensips at myproxyabc.com:5060>
>>
>>         SIP/2.0 404 Not Found
>>         From: <sip:7194760273 at myproxyabc.com:5060>;tag=b9952cfdcb0f3026fcffe5bf74779956-dca7
>>         To: <sip:18002441111 at 208.94.157.10:5060>;tag=b9d5ed0-13c4-4af6e7c2-465890d5-3ca2cb05
>>         Call-ID: B2B.462.0.1257695261
>>         CSeq: 2 REFER
>>         Via: SIP/2.0/UDP 64.111.16.50;branch=z9hG4bK7ea5.271c79b2.0
>>         Content-Length: 0
>>
>> As always, help is much appreciated!
>>
>> Jeff K
>>
>> -----Original Message-----
>> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Anca Vamanu
>> Sent: Friday, November 06, 2009 9:49 AM
>> To: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] Transfer issue
>>
>> Hi,
>>
>> The REFER handing support has been added in B2BUA. Please update from 
>> svn to use this feature.
>> To enable it you have to load a simple scenario document that describes 
>> the behavior of the B2BUA when a REFER message is received and then call 
>> b2b_init_request("refer") for the initial Invite message.
>> I have also updated the documentation page and you can find there also 
>> the scenario document for this feature: 
>> http://www.opensips.org/Resources/B2buaTutorial#toc15.
>>
>> Regards,
>> Anca
>>
>>
>> Jeff Kronlage wrote:
>>   
>>     
>>> Hi Bogdan,
>>>
>>> Thanks for the fantastic news.
>>>
>>> I don't suppose you have any samples of how to interpret a REFER and perform a transfer?
>>>
>>> I've started pouring through the documentation for the B2BUA, but I'm still grinding through it :)
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
>>> Sent: Saturday, October 24, 2009 11:18 AM
>>> To: OpenSIPS users mailling list
>>> Subject: Re: [OpenSIPS-Users] Transfer issue
>>>
>>> Hi Iñaki,
>>>
>>> Actually this is why the B2BUA module was designed in opensips - in most 
>>> of the cases you need to control/change the dialog(s) but without any 
>>> media dependencies/penalties (like you have now in most of the IP-PBXs).
>>>
>>> So you actually can have a highly scalable signalling B2BUA - the 
>>> opensips module could be used to locally (on opensips) interpret the 
>>> REFER and do the call transfer, totally transparent to the other party.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Iñaki Baz Castillo wrote:
>>>   
>>>     
>>>       
>>>> El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>  Our setup has been initially
>>>>>  engineered for thousands of concurrent calls, and we're hoping to avoid
>>>>>  having a dozen Asterisk machines :)
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> What you are looking for is the dream all want: a scalable SIP B2BUA (no media 
>>>> handling), so a cluster of these B2BUA's would be located behind a proxy 
>>>> (which does load balancing and failover). And it would be greater if the B2BUA 
>>>> share information (about current dialogs and so) in some way (memcache? common 
>>>> database?...).
>>>>
>>>> You could implement it with SipServlets (see Sailin SIP application server or 
>>>> others), or FreeSwitch which allows calls without handling the media...
>>>> Of course, Asterisk is not the most suitable solution: it involves media 
>>>> handling ("canreinvite" is a hack), it has a very poor SIP stack... and 
>>>> basically it's designed to be a single PBX box.
>>>>
>>>>
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>   
>>>     
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>   
>>     
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   




More information about the Users mailing list