Re: [OpenSIPS-Users] Transfer issue with Cisco unified call manager

2016-05-17 Thread Sasmita Panda 
Hi ,

I have encountered similar issue . B2BUA mode of opensips not able to
change the SDP . I have tried to do this with Opensips-1.11 . I think it
cant even change the SDP .

 As for my understanding , Opensips only work as a middle man
between two  User Agent . It only change the signaling part(like : Route ,
Via , From etc ) but not the SDP part .

 I think it cant be don't by this module automatically . If this is
possible to do then I will be helpful also .

*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Tue, May 17, 2016 at 2:40 PM, Chen-Che Huang  wrote:

> Dear all,
>
> For collaboration purpose and some reasons, we have set up a kind-of-weird
> architecture with Cisco unified call manager (abbreviated CUCM) as follows.
>
> client A
> client B <>OpenSIPS SIP proxy<>CUCM
> client C   |
>  RTP proxy
>
>
> The OpenSIPS SIP proxy here acts as clients to CUCM. For each client, the
> OpenSIPS SIP proxy creates a unique socket to CUCM. All the requests and
> responses between clients and CUCM pass through the OpenSIPS SIP proxy. All
> the RTP packets between clients are relayed by RTP proxy.
>
> Although this architecture is kind-of-weird, it works for client
> registration and call setup. However, in this architecture, we cannot
> support a particular call transfer case.
> Client A calls client B (OK)
> Client A transfers the call to client C (OK)
> Client A transfers the call to make client B talk to client C (Failed in
> terms of media relay).
>
> The SIP signalling flow is basically okay. The problem is that we cannot
> let
> client B and client C's RTP packets relayed by the RTP Proxy because the
> SIP
> messages in this case are two separate dialogs (the CUCM acts in B2BUA
> mode). I have do a preliminary study to address issue by using the B2BUA
> module of the OpenSIPS but the module seems not to have the ability to
> modify SDP.
>
> Has anyone encountered similar issues or had any suggestion on this issue?
> Many thanks for any comments.
>
> Yours sincerely,
> Chen-Che
>
>
>
>
>  where client A transfers the call to make client B and client C with each
> other. Because CUCM acts like in B2BUA mode,
>
>
>
> --
> View this message in context:
> http://opensips-open-sip-server.1449251.n2.nabble.com/Transfer-issue-with-Cisco-unified-call-manager-tp7602968.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Transfer issue with Cisco unified call manager

2016-05-17 Thread Chen-Che Huang 
Dear all,

For collaboration purpose and some reasons, we have set up a kind-of-weird
architecture with Cisco unified call manager (abbreviated CUCM) as follows. 

client A
client B <>OpenSIPS SIP proxy<>CUCM
client C   |
 RTP proxy
   

The OpenSIPS SIP proxy here acts as clients to CUCM. For each client, the
OpenSIPS SIP proxy creates a unique socket to CUCM. All the requests and
responses between clients and CUCM pass through the OpenSIPS SIP proxy. All
the RTP packets between clients are relayed by RTP proxy.

Although this architecture is kind-of-weird, it works for client
registration and call setup. However, in this architecture, we cannot
support a particular call transfer case.
Client A calls client B (OK)
Client A transfers the call to client C (OK)
Client A transfers the call to make client B talk to client C (Failed in
terms of media relay).

The SIP signalling flow is basically okay. The problem is that we cannot let
client B and client C's RTP packets relayed by the RTP Proxy because the SIP
messages in this case are two separate dialogs (the CUCM acts in B2BUA
mode). I have do a preliminary study to address issue by using the B2BUA
module of the OpenSIPS but the module seems not to have the ability to
modify SDP.

Has anyone encountered similar issues or had any suggestion on this issue?
Many thanks for any comments.

Yours sincerely,
Chen-Che




 where client A transfers the call to make client B and client C with each
other. Because CUCM acts like in B2BUA mode, 



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Transfer-issue-with-Cisco-unified-call-manager-tp7602968.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-11-17 Thread Bogdan-Andrei Iancu 
Hi Iñaki,

Iñaki Baz Castillo wrote:
 El Lunes, 16 de Noviembre de 2009, Bogdan-Andrei Iancu escribió:
   
 I agree that a b2bua is more complex than a proxy, but I guess the idea 
 is to identify all these buggy cases and fix them.
 

 A very important issue in most of the existing B2BUA's:

 Imagine the b2bua routes/generates the call to a proxy which does parallel 
 forking so b2bua receives two 183 with different To-tag and, of course, 
 different SDP (sess-id, sess-version...).

 The b2bua replaces the received To-tags in an *unique* new To-tag to be used 
 in the upstream leg.

 This is a bug since the UAC will receive two 183 with same To-tag but 
 different SDP so it must ignore the second SDP (a SDP cannot change during an 
 early-dialog).
   
are you sure about this behaviour ? is it stated by  RFC3261?
 I've issued this problem. The solution is easy:

 For each received 1XX response (different To-tags) the b2bua must create so 
 many different To-tags for the 1XX it sends to the UAC.

 If the b2bua doesn't replace the To-tag then the problem automatically 
 dissapears, but then it's not a b2bua :)
   
it does change :)

Regards,
Bogdan


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-11-16 Thread Bogdan-Andrei Iancu 
Hi Iñaki,

Iñaki Baz Castillo wrote:
 El Sábado, 24 de Octubre de 2009, Bogdan-Andrei Iancu escribió:
   
 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.
 

 Hi Bogdan, even if that sounds look let me be the bad boy ;)
   
OK, let;s play good-cops and bad-cops to get the best of it ;)
 - What about the implicit NOTIFY during the REFER transaction?
   
B2BU will take care of the entire transfer signalling (sending the 
NOTIFY with the state of the transfer)
 - What about if parallel forking occurs during REFER transaction?
   
from b2bua, there are 2 distinct calls : (1) one already established, 
between B2B and transferred party and (2) a new one from the b2b to the 
transferee party - The b2b will finally wait for a 200 OK, so there is 
no risk if the new call is doing any kind of forking (like no UA is 
affected by the forking done by a proxy)
 A more complex case:

 - A is speaking with P (PSTN provider).
 - A sends a REFER (Refer-To: B).
 - OpenSIPS handles the REFERa and generates an INVITE to B.
   - Which codecs does it use?
   
none :) - the re-INVITEs in b2bua are done with INVITEs without SDP, 
so that the SDPs are directly exchanged between end parties.
 - B sends 180 during 10 seconds.
 - Before B answers or declines the call, P sends a re-INVITE to A.
   - What does then happen? note that a re-INVITE shouldn't take place
 in middle of a REFER transaction (but P kwnos *nothing* about
 the REFER transaction since OpenSIPS b2bua handled it!).
   
This is good question - and mainly because of how should be done and not 
because you cannot do it.
Depends how you do the transfer scenario in B2BUA:
(1) once you received the REFER from A, the b2bua can hung up the P 
leg (unattended transfer)
(2) if P leg is still kept and B2B receives a re-INVITE from there, 
it should deny it...what is the proper SIP response ? hmmm:D
 Like this I can imagine hundreds of real cases in which, personally, I expect 
 b2bua module wouldn't behave correctly. 
   
I agree that a b2bua is more complex than a proxy, but I guess the idea 
is to identify all these buggy cases and fix them.

Thanks and Regards,
Bogdan


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-11-12 Thread Anca Vamanu 
Jeff Kronlage wrote:
 Anca,

 We've given in and started building a front-end/back-end opensips 
 configuration.  The 'front end' will be based on our original script and 
 perform the majority of the functions, the 'back end' being the B2BUA that 
 will be involved starting at the initial invite.

 Is there any possibility of getting a basic sample Opensips config to go 
 along with the XML config for the B2BUA scenario?

 Thanks,

 Jeff K

 -Original Message-
 From: users-boun...@lists.opensips.org 
 [mailto:users-boun...@lists.opensips.org] On Behalf Of Anca Vamanu
 Sent: Tuesday, November 10, 2009 1:43 AM
 To: OpenSIPS users mailling list
 Subject: Re: [OpenSIPS-Users] Transfer issue

 Hi Jeff,

 Jeff Kronlage wrote:
   
 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.

   
 
 I am sorry, but the answer is really no. The B2BUA must be in the middle 
 of the call from the beginning.

 Regards,
 Anca

   
 Thanks,

 Jeff K

 -Original Message-
 From: users-boun...@lists.opensips.org 
 [mailto:users-boun...@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:opens...@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
 idserver1/id
   /server
   client
 idclient1/id
 typemessage/type
 destination
   value type=initialserver1/value
 /destination
   /client
 /bridge
   /init

   rules
  request
refer
  rule id=1
action
  send_reply
code202/code
reasonAccepted/reason
  /send_reply
  end_dialog_leg/
  bridge
client
  peer/
/client
client
  idclient2/id
  destination
value type=headerRefer-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 INFOINFO
 #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-boun...@lists.opensips.org 
 [mailto:users-boun...@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

Re: [OpenSIPS-Users] Transfer issue

2009-11-11 Thread Jeff Kronlage 
Anca,

We've given in and started building a front-end/back-end opensips 
configuration.  The 'front end' will be based on our original script and 
perform the majority of the functions, the 'back end' being the B2BUA that will 
be involved starting at the initial invite.

Is there any possibility of getting a basic sample Opensips config to go along 
with the XML config for the B2BUA scenario?

Thanks,

Jeff K

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Anca Vamanu
Sent: Tuesday, November 10, 2009 1:43 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Transfer issue

Hi Jeff,

Jeff Kronlage wrote:
 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.

   
I am sorry, but the answer is really no. The B2BUA must be in the middle 
of the call from the beginning.

Regards,
Anca

 Thanks,

 Jeff K

 -Original Message-
 From: users-boun...@lists.opensips.org 
 [mailto:users-boun...@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:opens...@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
 idserver1/id
   /server
   client
 idclient1/id
 typemessage/type
 destination
   value type=initialserver1/value
 /destination
   /client
 /bridge
   /init

   rules
  request
refer
  rule id=1
action
  send_reply
code202/code
reasonAccepted/reason
  /send_reply
  end_dialog_leg/
  bridge
client
  peer/
/client
client
  idclient2/id
  destination
value type=headerRefer-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 INFOINFO
 #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-boun...@lists.opensips.org 
 [mailto:users-boun...@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

Re: [OpenSIPS-Users] Transfer issue

2009-11-10 Thread Anca Vamanu 
Hi Jeff,

Jeff Kronlage wrote:
 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.

   
I am sorry, but the answer is really no. The B2BUA must be in the middle 
of the call from the beginning.

Regards,
Anca

 Thanks,

 Jeff K

 -Original Message-
 From: users-boun...@lists.opensips.org 
 [mailto:users-boun...@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:opens...@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
 idserver1/id
   /server
   client
 idclient1/id
 typemessage/type
 destination
   value type=initialserver1/value
 /destination
   /client
 /bridge
   /init

   rules
  request
refer
  rule id=1
action
  send_reply
code202/code
reasonAccepted/reason
  /send_reply
  end_dialog_leg/
  bridge
client
  peer/
/client
client
  idclient2/id
  destination
value type=headerRefer-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 INFOINFO
 #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-boun...@lists.opensips.org 
 [mailto:users-boun...@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

Re: [OpenSIPS-Users] Transfer issue

2009-11-09 Thread Jeff Kronlage 
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:opens...@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;
}

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
idserver1/id
  /server
  client
idclient1/id
typemessage/type
destination
  value type=initialserver1/value
/destination
  /client
/bridge
  /init

  rules
 request
   refer
 rule id=1
   action
 send_reply
   code202/code
   reasonAccepted/reason
 /send_reply
 end_dialog_leg/
 bridge
   client
 peer/
   /client
   client
 idclient2/id
 destination
   value type=headerRefer-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 INFOINFO
#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

Please advise,

Jeff

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@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:18002441...@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:7194760...@70.57.173.114:63390
 To: 
 sip:18002441...@myproxyabc:5060;tag=b9d5ed0-13c4-4af6e7b5-46585e8b-24ef0427
 From: 3CXPhonesip:7194760...@myproxyabc.com:5060;tag=a837e85e
 Call-ID: NDY4YWZhMzRjMDQzZmM2MTU0YTg5YzRlZmFlMzU5NDc.
 CSeq: 4

Re: [OpenSIPS-Users] Transfer issue

2009-11-09 Thread Anca Vamanu 
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:opens...@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
 idserver1/id
   /server
   client
 idclient1/id
 typemessage/type
 destination
   value type=initialserver1/value
 /destination
   /client
 /bridge
   /init

   rules
  request
refer
  rule id=1
action
  send_reply
code202/code
reasonAccepted/reason
  /send_reply
  end_dialog_leg/
  bridge
client
  peer/
/client
client
  idclient2/id
  destination
value type=headerRefer-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 INFOINFO
 #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-boun...@lists.opensips.org 
 [mailto:users-boun...@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:18002441...@208.94.157.10:5060;transport=udp SIP/2.0
 Via: SIP/2.0/UDP 
 70.57.173.114

Re: [OpenSIPS-Users] Transfer issue

2009-11-09 Thread Jeff Kronlage 
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-boun...@lists.opensips.org 
[mailto:users-boun...@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:opens...@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
 idserver1/id
   /server
   client
 idclient1/id
 typemessage/type
 destination
   value type=initialserver1/value
 /destination
   /client
 /bridge
   /init

   rules
  request
refer
  rule id=1
action
  send_reply
code202/code
reasonAccepted/reason
  /send_reply
  end_dialog_leg/
  bridge
client
  peer/
/client
client
  idclient2/id
  destination
value type=headerRefer-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 INFOINFO
 #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-boun...@lists.opensips.org 
 [mailto:users-boun...@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

Re: [OpenSIPS-Users] Transfer issue

2009-11-08 Thread Jeff Kronlage 
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:18002441...@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:7194760...@70.57.173.114:63390
To: 
sip:18002441...@myproxyabc:5060;tag=b9d5ed0-13c4-4af6e7b5-46585e8b-24ef0427
From: 3CXPhonesip:7194760...@myproxyabc.com:5060;tag=a837e85e
Call-ID: NDY4YWZhMzRjMDQzZmM2MTU0YTg5YzRlZmFlMzU5NDc.
CSeq: 4 REFER
Proxy-Authorization: omitted
User-Agent: 3CXVoipPhone 4.0.9530.0
Refer-To: sip:18887779...@prxdev.sip.data102.com:5060
Referred-By: 3CXPhonesip:7194760...@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:18002441...@myproxyabc.com:5060;tag=b9d5ed0-13c4-4af6e7b5-46585e8b-24ef0427
From: 3CXPhonesip:7194760...@myproxyabc.com:5060;tag=a837e85e
Call-ID: NDY4YWZhMzRjMDQzZmM2MTU0YTg5YzRlZmFlMzU5NDc.
CSeq: 4 REFER
Server: OpenSIPS (1.6.1-notls (i386/linux))
Content-Length: 0

REFER sip:18002441...@208.94.157.10:5060 SIP/2.0
Via: SIP/2.0/UDP 64.111.16.50;branch=z9hG4bK7ea5.271c79b2.0
To: sip:18002441...@208.94.157.10:5060
From: 
sip:7194760...@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:opens...@myproxyabc.com:5060

SIP/2.0 404 Not Found
From: 
sip:7194760...@myproxyabc.com:5060;tag=b9952cfdcb0f3026fcffe5bf74779956-dca7
To: 
sip:18002441...@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-boun...@lists.opensips.org 
[mailto:users-boun...@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-boun...@lists.opensips.org 
 [mailto:users-boun...@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

Re: [OpenSIPS-Users] Transfer issue

2009-10-28 Thread Peter den Hartog 
Oke i feel so happy right now, i fixed it! it works! i can now create dials
over opensips, true asterisk, outside inside i can transfer, everything
works! damn i'm happy :D!
the answer was in my opensips.cfg and the routing back to asterisk, i've
created a routing script that just subscribe and trows the rest in to
asterisk.

i'm thinking of creating a big straightforward blogpost about this, how you
should do this, with what goes where and stuff like that.

I would like to thank everybody who replied on this issue, thanks alot.

On Tue, Oct 27, 2009 at 12:16 PM, Iñaki Baz Castillo i...@aliax.net wrote:

 El Martes, 27 de Octubre de 2009, Peter den Hartog escribió:
  I just checked a bit better and noticed this error while transfering:
 
  U 172.16.1.10:5060 - 172.16.1.14:5060
  NOTIFY sip:1...@172.16.0.24 sip%3a...@172.16.0.24 SIP/2.0.
  Via: SIP/2.0/UDP 172.16.1.10:5060;branch=z9hG4bK23a1000e;rport.
  Route: sip:172.16.1.14;lr=on.
  From: 0624469780 sip:0624469...@172.16.1.10sip%3a0624469...@172.16.1.10
 ;tag=as47c203e8.
  To: sip:0031851119...@172.16.1.14 sip%3a0031851119...@172.16.1.14
 ;tag=2AE312D6-A13BBC6D.
  Contact: sip:0624469...@172.16.1.10 sip%3a0624469...@172.16.1.10.
  Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
  CSeq: 103 NOTIFY.
  User-Agent: Asterisk PBX.
  Max-Forwards: 70.
  Event: refer;id=2.
  Subscription-state: terminated;reason=noresource.
  Content-Type: message/sipfrag;version=2.0.
  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
  Supported: replaces.
  Content-Length: 49.
  .
  SIP/2.0 481 Call leg/transaction does not exist.
 
 
  U 172.16.1.14:5060 - 172.16.0.24:5060
  NOTIFY sip:1...@172.16.0.24 sip%3a...@172.16.0.24 SIP/2.0.
  Via: SIP/2.0/UDP 172.16.1.14;branch=z9hG4bK1df2.c4df24a7.0.
  Via: SIP/2.0/UDP
  172.16.1.10:5060;received=172.16.1.10;branch=z9hG4bK23a1000e;rport=5060.
  From: 0624469780 sip:0624469...@172.16.1.10sip%3a0624469...@172.16.1.10
 ;tag=as47c203e8.
  To: sip:0031851119...@172.16.1.14 sip%3a0031851119...@172.16.1.14
 ;tag=2AE312D6-A13BBC6D.
  Contact: sip:0624469...@172.16.1.10 sip%3a0624469...@172.16.1.10.
  Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
  CSeq: 103 NOTIFY.
  User-Agent: Asterisk PBX.
  Max-Forwards: 69.
  Event: refer;id=2.
  Subscription-state: terminated;reason=noresource.
  Content-Type: message/sipfrag;version=2.0.
  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
  Supported: replaces.
  Content-Length: 49.
  .
  SIP/2.0 481 Call leg/transaction does not exist.
 
  That is the message that apears when pressing the transfer button.


 Are your client behind a router with SIP ALG?:
  http://www.voip-info.org/wiki/view/Routers+SIP+ALG


 --
 Iñaki Baz Castillo i...@aliax.net

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users




-- 
Groet // Kind regards,
Peter den Hartog

Sent from Leidschendam, ZH, Netherlands
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-28 Thread Iñaki Baz Castillo 
2009/10/28 Peter den Hartog peterdenhar...@gmail.com:
 Oke i feel so happy right now, i fixed it! it works! i can now create dials
 over opensips, true asterisk, outside inside i can transfer, everything
 works! damn i'm happy :D!
 the answer was in my opensips.cfg and the routing back to asterisk, i've
 created a routing script that just subscribe and trows the rest in to
 asterisk.

 i'm thinking of creating a big straightforward blogpost about this, how you
 should do this, with what goes where and stuff like that.

 I would like to thank everybody who replied on this issue, thanks alot.

Congratulations ;)

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-28 Thread Khan 
Please let me know when you setup the blogspot i'm very interested in seeing
how you did it, or if you could provide me your configuration that will be
really great.

Thanks in advance...

Khan

On Wed, Oct 28, 2009 at 7:34 AM, Iñaki Baz Castillo i...@aliax.net wrote:

 2009/10/28 Peter den Hartog peterdenhar...@gmail.com:
  Oke i feel so happy right now, i fixed it! it works! i can now create
 dials
  over opensips, true asterisk, outside inside i can transfer, everything
  works! damn i'm happy :D!
  the answer was in my opensips.cfg and the routing back to asterisk, i've
  created a routing script that just subscribe and trows the rest in to
  asterisk.
 
  i'm thinking of creating a big straightforward blogpost about this, how
 you
  should do this, with what goes where and stuff like that.
 
  I would like to thank everybody who replied on this issue, thanks alot.

 Congratulations ;)

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users




-- 
Khan


VoIP Rookie
Every beginning has an end regardless we believe it or not...
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-27 Thread Peter den Hartog 

I just checked a bit better and noticed this error while transfering:

U 172.16.1.10:5060 - 172.16.1.14:5060
NOTIFY sip:1...@172.16.0.24 SIP/2.0.
Via: SIP/2.0/UDP 172.16.1.10:5060;branch=z9hG4bK23a1000e;rport.
Route: sip:172.16.1.14;lr=on.
From: 0624469780 sip:0624469...@172.16.1.10;tag=as47c203e8.
To: sip:0031851119...@172.16.1.14;tag=2AE312D6-A13BBC6D.
Contact: sip:0624469...@172.16.1.10.
Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
CSeq: 103 NOTIFY.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Event: refer;id=2.
Subscription-state: terminated;reason=noresource.
Content-Type: message/sipfrag;version=2.0.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Length: 49.
.
SIP/2.0 481 Call leg/transaction does not exist.


U 172.16.1.14:5060 - 172.16.0.24:5060
NOTIFY sip:1...@172.16.0.24 SIP/2.0.
Via: SIP/2.0/UDP 172.16.1.14;branch=z9hG4bK1df2.c4df24a7.0.
Via: SIP/2.0/UDP
172.16.1.10:5060;received=172.16.1.10;branch=z9hG4bK23a1000e;rport=5060.
From: 0624469780 sip:0624469...@172.16.1.10;tag=as47c203e8.
To: sip:0031851119...@172.16.1.14;tag=2AE312D6-A13BBC6D.
Contact: sip:0624469...@172.16.1.10.
Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
CSeq: 103 NOTIFY.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Event: refer;id=2.
Subscription-state: terminated;reason=noresource.
Content-Type: message/sipfrag;version=2.0.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Length: 49.
.
SIP/2.0 481 Call leg/transaction does not exist.

That is the message that apears when pressing the transfer button.


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Well yes, it does work for the internal calls, but
 when a call comes in true asterisk to an opensips extention i CAN'T
  transfer it :-), i get transfer failed in my screen of my phone, and the
  call stays on the original called extention. This is only for announced
  transfers, unannounced works fine.
 
 Flavio post stated something about routing your REFER's back to asterisk,
  so it should work.. but i don't know how to route these calls back to
 the
  asterisk.
 
 Please, you *already* have the answer. When a phone is speaking with
 Asterisk 
 (through OpenSIPS) you must route REFER to Asterisk as *any* other
 in-dialog 
 request, this is, the *same* as when a phone is speaking with other phone 
 directly (through OpenSIPS).
 
 If the REFER fails this is because Asterisk is rejecting it !!!
 
 I already suggested you to do a SIP capture (using ngrep) to inspect which 
 error replies Asterisk when the REFER arrives to it. Please do it and
 paste it 
 here (I expect a 403 or 404, so it means a wrong configuration in you 
 Asterisk, no more).
 
 And please, forget anything about exotic routing of the REFER.
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3898287.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-27 Thread Iñaki Baz Castillo 
El Martes, 27 de Octubre de 2009, Peter den Hartog escribió:
 I just checked a bit better and noticed this error while transfering:
 
 U 172.16.1.10:5060 - 172.16.1.14:5060
 NOTIFY sip:1...@172.16.0.24 SIP/2.0.
 Via: SIP/2.0/UDP 172.16.1.10:5060;branch=z9hG4bK23a1000e;rport.
 Route: sip:172.16.1.14;lr=on.
 From: 0624469780 sip:0624469...@172.16.1.10;tag=as47c203e8.
 To: sip:0031851119...@172.16.1.14;tag=2AE312D6-A13BBC6D.
 Contact: sip:0624469...@172.16.1.10.
 Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
 CSeq: 103 NOTIFY.
 User-Agent: Asterisk PBX.
 Max-Forwards: 70.
 Event: refer;id=2.
 Subscription-state: terminated;reason=noresource.
 Content-Type: message/sipfrag;version=2.0.
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
 Supported: replaces.
 Content-Length: 49.
 .
 SIP/2.0 481 Call leg/transaction does not exist.
 
 
 U 172.16.1.14:5060 - 172.16.0.24:5060
 NOTIFY sip:1...@172.16.0.24 SIP/2.0.
 Via: SIP/2.0/UDP 172.16.1.14;branch=z9hG4bK1df2.c4df24a7.0.
 Via: SIP/2.0/UDP
 172.16.1.10:5060;received=172.16.1.10;branch=z9hG4bK23a1000e;rport=5060.
 From: 0624469780 sip:0624469...@172.16.1.10;tag=as47c203e8.
 To: sip:0031851119...@172.16.1.14;tag=2AE312D6-A13BBC6D.
 Contact: sip:0624469...@172.16.1.10.
 Call-ID: 05aedaab03eadeca3b42d0b84d880...@172.16.1.10.
 CSeq: 103 NOTIFY.
 User-Agent: Asterisk PBX.
 Max-Forwards: 69.
 Event: refer;id=2.
 Subscription-state: terminated;reason=noresource.
 Content-Type: message/sipfrag;version=2.0.
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
 Supported: replaces.
 Content-Length: 49.
 .
 SIP/2.0 481 Call leg/transaction does not exist.
 
 That is the message that apears when pressing the transfer button.


Are your client behind a router with SIP ALG?:
  http://www.voip-info.org/wiki/view/Routers+SIP+ALG


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Sábado, 24 de Octubre de 2009, Bogdan-Andrei Iancu escribió:
 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.

Hi Bogdan, even if that sounds look let me be the bad boy ;)

- What about the implicit NOTIFY during the REFER transaction?
- What about if parallel forking occurs during REFER transaction?

A more complex case:

- A is speaking with P (PSTN provider).
- A sends a REFER (Refer-To: B).
- OpenSIPS handles the REFERa and generates an INVITE to B.
  - Which codecs does it use?
- B sends 180 during 10 seconds.
- Before B answers or declines the call, P sends a re-INVITE to A.
  - What does then happen? note that a re-INVITE shouldn't take place
in middle of a REFER transaction (but P kwnos *nothing* about
the REFER transaction since OpenSIPS b2bua handled it!).

Like this I can imagine hundreds of real cases in which, personally, I expect 
b2bua module wouldn't behave correctly. 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Flavio (and others),

I've created the following setup:
Sip trunk - asterisk - opensips

I can now call in and outside, i can transfer calls internaly on opensips, i
can blind transfer every call.. but i can't transfer the announced calls
once again. I made in the script the following changes: 

route{

if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
}
if (is_method(REFER)) {
route(4);
}

And route(4) is the drouting script, so then it should go back to the
gateway (asterisk) that knows it should do a dial to 103 right?

Everything else seem to work fine, calling outside/inside to asterisk
extentions, to opensips extentions i can even transfer a call from a outside
caller from a asterisk extention to an opensips extention, but when i try to
transfer from the opensips extention to another opensips extention i get
transfer failed.

Any input on this issue? what should i check? is the script above wrong :)?

Best regards, and thanks for all the awesome input you guys are giving me.


Flavio Goncalves wrote:
 
 Hi Peter,
 
 You need to have support for REFER in all the SIP components, UACs 
 and Gateways. Your SIP provider seems to be refusing your REFERS with 
 the message 501 Not Implemented. The only way to workaround (as far 
 as I know) is to use a gateway before your SIP provider that 
 implements the REFER messages. You can do this using Asterisk. Handle 
 the REFERs in the same way you do with INVITEs, there is a parameter 
 called allowexternaldomains and it needs to be set to yes. The 
 security for REFERs is the same as the one used for INVITEs.
 
 Regards,
 
 Flavio E. Goncalves
 
 At 08:39 AM 10/23/2009, you wrote:
 
I moved my opensips in the network, it's now directly connected to my sip
trunk, i can call inside, i can call outside. I can transfer inside. But
when i try to tranfser an outside nummer i get to see this ngrep:

U 90.145.5.96:5060 - 90.145.5.83:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:90.145.5.83;lr=on,
sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 70.
Content-Length: 0.
.


U 90.145.5.83:5060 - 77.73.226.254:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 69.
Content-Length: 0.
.


U 77.73.226.254:5060 - 90.145.5.83:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.


U 90.145.5.83:5060 - 90.145.5.96:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.

It makes sense to me that i forgot something in my config, a refer module
or
something? any toughts/pushes in the right direction would be greatly
appreciated!

best regards.
--
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877950.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3891524.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 if (is_method(REFER)) {
 route(4);
 }
 
 And route(4) is the drouting script, so then it should go back to the
 gateway (asterisk) that knows it should do a dial to 103 right?

Not at all. REFER is an in-dialog request so leave it going through the 
loose_route secion, just it. It MUST work. 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Well yes, it does work for the internal calls, but
when a call comes in true asterisk to an opensips extention i CAN'T transfer
it :-), i get transfer failed in my screen of my phone, and the call stays
on the original called extention. This is only for announced transfers,
unannounced works fine. 

Flavio post stated something about routing your REFER's back to asterisk, so
it should work.. but i don't know how to route these calls back to the
asterisk.



Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 if (is_method(REFER)) {
 route(4);
 }
 
 And route(4) is the drouting script, so then it should go back to the
 gateway (asterisk) that knows it should do a dial to 103 right?
 
 Not at all. REFER is an in-dialog request so leave it going through the 
 loose_route secion, just it. It MUST work. 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3891742.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

BTW, when transfering anounched, i don't see a refer coming to asterisk, so
it stays in opensips..
If anybody wants i can add my script + a log file for this problem.


Peter den Hartog wrote:
 
 Well yes, it does work for the internal calls, but
 when a call comes in true asterisk to an opensips extention i CAN'T
 transfer it :-), i get transfer failed in my screen of my phone, and the
 call stays on the original called extention. This is only for announced
 transfers, unannounced works fine. 
 
 Flavio post stated something about routing your REFER's back to asterisk,
 so it should work.. but i don't know how to route these calls back to the
 asterisk.
 
 
 
 Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 if (is_method(REFER)) {
 route(4);
 }
 
 And route(4) is the drouting script, so then it should go back to the
 gateway (asterisk) that knows it should do a dial to 103 right?
 
 Not at all. REFER is an in-dialog request so leave it going through the 
 loose_route secion, just it. It MUST work. 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3891935.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Well yes, it does work for the internal calls, but
 when a call comes in true asterisk to an opensips extention i CAN'T
  transfer it :-), i get transfer failed in my screen of my phone, and the
  call stays on the original called extention. This is only for announced
  transfers, unannounced works fine.
 
 Flavio post stated something about routing your REFER's back to asterisk,
  so it should work.. but i don't know how to route these calls back to the
  asterisk.

Please, you *already* have the answer. When a phone is speaking with Asterisk 
(through OpenSIPS) you must route REFER to Asterisk as *any* other in-dialog 
request, this is, the *same* as when a phone is speaking with other phone 
directly (through OpenSIPS).

If the REFER fails this is because Asterisk is rejecting it !!!

I already suggested you to do a SIP capture (using ngrep) to inspect which 
error replies Asterisk when the REFER arrives to it. Please do it and paste it 
here (I expect a 403 or 404, so it means a wrong configuration in you 
Asterisk, no more).

And please, forget anything about exotic routing of the REFER.


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 BTW, when transfering anounched, i don't see a refer coming to asterisk, so
 it stays in opensips..

Please describe your escenario:

If is the following?

- phone_1 speaking to Asterisk through OpenSIPS.
- Asterisk speaking to phone_2 through OpenSIPS.


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Ok thank you for your clear post, here is the grep of the call i made, it's a
outside call to asterisk then a transfer to opensips. (anounched) that one
is working, but then i try a transfer from 105 to 103, this is from opensips
extention to opensips extention. this one fails.

http://dl.getdropbox.com/u/1382962/grep.txt

Best regards


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Well yes, it does work for the internal calls, but
 when a call comes in true asterisk to an opensips extention i CAN'T
  transfer it :-), i get transfer failed in my screen of my phone, and the
  call stays on the original called extention. This is only for announced
  transfers, unannounced works fine.
 
 Flavio post stated something about routing your REFER's back to asterisk,
  so it should work.. but i don't know how to route these calls back to
 the
  asterisk.
 
 Please, you *already* have the answer. When a phone is speaking with
 Asterisk 
 (through OpenSIPS) you must route REFER to Asterisk as *any* other
 in-dialog 
 request, this is, the *same* as when a phone is speaking with other phone 
 directly (through OpenSIPS).
 
 If the REFER fails this is because Asterisk is rejecting it !!!
 
 I already suggested you to do a SIP capture (using ngrep) to inspect which 
 error replies Asterisk when the REFER arrives to it. Please do it and
 paste it 
 here (I expect a 403 or 404, so it means a wrong configuration in you 
 Asterisk, no more).
 
 And please, forget anything about exotic routing of the REFER.
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3891992.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Well in that case, phone 1 + 2 are in opensips. and phone 1 has a call with a
mobile phone true asterisk.


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 BTW, when transfering anounched, i don't see a refer coming to asterisk,
 so
 it stays in opensips..
 
 Please describe your escenario:
 
 If is the following?
 
 - phone_1 speaking to Asterisk through OpenSIPS.
 - Asterisk speaking to phone_2 through OpenSIPS.
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892001.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Ok thank you for your clear post, here is the grep of the call i made, it's
  a outside call to asterisk then a transfer to opensips. (anounched) that
  one is working, but then i try a transfer from 105 to 103, this is from
  opensips extention to opensips extention. this one fails.
 
 http://dl.getdropbox.com/u/1382962/grep.txt

I see no REFER request in that trace.
Also what I see is a 484 Addres Incomplete from Asterisk

 Best regards
 
 Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Well yes, it does work for the internal calls, but
  when a call comes in true asterisk to an opensips extention i CAN'T
   transfer it :-), i get transfer failed in my screen of my phone, and
  the call stays on the original called extention. This is only for
  announced transfers, unannounced works fine.
 
  Flavio post stated something about routing your REFER's back to
  asterisk, so it should work.. but i don't know how to route these calls
  back to the
   asterisk.
 
  Please, you *already* have the answer. When a phone is speaking with
  Asterisk
  (through OpenSIPS) you must route REFER to Asterisk as *any* other
  in-dialog
  request, this is, the *same* as when a phone is speaking with other phone
  directly (through OpenSIPS).
 
  If the REFER fails this is because Asterisk is rejecting it !!!
 
  I already suggested you to do a SIP capture (using ngrep) to inspect
  which error replies Asterisk when the REFER arrives to it. Please do it
  and paste it
  here (I expect a 403 or 404, so it means a wrong configuration in you
  Asterisk, no more).
 
  And please, forget anything about exotic routing of the REFER.
 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Yes, i just noticed that error myself, that's something else didn't had that
before today :-), but that's the whole issue, i think it's not sending a new
refer, it just creates a new call on line 2, and when i try to press
transfer and hang up the call disappears and in my phone screen i see
transfer failed 

the situation is like this: 104 is on Asterisk, 105  103 are on opensips,
104 takes all the outside calls (for now i made it like this, so we are able
to transfer the calls announced) 

i call from my mobile, true the sip trunk  to 104. I transfer a call from
104 to 105, this works fine. Then i transfer the same call from 105 to 103,
these last 2 are both opensips extensions..  and that last part, doesn't
work. the ngrep of a call like this is what you can see in my last post


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Ok thank you for your clear post, here is the grep of the call i made,
 it's
  a outside call to asterisk then a transfer to opensips. (anounched) that
  one is working, but then i try a transfer from 105 to 103, this is from
  opensips extention to opensips extention. this one fails.
 
 http://dl.getdropbox.com/u/1382962/grep.txt
 
 I see no REFER request in that trace.
 Also what I see is a 484 Addres Incomplete from Asterisk
 
 Best regards
 
 Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Well yes, it does work for the internal calls, but
  when a call comes in true asterisk to an opensips extention i CAN'T
   transfer it :-), i get transfer failed in my screen of my phone, and
  the call stays on the original called extention. This is only for
  announced transfers, unannounced works fine.
 
  Flavio post stated something about routing your REFER's back to
  asterisk, so it should work.. but i don't know how to route these
 calls
  back to the
   asterisk.
 
  Please, you *already* have the answer. When a phone is speaking with
  Asterisk
  (through OpenSIPS) you must route REFER to Asterisk as *any* other
  in-dialog
  request, this is, the *same* as when a phone is speaking with other
 phone
  directly (through OpenSIPS).
 
  If the REFER fails this is because Asterisk is rejecting it !!!
 
  I already suggested you to do a SIP capture (using ngrep) to inspect
  which error replies Asterisk when the REFER arrives to it. Please do it
  and paste it
  here (I expect a 403 or 404, so it means a wrong configuration in you
  Asterisk, no more).
 
  And please, forget anything about exotic routing of the REFER.
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892228.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

I got rid of that error by putting allowguests=no in asterisk, then i don't
get the error.
i've put a number to a direct opensips extention with
_x,Dial,1,(SIP/1...@172.16.1.14) (.14 beeing my opensips server :))

I called in again, and it ringed @ 105, that works great. Then i do a
anounched transfer from 105 to 103, and again no succes. Again i added the
log:

http://dl.getdropbox.com/u/1382962/grep2.txt


Peter den Hartog wrote:
 
 Yes, i just noticed that error myself, that's something else didn't had
 that before today :-), but that's the whole issue, i think it's not
 sending a new refer, it just creates a new call on line 2, and when i try
 to press transfer and hang up the call disappears and in my phone screen i
 see transfer failed 
 
 the situation is like this: 104 is on Asterisk, 105  103 are on opensips,
 104 takes all the outside calls (for now i made it like this, so we are
 able to transfer the calls announced) 
 
 i call from my mobile, true the sip trunk  to 104. I transfer a call from
 104 to 105, this works fine. Then i transfer the same call from 105 to
 103, these last 2 are both opensips extensions..  and that last part,
 doesn't work. the ngrep of a call like this is what you can see in my last
 post
 
 
 Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Ok thank you for your clear post, here is the grep of the call i made,
 it's
  a outside call to asterisk then a transfer to opensips. (anounched)
 that
  one is working, but then i try a transfer from 105 to 103, this is from
  opensips extention to opensips extention. this one fails.
 
 http://dl.getdropbox.com/u/1382962/grep.txt
 
 I see no REFER request in that trace.
 Also what I see is a 484 Addres Incomplete from Asterisk
 
 Best regards
 
 Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Well yes, it does work for the internal calls, but
  when a call comes in true asterisk to an opensips extention i CAN'T
   transfer it :-), i get transfer failed in my screen of my phone, and
  the call stays on the original called extention. This is only for
  announced transfers, unannounced works fine.
 
  Flavio post stated something about routing your REFER's back to
  asterisk, so it should work.. but i don't know how to route these
 calls
  back to the
   asterisk.
 
  Please, you *already* have the answer. When a phone is speaking with
  Asterisk
  (through OpenSIPS) you must route REFER to Asterisk as *any* other
  in-dialog
  request, this is, the *same* as when a phone is speaking with other
 phone
  directly (through OpenSIPS).
 
  If the REFER fails this is because Asterisk is rejecting it !!!
 
  I already suggested you to do a SIP capture (using ngrep) to inspect
  which error replies Asterisk when the REFER arrives to it. Please do
 it
  and paste it
  here (I expect a 403 or 404, so it means a wrong configuration in you
  Asterisk, no more).
 
  And please, forget anything about exotic routing of the REFER.
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892280.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 I got rid of that error by putting allowguests=no in asterisk, then i don't
 get the error.
 i've put a number to a direct opensips extention with
 _x,Dial,1,(SIP/1...@172.16.1.14) (.14 beeing my opensips server :))
 
 I called in again, and it ringed @ 105, that works great. Then i do a
 anounched transfer from 105 to 103, and again no succes. Again i added the
 log:
 
 http://dl.getdropbox.com/u/1382962/grep2.txt

I'm sorry but I cannot help with this trace as it's incomplete. for example 
some responses are not shown:


U 172.16.0.24:5060 - 172.16.1.14:5060
INVITE sip:1...@172.16.1.14:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
To: sip:1...@172.16.1.14;user=phone.
CSeq: 1 INVITE.
Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
Contact: sip:1...@172.16.0.24.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, 
PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Supported: 100rel,replaces.
Allow-Events: talk,hold,conference.
Max-Forwards: 70.
Content-Type: application/sdp.
Content-Length: 247.
.
v=0.
o=- 1256566109 1256566109 IN IP4 172.16.0.24.
s=Polycom IP Phone.
c=IN IP4 172.16.0.24.
t=0 0.
a=sendrecv.
m=audio 2246 RTP/AVP 8 0 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.


U 172.16.0.24:5060 - 172.16.1.14:5060
ACK sip:1...@172.16.1.14:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
To: 
sip:1...@172.16.1.14;user=phone;tag=c97b4d1cb1f3d0da549e06a8d482ef63.ed84.
CSeq: 1 ACK.
Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
Contact: sip:1...@172.16.0.24.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, 
PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Max-Forwards: 70.
Content-Length: 0.



Where is the reply there?


 Peter den Hartog wrote:
  Yes, i just noticed that error myself, that's something else didn't had
  that before today :-), but that's the whole issue, i think it's not
  sending a new refer, it just creates a new call on line 2, and when i try
  to press transfer and hang up the call disappears and in my phone screen
  i see transfer failed
 
  the situation is like this: 104 is on Asterisk, 105  103 are on
  opensips, 104 takes all the outside calls (for now i made it like this,
  so we are able to transfer the calls announced)
 
  i call from my mobile, true the sip trunk  to 104. I transfer a call from
  104 to 105, this works fine. Then i transfer the same call from 105 to
  103, these last 2 are both opensips extensions..  and that last part,
  doesn't work. the ngrep of a call like this is what you can see in my
  last post
 
  Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Ok thank you for your clear post, here is the grep of the call i made,
  it's
   a outside call to asterisk then a transfer to opensips. (anounched)
  that
   one is working, but then i try a transfer from 105 to 103, this is
  from opensips extention to opensips extention. this one fails.
 
  http://dl.getdropbox.com/u/1382962/grep.txt
 
  I see no REFER request in that trace.
  Also what I see is a 484 Addres Incomplete from Asterisk
 
  Best regards
 
  Iñaki Baz Castillo wrote:
   El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
   Well yes, it does work for the internal calls, but
   when a call comes in true asterisk to an opensips extention i CAN'T
transfer it :-), i get transfer failed in my screen of my phone,
   and the call stays on the original called extention. This is only
   for announced transfers, unannounced works fine.
  
   Flavio post stated something about routing your REFER's back to
   asterisk, so it should work.. but i don't know how to route these
 
  calls
 
   back to the
asterisk.
  
   Please, you *already* have the answer. When a phone is speaking with
   Asterisk
   (through OpenSIPS) you must route REFER to Asterisk as *any* other
   in-dialog
   request, this is, the *same* as when a phone is speaking with other
 
  phone
 
   directly (through OpenSIPS).
  
   If the REFER fails this is because Asterisk is rejecting it !!!
  
   I already suggested you to do a SIP capture (using ngrep) to inspect
   which error replies Asterisk when the REFER arrives to it. Please do
 
  it
 
   and paste it
   here (I expect a 403 or 404, so it means a wrong configuration in you
   Asterisk, no more).
  
   And please, forget anything about exotic routing of the REFER.
 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

I'm sorry, but this is the complete ngrep. I did it like this: ngrep -p -q -W
byline 5060
Maby there is no reply, and that's the issue?


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 I got rid of that error by putting allowguests=no in asterisk, then i
 don't
 get the error.
 i've put a number to a direct opensips extention with
 _x,Dial,1,(SIP/1...@172.16.1.14) (.14 beeing my opensips server
 :))
 
 I called in again, and it ringed @ 105, that works great. Then i do a
 anounched transfer from 105 to 103, and again no succes. Again i added
 the
 log:
 
 http://dl.getdropbox.com/u/1382962/grep2.txt
 
 I'm sorry but I cannot help with this trace as it's incomplete. for
 example 
 some responses are not shown:
 
 
 U 172.16.0.24:5060 - 172.16.1.14:5060
 INVITE sip:1...@172.16.1.14:5060;user=phone SIP/2.0.
 Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
 From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
 To: sip:1...@172.16.1.14;user=phone.
 CSeq: 1 INVITE.
 Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
 Contact: sip:1...@172.16.0.24.
 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
 NOTIFY, 
 PRACK, UPDATE, REFER.
 User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
 Supported: 100rel,replaces.
 Allow-Events: talk,hold,conference.
 Max-Forwards: 70.
 Content-Type: application/sdp.
 Content-Length: 247.
 .
 v=0.
 o=- 1256566109 1256566109 IN IP4 172.16.0.24.
 s=Polycom IP Phone.
 c=IN IP4 172.16.0.24.
 t=0 0.
 a=sendrecv.
 m=audio 2246 RTP/AVP 8 0 18 101.
 a=rtpmap:8 PCMA/8000.
 a=rtpmap:0 PCMU/8000.
 a=rtpmap:18 G729/8000.
 a=rtpmap:101 telephone-event/8000.
 
 
 U 172.16.0.24:5060 - 172.16.1.14:5060
 ACK sip:1...@172.16.1.14:5060 SIP/2.0.
 Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
 From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
 To: 
 sip:1...@172.16.1.14;user=phone;tag=c97b4d1cb1f3d0da549e06a8d482ef63.ed84.
 CSeq: 1 ACK.
 Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
 Contact: sip:1...@172.16.0.24.
 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
 NOTIFY, 
 PRACK, UPDATE, REFER.
 User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
 Max-Forwards: 70.
 Content-Length: 0.
 
 
 
 Where is the reply there?
 
 
 Peter den Hartog wrote:
  Yes, i just noticed that error myself, that's something else didn't had
  that before today :-), but that's the whole issue, i think it's not
  sending a new refer, it just creates a new call on line 2, and when i
 try
  to press transfer and hang up the call disappears and in my phone
 screen
  i see transfer failed
 
  the situation is like this: 104 is on Asterisk, 105  103 are on
  opensips, 104 takes all the outside calls (for now i made it like this,
  so we are able to transfer the calls announced)
 
  i call from my mobile, true the sip trunk  to 104. I transfer a call
 from
  104 to 105, this works fine. Then i transfer the same call from 105 to
  103, these last 2 are both opensips extensions..  and that last part,
  doesn't work. the ngrep of a call like this is what you can see in my
  last post
 
  Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Ok thank you for your clear post, here is the grep of the call i
 made,
  it's
   a outside call to asterisk then a transfer to opensips. (anounched)
  that
   one is working, but then i try a transfer from 105 to 103, this is
  from opensips extention to opensips extention. this one fails.
 
  http://dl.getdropbox.com/u/1382962/grep.txt
 
  I see no REFER request in that trace.
  Also what I see is a 484 Addres Incomplete from Asterisk
 
  Best regards
 
  Iñaki Baz Castillo wrote:
   El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
   Well yes, it does work for the internal calls, but
   when a call comes in true asterisk to an opensips extention i
 CAN'T
transfer it :-), i get transfer failed in my screen of my phone,
   and the call stays on the original called extention. This is only
   for announced transfers, unannounced works fine.
  
   Flavio post stated something about routing your REFER's back to
   asterisk, so it should work.. but i don't know how to route these
 
  calls
 
   back to the
asterisk.
  
   Please, you *already* have the answer. When a phone is speaking
 with
   Asterisk
   (through OpenSIPS) you must route REFER to Asterisk as *any* other
   in-dialog
   request, this is, the *same* as when a phone is speaking with other
 
  phone
 
   directly (through OpenSIPS).
  
   If the REFER fails this is because Asterisk is rejecting it !!!
  
   I already suggested you to do a SIP capture (using ngrep) to
 inspect
   which error replies Asterisk when the REFER arrives to it. Please
 do
 
  it
 
   and paste it
   here (I expect a 403 or 404, so it means a wrong configuration in
 you
   Asterisk, no more).
  
   And please, forget anything about exotic routing of the REFER.
 
 
 
 -- 
 Iñaki Baz

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

The reason there is no reply because, there is no reply, 
On phone 105, i press Xfer - 103, 103 rings i pick it up and then i press
the Xfer button again to actualy transfer it. This result in a hangup on
103, and the outside mobile call is still on 105, on line 2.. It's on
hold... i have to manually resume it, or hang it up...


Peter den Hartog wrote:
 
 I'm sorry, but this is the complete ngrep. I did it like this: ngrep -p -q
 -W byline 5060
 Maby there is no reply, and that's the issue?
 
 
 Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 I got rid of that error by putting allowguests=no in asterisk, then i
 don't
 get the error.
 i've put a number to a direct opensips extention with
 _x,Dial,1,(SIP/1...@172.16.1.14) (.14 beeing my opensips server
 :))
 
 I called in again, and it ringed @ 105, that works great. Then i do a
 anounched transfer from 105 to 103, and again no succes. Again i added
 the
 log:
 
 http://dl.getdropbox.com/u/1382962/grep2.txt
 
 I'm sorry but I cannot help with this trace as it's incomplete. for
 example 
 some responses are not shown:
 
 
 U 172.16.0.24:5060 - 172.16.1.14:5060
 INVITE sip:1...@172.16.1.14:5060;user=phone SIP/2.0.
 Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
 From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
 To: sip:1...@172.16.1.14;user=phone.
 CSeq: 1 INVITE.
 Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
 Contact: sip:1...@172.16.0.24.
 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
 NOTIFY, 
 PRACK, UPDATE, REFER.
 User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
 Supported: 100rel,replaces.
 Allow-Events: talk,hold,conference.
 Max-Forwards: 70.
 Content-Type: application/sdp.
 Content-Length: 247.
 .
 v=0.
 o=- 1256566109 1256566109 IN IP4 172.16.0.24.
 s=Polycom IP Phone.
 c=IN IP4 172.16.0.24.
 t=0 0.
 a=sendrecv.
 m=audio 2246 RTP/AVP 8 0 18 101.
 a=rtpmap:8 PCMA/8000.
 a=rtpmap:0 PCMU/8000.
 a=rtpmap:18 G729/8000.
 a=rtpmap:101 telephone-event/8000.
 
 
 U 172.16.0.24:5060 - 172.16.1.14:5060
 ACK sip:1...@172.16.1.14:5060 SIP/2.0.
 Via: SIP/2.0/UDP 172.16.0.24;branch=z9hG4bKfa15f43e8B64AABF.
 From: 105 sip:1...@172.16.1.14;tag=2BB56AE3-ACF37974.
 To: 
 sip:1...@172.16.1.14;user=phone;tag=c97b4d1cb1f3d0da549e06a8d482ef63.ed84.
 CSeq: 1 ACK.
 Call-ID: 1cab3410-e688f931-83bcb...@172.16.0.24.
 Contact: sip:1...@172.16.0.24.
 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
 NOTIFY, 
 PRACK, UPDATE, REFER.
 User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
 Max-Forwards: 70.
 Content-Length: 0.
 
 
 
 Where is the reply there?
 
 
 Peter den Hartog wrote:
  Yes, i just noticed that error myself, that's something else didn't
 had
  that before today :-), but that's the whole issue, i think it's not
  sending a new refer, it just creates a new call on line 2, and when i
 try
  to press transfer and hang up the call disappears and in my phone
 screen
  i see transfer failed
 
  the situation is like this: 104 is on Asterisk, 105  103 are on
  opensips, 104 takes all the outside calls (for now i made it like
 this,
  so we are able to transfer the calls announced)
 
  i call from my mobile, true the sip trunk  to 104. I transfer a call
 from
  104 to 105, this works fine. Then i transfer the same call from 105 to
  103, these last 2 are both opensips extensions..  and that last part,
  doesn't work. the ngrep of a call like this is what you can see in my
  last post
 
  Iñaki Baz Castillo wrote:
  El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
  Ok thank you for your clear post, here is the grep of the call i
 made,
  it's
   a outside call to asterisk then a transfer to opensips. (anounched)
  that
   one is working, but then i try a transfer from 105 to 103, this is
  from opensips extention to opensips extention. this one fails.
 
  http://dl.getdropbox.com/u/1382962/grep.txt
 
  I see no REFER request in that trace.
  Also what I see is a 484 Addres Incomplete from Asterisk
 
  Best regards
 
  Iñaki Baz Castillo wrote:
   El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
   Well yes, it does work for the internal calls, but
   when a call comes in true asterisk to an opensips extention i
 CAN'T
transfer it :-), i get transfer failed in my screen of my phone,
   and the call stays on the original called extention. This is only
   for announced transfers, unannounced works fine.
  
   Flavio post stated something about routing your REFER's back to
   asterisk, so it should work.. but i don't know how to route these
 
  calls
 
   back to the
asterisk.
  
   Please, you *already* have the answer. When a phone is speaking
 with
   Asterisk
   (through OpenSIPS) you must route REFER to Asterisk as *any* other
   in-dialog
   request, this is, the *same* as when a phone is speaking with
 other
 
  phone
 
   directly (through OpenSIPS).
  
   If the REFER fails this is because Asterisk is rejecting

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Yes, i just noticed that error myself, that's something else didn't had
  that before today :-), but that's the whole issue, i think it's not
  sending a new refer, it just creates a new call on line 2, and when i try
  to press transfer and hang up the call disappears and in my phone screen i
  see transfer failed

This is how attended transfer works:
- A is speaking with B.
- A puts B on hold and sends a *new* INVITE to C (and talks with him).
- A sends a REFER to B with Refer-To: sip:c...@domain;replaces=.
- B then generates an INVITE to C with Replaces header.
- C accepts the call and *replaces* the previous call (established with A) 
since the new INVITE contains a Replaces header with previous dialog 
information.


 
 the situation is like this: 104 is on Asterisk, 105  103 are on opensips,
 104 takes all the outside calls (for now i made it like this, so we are
  able to transfer the calls announced)
 
 i call from my mobile, true the sip trunk  to 104. I transfer a call from
 104 to 105, this works fine. Then i transfer the same call from 105 to 103,
 these last 2 are both opensips extensions..  and that last part, doesn't
 work. the ngrep of a call like this is what you can see in my last post

It's not easy to guess the issue with this information. However, I describe a 
flow that should work:

- Asterisk receives a call and calls to 104 (through OpenSIPS).
- 104 transfers Asterisk to 105, so now Asterisk is speaking with 105.
- 105 transfers Asterisk to 103, so now Asterisk is speaking with 103.

It should work if 105, 103 and 104 have the same configuration for OpenSIPS 
and Asterisk.


 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

ok so you mean it like this?

sip trunk - opensips - asterisk
every call goes true opensips true asterisk to a extention, so asterisk keep
track of all the calls.

so when extention 085* comes in (outside number) i do a dial from opensips
to asterisk, asterisk knows it should dial 105, and then i can transfer the
105 call to 103? I think this will work also.. 

One question tho, what do you mean with:

It should work if 105, 103 and 104 have the same configuration for OpenSIPS 
and Asterisk.

I don't have any asterisk information in the phones now, they all registred
on opensips..



Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Yes, i just noticed that error myself, that's something else didn't had
  that before today :-), but that's the whole issue, i think it's not
  sending a new refer, it just creates a new call on line 2, and when i
 try
  to press transfer and hang up the call disappears and in my phone screen
 i
  see transfer failed
 
 This is how attended transfer works:
 - A is speaking with B.
 - A puts B on hold and sends a *new* INVITE to C (and talks with him).
 - A sends a REFER to B with Refer-To: sip:c...@domain;replaces=.
 - B then generates an INVITE to C with Replaces header.
 - C accepts the call and *replaces* the previous call (established with A) 
 since the new INVITE contains a Replaces header with previous dialog 
 information.
 
 
 
 the situation is like this: 104 is on Asterisk, 105  103 are on
 opensips,
 104 takes all the outside calls (for now i made it like this, so we are
  able to transfer the calls announced)
 
 i call from my mobile, true the sip trunk  to 104. I transfer a call from
 104 to 105, this works fine. Then i transfer the same call from 105 to
 103,
 these last 2 are both opensips extensions..  and that last part, doesn't
 work. the ngrep of a call like this is what you can see in my last post
 
 It's not easy to guess the issue with this information. However, I
 describe a 
 flow that should work:
 
 - Asterisk receives a call and calls to 104 (through OpenSIPS).
 - 104 transfers Asterisk to 105, so now Asterisk is speaking with 105.
 - 105 transfers Asterisk to 103, so now Asterisk is speaking with 103.
 
 It should work if 105, 103 and 104 have the same configuration for
 OpenSIPS 
 and Asterisk.
 
 
  
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892533.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Ok, that's strange.

In Asterisk, i see nothing of this 105 to 103 transfer, only the bye from
105 to my mobile number..
Why isn't opensips sending this information to Asterisk, that's still
strange to me, i mean asterisk should know about the transfer otherwise this
happens.


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 I'm sorry, but this is the complete ngrep. I did it like this: ngrep -p
 -q
  -W byline 5060
 Maby there is no reply, and that's the issue?
 
 No, there must be a response since there is an ACK confirming it.
 No idea why it's not shown.
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892650.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Ok well:

A = mobile phone
B = 101
C = 102

A calls B, true the sip trunk - connected to opensips - that dials B true
Asterisk (B is connected to opensips).

B transfers to C:
B puts A on hold - dials C true Asterisk and opensips (C is also connected
to opensips) there is a call from B to C now, B tells C that A is there, and
B hangs up. The call goes from B to C, the call is now connected true the A
- sip trunk - opensips - asterisk - opensips - C.

I don't see another way to do this.

What i have now is: 
sip trunk - Asterisk - opensips - Extensions and in this scenario  the
outside transfer true Asterisk fails. or atleast, there is no REFER send, i
mean the call DOES go on hold on B, and C is called, but when B disconnects
with C, (so this is the moment the call should actually transfer) the call
from A to B is still there on hold, and is never transferred.

Is this such a strange scenario? That the call never makes the final
destination? 



Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 ok so you mean it like this?
 
 sip trunk - opensips - asterisk
 every call goes true opensips true asterisk to a extention, so asterisk
  keep track of all the calls.
 
 so when extention 085* comes in (outside number) i do a dial from
 opensips
 to asterisk, asterisk knows it should dial 105, and then i can transfer
 the
 105 call to 103? I think this will work also.. 
 
 One question tho, what do you mean with:
 
 It should work if 105, 103 and 104 have the same configuration for
  OpenSIPS  and Asterisk.
 
 I don't have any asterisk information in the phones now, they all
 registred
 on opensips..
 
 
 I don't fully understand your scenario. Please describe it to me as I 
 described this one:
 
 This is how attended transfer works:
 - A is speaking with B.
 - A puts B on hold and sends a new INVITE to C (and talks with him).
 - A sends a REFER to B with Refer-To: sip:c...@domain;replaces=.
 - B then generates an INVITE to C with Replaces header.
 - C accepts the call and replaces the previous call (established with A) 
 since the new INVITE contains a Replaces header with previous dialog 
 information.
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3892825.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Anybody has any information about this? I mean, if it should work by
  default, the transfering from another domain, why is this going wrong? Why
  is Asterisk not receiving a refer from my phone? i noticed with a blind
  transfer it's a ACK or something like that?
 
 If needed i can post my full script + asterisk config.. 

Peter, don't take me wrong but this is more like a consultance service, rather 
than a specific question about OpenSIPS.

-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Ok well:
 
 A = mobile phone
 B = 101
 C = 102
 
 A calls B, true the sip trunk - connected to opensips - that dials B true
 Asterisk (B is connected to opensips).

so:

  A -- Provider -- OpenSIPS -- Asterisk -- B
  A -- Provider -- OpenSIPS -- C


 B transfers to C:

 B puts A on hold

No, that's an error. B puts *Asterisk* on hold, but not A (you cannot see a 
re-INVITE from Asterisk to A, but just from B to Asterisk).


 - dials C true Asterisk and opensips (C is also connected
 to opensips) there is a call from B to C now,

No, there are these calls:

Call between B and A (two dialogs in fact):
- B -- Asterisk
- Asterisk --(opensips)-- --(provider)-- A

Call between B anc C (two dialogs in fact):
- B -- Asterisk
- Asterisk --(opensips)-- C


 B tells C that A is there,
  and B hangs up.

Ohhh, B hangs up... so you are doing Asterisk transfer instead of SIP 
transfer??? (so you are doing the transference using DTFM???)

The of course there is NO REFER !

However it doesn't affect the scenario.



  The call goes from B to C, the call is now connected true
  the A - sip trunk - opensips - asterisk - opensips - C.


 I don't see another way to do this.

Yes, it's valid.





-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Sorry that was not my intention at all, i'm just eager to learn. Sorry for
that :)


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Anybody has any information about this? I mean, if it should work by
  default, the transfering from another domain, why is this going wrong?
 Why
  is Asterisk not receiving a refer from my phone? i noticed with a blind
  transfer it's a ACK or something like that?
 
 If needed i can post my full script + asterisk config.. 
 
 Peter, don't take me wrong but this is more like a consultance service,
 rather 
 than a specific question about OpenSIPS.
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3893012.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Well, it doesn't matter if i hang up, use the transfer button again or
anything the result is the same, my call is gone. :)

I understand the rest of your post tho, :) thanks alot for your input.



Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Ok well:
 
 A = mobile phone
 B = 101
 C = 102
 
 A calls B, true the sip trunk - connected to opensips - that dials B
 true
 Asterisk (B is connected to opensips).
 
 so:
 
   A -- Provider -- OpenSIPS -- Asterisk -- B
   A -- Provider -- OpenSIPS -- C
 
 
 B transfers to C:
 
 B puts A on hold
 
 No, that's an error. B puts *Asterisk* on hold, but not A (you cannot see
 a 
 re-INVITE from Asterisk to A, but just from B to Asterisk).
 
 
 - dials C true Asterisk and opensips (C is also connected
 to opensips) there is a call from B to C now,
 
 No, there are these calls:
 
 Call between B and A (two dialogs in fact):
 - B -- Asterisk
 - Asterisk --(opensips)-- --(provider)-- A
 
 Call between B anc C (two dialogs in fact):
 - B -- Asterisk
 - Asterisk --(opensips)-- C
 
 
 B tells C that A is there,
  and B hangs up.
 
 Ohhh, B hangs up... so you are doing Asterisk transfer instead of SIP 
 transfer??? (so you are doing the transference using DTFM???)
 
 The of course there is NO REFER !
 
 However it doesn't affect the scenario.
 
 
 
  The call goes from B to C, the call is now connected true
  the A - sip trunk - opensips - asterisk - opensips - C.
 
 
 I don't see another way to do this.
 
 Yes, it's valid.
 
 
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3893042.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Iñaki Baz Castillo 
El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Sorry that was not my intention at all, i'm just eager to learn. Sorry for
 that :)

oh, don't worry at all, I  just mean that such questions are too wide (as 
they involve opensips and asterisk integration and so...).




-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-26 Thread Peter den Hartog 

Ok so i did a little drawing to make stuff clear for myself (PDF warning!!!)

http://dl.getdropbox.com/u/1382962/opensips.pdf

Black arrows are all connections, green is the first call, and yellow is the
transfer, am i thinking correct now :)? The yellow arrow goes from ext 100
to opensips, to asterisk, to ext 101, back to opensips to the sip trunk and
outside.


Iñaki Baz Castillo wrote:
 
 El Lunes, 26 de Octubre de 2009, Peter den Hartog escribió:
 Sorry that was not my intention at all, i'm just eager to learn. Sorry
 for
 that :)
 
 oh, don't worry at all, I  just mean that such questions are too wide
 (as 
 they involve opensips and asterisk integration and so...).
 
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3893249.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-24 Thread Bogdan-Andrei Iancu 
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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-24 Thread Jeff Kronlage 
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-boun...@lists.opensips.org 
[mailto:users-boun...@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-24 Thread Jeff Pyle 
Yes, samples/examples would be fantastic.  My first adventure into the b2bua
module ended about as quickly as it began with mountains of auth problems.
For example, I'd love to see the differences between a standard
(non-b2bua) call routing config and one that accomplished much the same
thing but with the topology hiding scenario in use.  And while solving this
REFER situation sounds less of a priority to me than to Jeff K., I feel I
must walk with the tophiding before I can run with REFERs.


- Jeff



On 10/24/09 10:50 PM, Jeff Kronlage j...@data102.com 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-boun...@lists.opensips.org
 [mailto:users-boun...@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@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

I moved my opensips in the network, it's now directly connected to my sip
trunk, i can call inside, i can call outside. I can transfer inside. But
when i try to tranfser an outside nummer i get to see this ngrep:

U 90.145.5.96:5060 - 90.145.5.83:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:90.145.5.83;lr=on,
sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 70.
Content-Length: 0.
.


U 90.145.5.83:5060 - 77.73.226.254:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 69.
Content-Length: 0.
.


U 77.73.226.254:5060 - 90.145.5.83:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.


U 90.145.5.83:5060 - 90.145.5.96:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.

It makes sense to me that i forgot something in my config, a refer module or
something? any toughts/pushes in the right direction would be greatly
appreciated!

best regards.
-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877950.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Raúl Alexis Betancor Santana 
On Friday 23 October 2009 11:39:44 Peter den Hartog wrote:
 I moved my opensips in the network, it's now directly connected to my sip
 trunk, i can call inside, i can call outside. I can transfer inside. But
 when i try to tranfser an outside nummer i get to see this ngrep:

[..]

 It makes sense to me that i forgot something in my config, a refer module
 or something? any toughts/pushes in the right direction would be greatly
 appreciated!

As far as I see ... 77.73.226.254 it's refusing to do the REFER, what are 
you inside IP's, and what are you outside one ? ...

-- 
Raúl Alexis Betancor Santana
Dimensión Virtual

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

77 is the sip trunk, 90 are my IP's.



Raúl Alexis Betancor Santana wrote:
 
 On Friday 23 October 2009 11:39:44 Peter den Hartog wrote:
 I moved my opensips in the network, it's now directly connected to my sip
 trunk, i can call inside, i can call outside. I can transfer inside. But
 when i try to tranfser an outside nummer i get to see this ngrep:
 
 [..]
 
 It makes sense to me that i forgot something in my config, a refer module
 or something? any toughts/pushes in the right direction would be greatly
 appreciated!
 
 As far as I see ... 77.73.226.254 it's refusing to do the REFER, what are 
 you inside IP's, and what are you outside one ? ...
 
 -- 
 Raúl Alexis Betancor Santana
 Dimensión Virtual
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 



-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877992.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Raúl Alexis Betancor Santana 
Peter den Hartog escribió:
 77 is the sip trunk, 90 are my IP's.
   

So, it's your trunk provider the one who refuses to do the REFER

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 yeah i understand that, but why is it sending this refer to the sip trunk?
  i mean..
 
 it's an outside call going to a local extention, i want to transfer from 1
 local extention to another, so why isn't my opensips doing this refer?

Sorry but you don't seem to understand how a REFER transfer works:

1) Your PSTN provider sends an INVITE to your proxy (opensips).
2) OpenSIPS routes the call to user1.
3) User1 answers the call and so.
4) User1 wants to transfer the call to user2.
5) User1 sends a REFER to *the PSTN provider* (through OpenSIPS as any in-
dialog request).
6) The PSTN provider accepts the refer so *initiates* a new call to user2.

Of course point 5 will NEVER work with a PSTN provider (and shouldn't work at 
all!). This is why PBX/B2BUA do exist: to enable PBX features.

If you just have a proxy and receive calls from a PSTN you could NEVER 
transfer that call to other user.

Having a PBX/B2BUA the sceario changes and allows transference. An example 
scenario:

1) Your PSTN provider sends an INVITE to your PBX (B2BUA).
2) The PBX generates a *new* INVITE (a different dialog) to OpenSIPS.
3) OpenSIPS routes the call to user1.
4) User1 answers the call.
5) User1 wants to transfer the call to user2.
6) User1 sends a REFER to *the PBX* (through OpenSIPS as any in-dialog 
request).
7) The PBX  provider accepts the refer so *initiates* a new call to user2.
8) The PSTN provider didn't realize, at all, about the transference.




-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Alex Balashov 
OpenSIPS (in this case) is a proxy, not a user agent.  It cannot do 
the REFER.

Peter den Hartog wrote:

 yeah i understand that, but why is it sending this refer to the sip trunk? i
 mean..
 
 it's an outside call going to a local extention, i want to transfer from 1
 local extention to another, so why isn't my opensips doing this refer?
 
 
 Raúl Alexis Betancor Santana wrote:
 Peter den Hartog escribió:
 77 is the sip trunk, 90 are my IP's.
   
 So, it's your trunk provider the one who refuses to do the REFER

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


 


-- 
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

Oke that is clear to me,

So if i want the transfer function, i have to use a asterisk as a gateway
(or any other pbx).
But how do you create this new channel? i tried this before, with an
asterisk as pbx, that received the outside calls... i've created a dial from
asterisk to my opensips extention, but this is clearly wrong because if i
try a transfer then, he tries it on the asterisk.. result the new
destination not found..

What i understand from your story is that asterisk shouldn't do a dial, but
a invite to the opensips extention, am i right?  Any ideas on how to do
this? 


Iñaki Baz Castillo wrote:
 
 El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 yeah i understand that, but why is it sending this refer to the sip
 trunk?
  i mean..
 
 it's an outside call going to a local extention, i want to transfer from
 1
 local extention to another, so why isn't my opensips doing this refer?
 
 Sorry but you don't seem to understand how a REFER transfer works:
 
 1) Your PSTN provider sends an INVITE to your proxy (opensips).
 2) OpenSIPS routes the call to user1.
 3) User1 answers the call and so.
 4) User1 wants to transfer the call to user2.
 5) User1 sends a REFER to *the PSTN provider* (through OpenSIPS as any in-
 dialog request).
 6) The PSTN provider accepts the refer so *initiates* a new call to user2.
 
 Of course point 5 will NEVER work with a PSTN provider (and shouldn't work
 at 
 all!). This is why PBX/B2BUA do exist: to enable PBX features.
 
 If you just have a proxy and receive calls from a PSTN you could NEVER 
 transfer that call to other user.
 
 Having a PBX/B2BUA the sceario changes and allows transference. An example 
 scenario:
 
 1) Your PSTN provider sends an INVITE to your PBX (B2BUA).
 2) The PBX generates a *new* INVITE (a different dialog) to OpenSIPS.
 3) OpenSIPS routes the call to user1.
 4) User1 answers the call.
 5) User1 wants to transfer the call to user2.
 6) User1 sends a REFER to *the PBX* (through OpenSIPS as any in-dialog 
 request).
 7) The PBX  provider accepts the refer so *initiates* a new call to user2.
 8) The PSTN provider didn't realize, at all, about the transference.
 
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3878529.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 Oke that is clear to me,
 
 So if i want the transfer function, i have to use a asterisk as a gateway
 (or any other pbx).
 But how do you create this new channel? i tried this before, with an
 asterisk as pbx, that received the outside calls... i've created a dial
  from asterisk to my opensips extention, but this is clearly wrong because
  if i try a transfer then, he tries it on the asterisk.. result the new
 destination not found..

If destination not found that means that your dialplan is not correctly 
configured. If user1 transfer to Asterisk to user2, this means that Asterisk 
will look for user2 extension in the context of OpenSIPs peer. So exten = 
user2 must exist there.


 What i understand from your story is that asterisk shouldn't do a dial, but
 a invite to the opensips extention, am i right?

No, it's the same doing a dial and sending an invite. Asterisk just can 
send an INVITE.


 Any ideas on how to do this?

There are some doucments/howtos in OpenSIPS wiki about integration woth 
Asterisk. Not sure if they fully cover users integration (so transfer is 
possible and so).
However I've this exact scenario working perfectly. It's just a taste of 
configuration (peers and dialplan in Asterisk).




 
 Iñaki Baz Castillo wrote:
  El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
  yeah i understand that, but why is it sending this refer to the sip
  trunk?
   i mean..
 
  it's an outside call going to a local extention, i want to transfer from
  1
  local extention to another, so why isn't my opensips doing this refer?
 
  Sorry but you don't seem to understand how a REFER transfer works:
 
  1) Your PSTN provider sends an INVITE to your proxy (opensips).
  2) OpenSIPS routes the call to user1.
  3) User1 answers the call and so.
  4) User1 wants to transfer the call to user2.
  5) User1 sends a REFER to *the PSTN provider* (through OpenSIPS as any
  in- dialog request).
  6) The PSTN provider accepts the refer so *initiates* a new call to
  user2.
 
  Of course point 5 will NEVER work with a PSTN provider (and shouldn't
  work at
  all!). This is why PBX/B2BUA do exist: to enable PBX features.
 
  If you just have a proxy and receive calls from a PSTN you could NEVER
  transfer that call to other user.
 
  Having a PBX/B2BUA the sceario changes and allows transference. An
  example scenario:
 
  1) Your PSTN provider sends an INVITE to your PBX (B2BUA).
  2) The PBX generates a *new* INVITE (a different dialog) to OpenSIPS.
  3) OpenSIPS routes the call to user1.
  4) User1 answers the call.
  5) User1 wants to transfer the call to user2.
  6) User1 sends a REFER to *the PBX* (through OpenSIPS as any in-dialog
  request).
  7) The PBX  provider accepts the refer so *initiates* a new call to
  user2. 8) The PSTN provider didn't realize, at all, about the
  transference.
 


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

ok, but i want to have my users registered to opensips. And what happend
before was this -
call from outside - asterisk did a dial to 101 in opensips - 101 ringed i
had a call..

transfer this call from 101 to 102 - i've got a new call on line two from
phone 101 to 102, but the call from the outside, was on hold on 101 on line
1..  Blind transfers work perfectly, but not the announced transfers. they
just go on hold, and when i press transfer after telling 102 that i have a
call from 101, the call just stays on 101 in hold.

How did you fix this? Do you have working announced transfers?


Iñaki Baz Castillo wrote:
 
 El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 Oke that is clear to me,
 
 So if i want the transfer function, i have to use a asterisk as a gateway
 (or any other pbx).
 But how do you create this new channel? i tried this before, with an
 asterisk as pbx, that received the outside calls... i've created a dial
  from asterisk to my opensips extention, but this is clearly wrong
 because
  if i try a transfer then, he tries it on the asterisk.. result the new
 destination not found..
 
 If destination not found that means that your dialplan is not correctly 
 configured. If user1 transfer to Asterisk to user2, this means that
 Asterisk 
 will look for user2 extension in the context of OpenSIPs peer. So exten
 = 
 user2 must exist there.
 
 
 What i understand from your story is that asterisk shouldn't do a dial,
 but
 a invite to the opensips extention, am i right?
 
 No, it's the same doing a dial and sending an invite. Asterisk just
 can 
 send an INVITE.
 
 
 Any ideas on how to do this?
 
 There are some doucments/howtos in OpenSIPS wiki about integration woth 
 Asterisk. Not sure if they fully cover users integration (so transfer is 
 possible and so).
 However I've this exact scenario working perfectly. It's just a taste of 
 configuration (peers and dialplan in Asterisk).
 
 
 
 
 
 Iñaki Baz Castillo wrote:
  El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
  yeah i understand that, but why is it sending this refer to the sip
  trunk?
   i mean..
 
  it's an outside call going to a local extention, i want to transfer
 from
  1
  local extention to another, so why isn't my opensips doing this refer?
 
  Sorry but you don't seem to understand how a REFER transfer works:
 
  1) Your PSTN provider sends an INVITE to your proxy (opensips).
  2) OpenSIPS routes the call to user1.
  3) User1 answers the call and so.
  4) User1 wants to transfer the call to user2.
  5) User1 sends a REFER to *the PSTN provider* (through OpenSIPS as any
  in- dialog request).
  6) The PSTN provider accepts the refer so *initiates* a new call to
  user2.
 
  Of course point 5 will NEVER work with a PSTN provider (and shouldn't
  work at
  all!). This is why PBX/B2BUA do exist: to enable PBX features.
 
  If you just have a proxy and receive calls from a PSTN you could NEVER
  transfer that call to other user.
 
  Having a PBX/B2BUA the sceario changes and allows transference. An
  example scenario:
 
  1) Your PSTN provider sends an INVITE to your PBX (B2BUA).
  2) The PBX generates a *new* INVITE (a different dialog) to OpenSIPS.
  3) OpenSIPS routes the call to user1.
  4) User1 answers the call.
  5) User1 wants to transfer the call to user2.
  6) User1 sends a REFER to *the PBX* (through OpenSIPS as any in-dialog
  request).
  7) The PBX  provider accepts the refer so *initiates* a new call to
  user2. 8) The PSTN provider didn't realize, at all, about the
  transference.
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3878699.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Jeff Kronlage 
I too am interested in this issue.  Most of our users have PBXs that generate 
the second INVITE out-of-the-box, but we're about to move into residential 
service (hence my slew of NAT-related posts recently), and I'd like to have 
transfers/REFERs working natively in OpenSIPS without having to involve 
Asterisk.

My biggest question, not having moved to 1.6 or looked into the B2BUA module, 
is:  Is it possible to have opensips generate a 2nd INVITE (additional call 
leg) by capturing the REFER and using the new B2BUA module?

My secondary question, is, if not, would anyone be willing to post some basic 
documentation on how this can be achieved with Asterisk sitting behind 
Opensips (i.e. Opensips holds the registration, and does the majority of the 
call processing, and only sends packets/calls to Asterisk for features that a 
proxy isn't supposed to handle?)  

Cheers,

Jeff

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Peter den Hartog
Sent: Friday, October 23, 2009 7:22 AM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Transfer issue


ok, but i want to have my users registered to opensips. And what happend
before was this -
call from outside - asterisk did a dial to 101 in opensips - 101 ringed i
had a call..

transfer this call from 101 to 102 - i've got a new call on line two from
phone 101 to 102, but the call from the outside, was on hold on 101 on line
1..  Blind transfers work perfectly, but not the announced transfers. they
just go on hold, and when i press transfer after telling 102 that i have a
call from 101, the call just stays on 101 in hold.

How did you fix this? Do you have working announced transfers?


Iñaki Baz Castillo wrote:
 
 El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 Oke that is clear to me,
 
 So if i want the transfer function, i have to use a asterisk as a gateway
 (or any other pbx).
 But how do you create this new channel? i tried this before, with an
 asterisk as pbx, that received the outside calls... i've created a dial
  from asterisk to my opensips extention, but this is clearly wrong
 because
  if i try a transfer then, he tries it on the asterisk.. result the new
 destination not found..
 
 If destination not found that means that your dialplan is not correctly 
 configured. If user1 transfer to Asterisk to user2, this means that
 Asterisk 
 will look for user2 extension in the context of OpenSIPs peer. So exten
 = 
 user2 must exist there.
 
 
 What i understand from your story is that asterisk shouldn't do a dial,
 but
 a invite to the opensips extention, am i right?
 
 No, it's the same doing a dial and sending an invite. Asterisk just
 can 
 send an INVITE.
 
 
 Any ideas on how to do this?
 
 There are some doucments/howtos in OpenSIPS wiki about integration woth 
 Asterisk. Not sure if they fully cover users integration (so transfer is 
 possible and so).
 However I've this exact scenario working perfectly. It's just a taste of 
 configuration (peers and dialplan in Asterisk).
 
 
 
 
 
 Iñaki Baz Castillo wrote:
  El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
  yeah i understand that, but why is it sending this refer to the sip
  trunk?
   i mean..
 
  it's an outside call going to a local extention, i want to transfer
 from
  1
  local extention to another, so why isn't my opensips doing this refer?
 
  Sorry but you don't seem to understand how a REFER transfer works:
 
  1) Your PSTN provider sends an INVITE to your proxy (opensips).
  2) OpenSIPS routes the call to user1.
  3) User1 answers the call and so.
  4) User1 wants to transfer the call to user2.
  5) User1 sends a REFER to *the PSTN provider* (through OpenSIPS as any
  in- dialog request).
  6) The PSTN provider accepts the refer so *initiates* a new call to
  user2.
 
  Of course point 5 will NEVER work with a PSTN provider (and shouldn't
  work at
  all!). This is why PBX/B2BUA do exist: to enable PBX features.
 
  If you just have a proxy and receive calls from a PSTN you could NEVER
  transfer that call to other user.
 
  Having a PBX/B2BUA the sceario changes and allows transference. An
  example scenario:
 
  1) Your PSTN provider sends an INVITE to your PBX (B2BUA).
  2) The PBX generates a *new* INVITE (a different dialog) to OpenSIPS.
  3) OpenSIPS routes the call to user1.
  4) User1 answers the call.
  5) User1 wants to transfer the call to user2.
  6) User1 sends a REFER to *the PBX* (through OpenSIPS as any in-dialog
  request).
  7) The PBX  provider accepts the refer so *initiates* a new call to
  user2. 8) The PSTN provider didn't realize, at all, about the
  transference.
 
 
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 ok, but i want to have my users registered to opensips. And what happend
 before was this -
 call from outside - asterisk did a dial to 101 in opensips - 101 ringed i
 had a call..
 
 transfer this call from 101 to 102 - i've got a new call on line two from
 phone 101 to 102, but the call from the outside, was on hold on 101 on line
 1..  Blind transfers work perfectly, but not the announced transfers. they
 just go on hold, and when i press transfer after telling 102 that i have a
 call from 101, the call just stays on 101 in hold.
 
 How did you fix this? Do you have working announced transfers?

I didn't fix it as I did never experiment that issue. It *must* be a bug 
related to you configuration (NAT or whatever).

-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

I don't have any nat involved here.

so you simply get everything from asterisk to your opensips? and in asterisk
you just have something like:

exten = outsidenumber,1,Dial,(SIP/1...@opensips)?

Because this is how i do it.. and when it reaches my phone this way, i'm
unable to transfer.



Iñaki Baz Castillo wrote:
 
 El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 ok, but i want to have my users registered to opensips. And what happend
 before was this -
 call from outside - asterisk did a dial to 101 in opensips - 101 ringed
 i
 had a call..
 
 transfer this call from 101 to 102 - i've got a new call on line two
 from
 phone 101 to 102, but the call from the outside, was on hold on 101 on
 line
 1..  Blind transfers work perfectly, but not the announced transfers.
 they
 just go on hold, and when i press transfer after telling 102 that i have
 a
 call from 101, the call just stays on 101 in hold.
 
 How did you fix this? Do you have working announced transfers?
 
 I didn't fix it as I did never experiment that issue. It *must* be a bug 
 related to you configuration (NAT or whatever).
 
 -- 
 Iñaki Baz Castillo i...@aliax.net
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3878794.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Viernes, 23 de Octubre de 2009, Jeff Kronlage escribió:

 My biggest question, not having moved to 1.6 or looked into the B2BUA
  module, is:  Is it possible to have opensips generate a 2nd INVITE
  (additional call leg) by capturing the REFER and using the new B2BUA
  module?

Not sure, any how it would be a hack.

 
 My secondary question, is, if not, would anyone be willing to post some
  basic documentation on how this can be achieved with Asterisk sitting
  behind Opensips (i.e. Opensips holds the registration, and does the
  majority of the call processing, and only sends packets/calls to Asterisk
  for features that a proxy isn't supposed to handle?)

I've this scenario working perfectly, but I cannot paste all the configuration 
as it belongs to my company. Anyhow you could describe the issue you have, 
some traces and so.


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Viernes, 23 de Octubre de 2009, Peter den Hartog escribió:
 I don't have any nat involved here.
 
 so you simply get everything from asterisk to your opensips? and in
  asterisk you just have something like:
 
 exten = outsidenumber,1,Dial,(SIP/1...@opensips)?
 
 Because this is how i do it.. and when it reaches my phone this way, i'm
 unable to transfer.

You should do a SIP capture to see what happens when the REFER arrives to 
Asterisk. What does Asterisk reply? 200? 403? 404?

-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Flavio E. Goncalves 
Hi Peter,

You need to have support for REFER in all the SIP components, UACs 
and Gateways. Your SIP provider seems to be refusing your REFERS with 
the message 501 Not Implemented. The only way to workaround (as far 
as I know) is to use a gateway before your SIP provider that 
implements the REFER messages. You can do this using Asterisk. Handle 
the REFERs in the same way you do with INVITEs, there is a parameter 
called allowexternaldomains and it needs to be set to yes. The 
security for REFERs is the same as the one used for INVITEs.

Regards,

Flavio E. Goncalves

At 08:39 AM 10/23/2009, you wrote:

I moved my opensips in the network, it's now directly connected to my sip
trunk, i can call inside, i can call outside. I can transfer inside. But
when i try to tranfser an outside nummer i get to see this ngrep:

U 90.145.5.96:5060 - 90.145.5.83:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:90.145.5.83;lr=on,
sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 70.
Content-Length: 0.
.


U 90.145.5.83:5060 - 77.73.226.254:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 69.
Content-Length: 0.
.


U 77.73.226.254:5060 - 90.145.5.83:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.


U 90.145.5.83:5060 - 90.145.5.96:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.

It makes sense to me that i forgot something in my config, a refer module or
something? any toughts/pushes in the right direction would be greatly
appreciated!

best regards.
--
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877950.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Peter den Hartog 

Hello flavio, thank you for your response.

It makes sence to me, so i have to use asterisk as a gateway infront of
opensips, and let it handle outside domains to do stuff like
invites/refers.. 

The parameter your talking about is a Asterisk parameter right? I will look
in to this.
Thank you for the information, it's a tricky journey into opensips, but i'm
getting there :D

Flavio Goncalves wrote:
 
 Hi Peter,
 
 You need to have support for REFER in all the SIP components, UACs 
 and Gateways. Your SIP provider seems to be refusing your REFERS with 
 the message 501 Not Implemented. The only way to workaround (as far 
 as I know) is to use a gateway before your SIP provider that 
 implements the REFER messages. You can do this using Asterisk. Handle 
 the REFERs in the same way you do with INVITEs, there is a parameter 
 called allowexternaldomains and it needs to be set to yes. The 
 security for REFERs is the same as the one used for INVITEs.
 
 Regards,
 
 Flavio E. Goncalves
 
 At 08:39 AM 10/23/2009, you wrote:
 
I moved my opensips in the network, it's now directly connected to my sip
trunk, i can call inside, i can call outside. I can transfer inside. But
when i try to tranfser an outside nummer i get to see this ngrep:

U 90.145.5.96:5060 - 90.145.5.83:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:90.145.5.83;lr=on,
sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 70.
Content-Length: 0.
.


U 90.145.5.83:5060 - 77.73.226.254:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 69.
Content-Length: 0.
.


U 77.73.226.254:5060 - 90.145.5.83:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.


U 90.145.5.83:5060 - 90.145.5.96:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C60.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.

It makes sense to me that i forgot something in my config, a refer module
or
something? any toughts/pushes in the right direction would be greatly
appreciated!

best regards.
--
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877950.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3881352.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Jeff Kronlage 
I'd like to be certain I understand from these last few posts regarding
this topic-

The suggestion is to use Asterisk 'behind' Opensips, transferring calls
to it only when a B2BUA is necessary?

I certainly understand not wanting to post a config, but can anyone
share a general idea of how this is accomplished?  I'm having a hard
time picturing how to send Asterisk an out-of-context REFER, while
Opensips 'held' the call up to that point.  Perhaps I'm over-thinking
it.

Thanks,

Jeff

-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Peter den Hartog
Sent: Friday, October 23, 2009 3:15 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Transfer issue


Hello flavio, thank you for your response.

It makes sence to me, so i have to use asterisk as a gateway infront of
opensips, and let it handle outside domains to do stuff like
invites/refers.. 

The parameter your talking about is a Asterisk parameter right? I will
look
in to this.
Thank you for the information, it's a tricky journey into opensips, but
i'm
getting there :D

Flavio Goncalves wrote:
 
 Hi Peter,
 
 You need to have support for REFER in all the SIP components, UACs 
 and Gateways. Your SIP provider seems to be refusing your REFERS with 
 the message 501 Not Implemented. The only way to workaround (as far 
 as I know) is to use a gateway before your SIP provider that 
 implements the REFER messages. You can do this using Asterisk. Handle 
 the REFERs in the same way you do with INVITEs, there is a parameter 
 called allowexternaldomains and it needs to be set to yes. The 
 security for REFERs is the same as the one used for INVITEs.
 
 Regards,
 
 Flavio E. Goncalves
 
 At 08:39 AM 10/23/2009, you wrote:
 
I moved my opensips in the network, it's now directly connected to my
sip
trunk, i can call inside, i can call outside. I can transfer inside.
But
when i try to tranfser an outside nummer i get to see this ngrep:

U 90.145.5.96:5060 - 90.145.5.83:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C6
0.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:90.145.5.83;lr=on,
sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 70.
Content-Length: 0.
.


U 90.145.5.83:5060 - 77.73.226.254:5060
REFER sip:sip_...@217.112.112.114 SIP/2.0.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C6
0.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Route: sip:77.73.226.254;lr=on;ftag=202954455;did=4b1.a8f7e0a5.
CSeq: 2 REFER.
Call-ID: 1975939...@217.112.112.114.
Contact: sip:1...@90.145.5.96.
User-Agent: PolycomSoundPointIP-SPIP_430-UA/1.6.7.0133.
Refer-To: sip:1...@90.145.5.83:5060.
Referred-By: sip:1...@90.145.5.83.
Max-Forwards: 69.
Content-Length: 0.
.


U 77.73.226.254:5060 - 90.145.5.83:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.83;branch=z9hG4bK0582.ce0b1427.0.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C6
0.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.


U 90.145.5.83:5060 - 90.145.5.96:5060
SIP/2.0 501 Not Implemented.
Via: SIP/2.0/UDP 90.145.5.96;branch=z9hG4bK80db89a3AE4DF976.
From:
sip:0031851110...@77.73.226.254:5060;user=phone;tag=519E7E95-45526C6
0.
To: sip:0624469...@217.112.112.114;user=phone;tag=202954455.
Call-ID: 1975939...@217.112.112.114.
CSeq: 2 REFER.
Content-Length: 0.
.

It makes sense to me that i forgot something in my config, a refer
module
or
something? any toughts/pushes in the right direction would be greatly
appreciated!

best regards.
--
View this message in context: 
http://n2.nabble.com/Transfer-issue-tp3877950p3877950.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 

-- 
View this message in context:
http://n2.nabble.com/Transfer-issue-tp3877950p3881352.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió:
 The suggestion is to use Asterisk 'behind' Opensips, transferring calls
 to it only when a B2BUA is necessary?

Not exactly, see below.

 
 I certainly understand not wanting to post a config, but can anyone
 share a general idea of how this is accomplished?  I'm having a hard
 time picturing how to send Asterisk an out-of-context REFER,

Why out-of-context REFER??

 while Opensips 'held' the call up to that point.  Perhaps I'm over-thinking
 it.


- user1 sends an INVITE to OpenSIPS with RURI sip:us...@domain.

- OpenSIPS doesn do a lookup, instead it routes the INVITE to Asterisk 
*without* changing the RURI username (user2).

- Asterisk receives a call from peer [opensips] to exten user2.

- Asterisk ejecutes Dial and generates an INVITE with RURI user2 and sends 
it to OpenSIPS.

- OpenSIPS receives the INVITE and, since it comes from Asterisk, now it 
*does* the lookup so retrieves the location(s) of user2, and sends there the 
INVITE.

- So now we have 2 calls:
  - user1 speaking with Asterisk (through OpenSIPS).
  - Asterisk speaking with user2 (through OpenSIPS).

- Now user1 wants to transfer the call to user3 so it sends an in-dialog REFER 
(with Refer-To: sip:us...@domain) to Asterisk.

- Asterisk accepts it and generates an INVITE to user3 sending it to 
OpenSIPS.

- OpenSIPS does the loockup for user3 and routes there the new INVITE from 
Asterisk.

- etc etc etc... and the transference (blink or attended is performed as 
usual).


Does it help you?


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Jeff Kronlage 
I follow this, but -and please correct me where I'm misunderstanding- isn't the 
point of using a Proxy versus a B2BUA is that it's more lightweight and 
scalable?  It seems with this setup every call ends up routed through Asterisk 
on the initial INVITE, simply so that when a REFER potentially comes later in 
the dialog, it can handle it.  Our setup has been initially engineered for 
thousands of concurrent calls, and we're hoping to avoid having a dozen 
Asterisk machines :)

Our goal is to design something like:

UA -- Opensips -- Our PSTN gateways

That could dynamically turn into, on the fly:

UA -- Opensips -- B2BUA -- Our PSTN Gateway

We haven't found a clean way of doing this, unfortunately...  It may just end 
up being a hack on Opensips 1.6 if that might work.

Jeff

-Original Message-
From: users-boun...@lists.opensips.org 
[mailto:users-boun...@lists.opensips.org] On Behalf Of Iñaki Baz Castillo
Sent: Friday, October 23, 2009 5:38 PM
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Transfer issue

El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió:
 The suggestion is to use Asterisk 'behind' Opensips, transferring calls
 to it only when a B2BUA is necessary?

Not exactly, see below.

 
 I certainly understand not wanting to post a config, but can anyone
 share a general idea of how this is accomplished?  I'm having a hard
 time picturing how to send Asterisk an out-of-context REFER,

Why out-of-context REFER??

 while Opensips 'held' the call up to that point.  Perhaps I'm over-thinking
 it.


- user1 sends an INVITE to OpenSIPS with RURI sip:us...@domain.

- OpenSIPS doesn do a lookup, instead it routes the INVITE to Asterisk 
*without* changing the RURI username (user2).

- Asterisk receives a call from peer [opensips] to exten user2.

- Asterisk ejecutes Dial and generates an INVITE with RURI user2 and sends 
it to OpenSIPS.

- OpenSIPS receives the INVITE and, since it comes from Asterisk, now it 
*does* the lookup so retrieves the location(s) of user2, and sends there the 
INVITE.

- So now we have 2 calls:
  - user1 speaking with Asterisk (through OpenSIPS).
  - Asterisk speaking with user2 (through OpenSIPS).

- Now user1 wants to transfer the call to user3 so it sends an in-dialog REFER 
(with Refer-To: sip:us...@domain) to Asterisk.

- Asterisk accepts it and generates an INVITE to user3 sending it to 
OpenSIPS.

- OpenSIPS does the loockup for user3 and routes there the new INVITE from 
Asterisk.

- etc etc etc... and the transference (blink or attended is performed as 
usual).


Does it help you?


-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Iñaki Baz Castillo 
El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió:
 I follow this, but -and please correct me where I'm misunderstanding- isn't
  the point of using a Proxy versus a B2BUA is that it's more lightweight
  and scalable?

Of course, but if you want PBX features you need a B2BUA. Also, trasferring a 
call from a SIP PSTN provider does require *always* a B2BUA (in fact the user 
doesn't transfer the provider, but the B2BUA which will accept such REFER).



  It seems with this setup every call ends up routed through
  Asterisk on the initial INVITE, simply so that when a REFER potentially
  comes later in the dialog, it can handle it.

If you need a proxy use a proxy. If you need a PBX you need a PBX/B2BUA. If 
you need a very scalable system with high load you can scale it with a proxy 
in front of various PBX's (of course, most probably the PBXs won't share 
dialog inforamtion between them...).


  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.


 Our goal is to design something like:
 
 UA -- Opensips -- Our PSTN gateways
 
 That could dynamically turn into, on the fly:
 
 UA -- Opensips -- B2BUA -- Our PSTN Gateway
 
 We haven't found a clean way of doing this, unfortunately...  It may just
  end up being a hack on Opensips 1.6 if that might work.

You shouldn't expect that OpenSIPS could behave as a PBX because it's a proxy. 
And what you need is a PBX, you MUST assume it. A proxy is very scalable, fast 
and so, but it will NEVER provide PBX features (as transferring a call coming 
from a PSTN provider to other user).
IMHO OpenSIPS b2bua module will be useful for some limited tasks (topology 
hidding and others) but not for replacing a PBX.



Regards.



-- 
Iñaki Baz Castillo i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transfer issue

2009-10-23 Thread Alex Balashov 
SEMS is another option for a B2BUA, though all its prebuilt B2BUA apps  
are not pure B2BUA but incorporate some sort of initial media-based  
announcement premise.  But you can use its Python or C++ API to create  
one.

Another option is YATE?

--
Sent from mobile device

On Oct 23, 2009, at 8:07 PM, Iñaki Baz Castillo i...@aliax.net wrote:

 El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió:
 I follow this, but -and please correct me where I'm  
 misunderstanding- isn't
 the point of using a Proxy versus a B2BUA is that it's more  
 lightweight
 and scalable?

 Of course, but if you want PBX features you need a B2BUA. Also,  
 trasferring a
 call from a SIP PSTN provider does require *always* a B2BUA (in fact  
 the user
 doesn't transfer the provider, but the B2BUA which will accept such  
 REFER).



 It seems with this setup every call ends up routed through
 Asterisk on the initial INVITE, simply so that when a REFER  
 potentially
 comes later in the dialog, it can handle it.

 If you need a proxy use a proxy. If you need a PBX you need a PBX/ 
 B2BUA. If
 you need a very scalable system with high load you can scale it with  
 a proxy
 in front of various PBX's (of course, most probably the PBXs won't  
 share
 dialog inforamtion between them...).


 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.


 Our goal is to design something like:

 UA -- Opensips -- Our PSTN gateways

 That could dynamically turn into, on the fly:

 UA -- Opensips -- B2BUA -- Our PSTN Gateway

 We haven't found a clean way of doing this, unfortunately...  It  
 may just
 end up being a hack on Opensips 1.6 if that might work.

 You shouldn't expect that OpenSIPS could behave as a PBX because  
 it's a proxy.
 And what you need is a PBX, you MUST assume it. A proxy is very  
 scalable, fast
 and so, but it will NEVER provide PBX features (as transferring a  
 call coming
 from a PSTN provider to other user).
 IMHO OpenSIPS b2bua module will be useful for some limited tasks  
 (topology
 hidding and others) but not for replacing a PBX.



 Regards.



 -- 
 Iñaki Baz Castillo i...@aliax.net

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users