[OpenSIPS-Users] Transfer issue
Jeff Kronlage
jeff at data102.com
Mon Nov 9 15:29:29 CET 2009
Anca,
Thanks for the quick reply. I tried as you suggested, on a development box, and while it didn't work, it did look a lot more like what I was expecting to see.
However, I guess I am looking for more of a "tack on" solution for what I've already developed. The "right" answer may be to not support REFERs. Is there any way to modify the script scenario to -just- pick up from the REFER and still bridge in the first call leg? It's OK if the answer is 'no', I just need to know what my options are.
Thanks,
Jeff K
-----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 7:17 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Transfer issue
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
>
>
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list