Loading ...
Sorry, an error occurred while loading the content.

Re: call transfer problem with asterisk

Expand Messages
  • v0bza
    First of all, blind tranfer is working, don t know why it was a problem last week. I can t reproduce it any more. The second is, I catched something
    Message 1 of 15 , Dec 4, 2007
    • 0 Attachment
      First of all, blind tranfer is working, don't know why it was a
      problem last week. I can't reproduce it any more.

      The second is, I catched something interesting concerning "transfer
      with consultation".

      The scenario: phone1 calls phone2 (twinkle), phone2 speaks with
      phone3 and transfers the call to.

      What we are awaiting:

      phone1 -> phone2 INVITE (calling and talking)
      phone1 <- phone2 INVITE (place phone1 on hold)
      phone3 <- phone2 INVITE (proxy)
      phone3 <- phone2 INVITE (calling and talking to phone3)
      phone3 <- phone2 INVITE (place phone3 on hold)
      phone1 <- phone2 REFER (phome1 and phone3 are talking)
      ....... some other things .......

      twinkle doing:

      phone1 -> phone2 INVITE (calling and talking)
      phone1 <- phone2 INVITE (place phone1 on hold)
      phone3 <- phone2 INVITE (proxy)
      phone3 <- phone2 INVITE (calling and talking to phone3)
      phone3 <- phone2 BYE (disconnect from phone3)
      phone1 <- phone2 REFER (returning 486 "Busy Here")
      ....... some other things .......

      I think, it's a bug. I'm not a SIP professional, but as I see, it
      can't working with BYE on this place...

      P.S. How can I send logs (<60k) (if somebody wish to look at)? I did
      this with sip debug in asterisk.

      rgds
      Vova

      --- In twinklephone@yahoogroups.com, joerg <joerg.twinklephone@...>
      wrote:
      >
      > Am Fr 30. November 2007 schrieb v0bza:
      > > I'm not sure, is it the same problem or not?
      > me either.
      >
      > > As I can see, asterisk
      > > 1.2.X has a problem with understandig of new twinkle 1.1 behavior.
      > I didn't learn yet to read * logs, and i had no time so far to
      analyze the
      > twinkle.log of yesterday's problem with call forward so far. Anyway
      there was
      > good reason my forward failed, however twinkle does not recover
      gracefully,
      > but instead does not show error msg, and freezes on next call (or
      about sth
      > like that)
      >
      > > I'll try to compare twinkle and asterisk logs on this WE. Probably
      > > I'll find something.
      > Fine! :-) let us know
      >
      > >
      > > P.S. I'm not waiting for a quick answer :-) It's not a fatal
      > > problem. :-)
      > Right, not fatal, but severe - at least in my case when freezing.
      > Anyway Michel announced next twinkle activities for January at the
      earliest.
      >
      > j
      >
    • olivier_aufrere
      just to say that I have the same pb with twinkle 1.0.1 and asterisk (transfer with consultation does not work properly). (I didn t update to 1.1 when I saw
      Message 2 of 15 , Dec 4, 2007
      • 0 Attachment
        just to say that I have the same pb with twinkle 1.0.1 and asterisk
        (transfer with consultation does not work properly).
        (I didn't update to 1.1 when I saw jeorg's post)

        Sorry but I have no time to make some test at this moment. So I only
        use blind transfer.

        Hope you will solve it. When I can spend some time on it, I will tell you.

        Olivier
      • joerg
        ... That s exactly the way it behaves when my error with transfer occurred - well, got no 486. After this, a 3way-conf crashed twinkle. Let s see if Michel can
        Message 3 of 15 , Dec 4, 2007
        • 0 Attachment
          >
          > twinkle doing:
          >
          > phone1 -> phone2 INVITE (calling and talking)
          > phone1 <- phone2 INVITE (place phone1 on hold)
          > phone3 <- phone2 INVITE (proxy)
          > phone3 <- phone2 INVITE (calling and talking to phone3)
          > phone3 <- phone2 BYE (disconnect from phone3)
          > phone1 <- phone2 REFER (returning 486 "Busy Here")
          > ....... some other things .......
          >
          > I think, it's a bug. I'm not a SIP professional, but as I see, it
          > can't working with BYE on this place...
          That's exactly the way it behaves when my error with transfer occurred - well,
          got no 486. After this, a 3way-conf crashed twinkle.
          Let's see if Michel can find the time to drop a short note on this. I'm no
          SIP-pro too, at least when it comes to REFER.


          >
          > P.S. How can I send logs (<60k) (if somebody wish to look at)? I did
          > this with sip debug in asterisk.
          you always may upload logs to the file section of this forum. Real short logs
          may be included inline to a post (imagine you had to read this post via
          web-frontend on your iphone ;-), though these often are crippled by yahoo's
          editor/web-frontend. Usually when asked to send a log, you should send it to
          PM of the person who asked you.

          btw: could you send to me the twinkle.log file of such a fail described by
          you? Best with a successful blind transfer in it at first too, for reference
          purposes.


          @Olivier: there's nothing wrong with 1.1 (except the same transfer code as in
          1.0.1, if this code is buggy), you may update any time. Just be aware there's
          been a rather short period when old twinkle binaries were not compatible to
          new openSUSE-10.3 - this is fixed now. Also when you build from src, there
          should be no problem anyway.

          cheers
          jOERG
        • joerg
          some few days ago i wrote a micro-howto on transfer and forward. Though i would have preferred to have this checked by a real SIP-expert before posting
          Message 4 of 15 , Dec 5, 2007
          • 0 Attachment
            some few days ago i wrote a "micro-howto" on transfer and forward. Though i
            would have preferred to have this checked by a real SIP-expert before posting
            potentially silly things, i now made up my mind to ask for comments here in
            this thread.
            So here it is:

            ------------------- (c) jOERG ---------------------
            Independent of your actual "problem", there are some facts special to SIP call
            forward and call transfer, which are worth to note.

            *** How call forwarding is done on usual phonelines?
            1.) Alice calls Bob, both are on conventional landlines (or cellphone):
            A ---> B
            in fact it's a little more complex, e.g. it might be as complex like this:
            A --(A's Telco AT)--> [AT/BT gateway] --(B's Telco BT)--> B

            2.) Now Bob goes having lunch. He configures his line to forward all calls to
            Cesar's Restaurant:
            A ---> ((B)) --(forwards)--> C
            again the true story is more complex - B is telling BT to forward calls:
            A --(A's Telco AT)--> [AT/BT gateway] --(B's Telco BT)
            \__--> C
            obviously the way segment BT-->C is due to Bob's commands, and so BT will
            charge Bob for this connection. Usually at least same fee like a normal call
            Bob to Cesar's.

            *** How call forwarding is done on SIP?

            3.) Now let's see how things change when Alice and Bob both use twinkle.
            When Alice calls Bob, and they both are customers of SIP-Provider Acme SPA:
            A -invites-> [SPA] -invites-> B
            INVITE (a SIP message to start a call) asks B to talk to A, and when call is
            established, A and B have _direct _ connection via internet.
            A <--(internet)--> B
            That's why true SIP calls between SIP-phones usually are free of charge.
            (when you are using a "direct IP to IP" setup, you don't need SPA to initiate
            the call. Each phone knows how to reach the other end directly via it's
            IP-address - therefor the name. NB: even with directIP2IP, SIP forward and
            transfer are supposed to work!)

            4.) Bob goes to lunch again. He configures twinkle (not SPA!) to forward all
            calls. Whats happening when Alice calls Bob:
            A -invites-> [SPA] -invites-> B
            Bob's twinkle tells he's out for lunch, and Alice should call him at Cesar's:
            A <-refer- [SPA] <-refer- B
            now if Alice has configured her twinkle accordingly, it will ask her to allow
            call forward to Cesar's. Then twinkle A stops the call to B, and starts new
            call to C
            A -invites-> [SPA] -invites-> C
            You notice, this is quite different to the way a call forward is set up in
            other telephone networks we seen in 2.)

            5.) In 3.) and 4.) the sketch was for Cesar's is a SIP-phone, too. Now let's
            assume C is a normal landline. When Bob asks for a table at Cesar's, the
            established call, after INVITE etc, has to go through a
            SIP-to-landline gateway provided by SPA:
            B --internet-> [SPA SIP to landline GW] --PlainOldTelephoneSystem--> C
            The "last mile" from SPA-GW to C is Cesar's Telco, ususally different to SPA.
            So SPA has to pay to C's Telco, and that's why SIP calls to landlines usually
            are NOT for free. In the end these gateways are the cashcow for most of the
            SIP-providers.
            Now when A calls B, and B tells A to call C - like in 4.) - then obviously
            Alice (NOT Bob, like in 2.) has to pay fee for the "last mile" from SPA-GW to
            C (note: SPA here is meant to be A's provider, not B's)
            A --internet--> [SPA GW] --POTS--> C
            That's why twinkle may be configured to ask you, before your call is
            forwarded - you have to pay for it.


            *** But it does not work! Why?
            There are couple of reasons for any SIP call to fail. And some more for
            transfer and forward. It's easy to see:
            - A has to allow forward. If Alice's SIP-phone does not know how, or refuses
            to handle refer, there will be an error but no call.
            - When a landline caller C is calling a SIP-phone, the call has to pass a
            gateway too:
            C --PlainOldTelephoneSystem--> [SPA landline to SIP GW] --(internet)--> B
            Anyway if the destination to forward the call to is POTS too or of unknown
            type, B can NOT ask C to stop the call and start a call to A instead - the
            POTS does not know how to do that (how should a rotary dial phone ask you for
            allowance to forward the call?). So call forward and call transfer regularly
            will fail, when the call origin is no SIP-phone - unless the SIP-provider
            takes special messures to relay forward the call (POTS->SIP->POTS) and charge
            the forwarding user for it.
            Or the gateway is smart enough to see, when forward destination A is a
            customer of same provider as B, so the call won't leave the SIP-"area" when
            forwarded. The forward destination usually has to be a valid SIP-address for
            this to work, not a simple phone-number.
            I should say that i did not hear yet of any provider supporting any of these
            both ways to forward a POTS-origin call via twinkle.
            Also all i'm telling here is no result of professional education or serious
            study, but only is what i learned the last few years by reading twinkle's
            logs and helptexts. Comments welcome (mail to joerg DOT twinklephone AT gmx
            DOT de)!

            In this short explanation i mostly talked about call forwarding. Though
            somewhat more complex, call transfer in both it's flavors "unattended"
            and "attended" is the same as call forward for the aspects discussed herein,
            for SIP as well as landline or cellphone.
            ------------------- (c) jOERG ---------------------
          • olivier_aufrere
            it s quite interesting, but much more complicated than what we are looking for. In our case (asterisk), the sip provider is not the way: This is (only) what I
            Message 5 of 15 , Dec 6, 2007
            • 0 Attachment
              it's quite interesting, but much more complicated than what we are
              looking for.

              In our case (asterisk), the sip provider is not the way:

              This is (only) what I understand of the way asterisk works:
              ex landline incoming call (or what ever call):
              The call arrives as inbound route.
              Asterisk routes it too a SIP extension.
              80% of the calls tranfers are too another extension of asterisk.
              So we only tranfer too a SIP asterisk extension.

              I let you translate it into SIP and hope some asterisk users (that
              really know how asterisk works) will correct what I wrote.

              regards
              olivier

              PS: blind transfer really works fine (except if the extension is on hold)
            • joerg
              Hi Olivier, many thanks for your remarks! ... you are right, what i described is not related to the actual issue of failing attended transfer, and i know it s
              Message 6 of 15 , Dec 6, 2007
              • 0 Attachment
                Hi Olivier,
                many thanks for your remarks!

                Am Do 6. Dezember 2007 schrieb olivier_aufrere:
                > it's quite interesting, but much more complicated than what we are
                > looking for.
                you are right, what i described is not related to the actual issue of failing
                attended transfer, and i know it's a little OT in this thread. It was
                intended as a background info of it's own right, dealing with (bugfree)
                forward&transfer. However with this info you may acquire understanding of the
                process of call transfer in SIP. This process is inherent to SIP and
                independent of the owner of any asterisk involved. Provider Sipgate e.g. is
                using asterisk too (for some of the tasks of a provider, though not for
                gateway function).
                At least you may see why i'm not even able to test a successful blind
                transfer: i have exactly one SIPphone and NO asterisk running, so ALL my
                farends are POTS for testing purposes.

                >
                > In our case (asterisk), the sip provider is not the way:
                >
                > This is (only) what I understand of the way asterisk works:
                > ex landline incoming call (or what ever call):
                > The call arrives as inbound route.
                > Asterisk routes it too a SIP extension.
                > 80% of the calls tranfers are too another extension of asterisk.
                > So we only tranfer too a SIP asterisk extension.
                So this may be considered as: you are your own provider and asterisk serves as
                your landline to SIP gateway. No real difference to scenario described in my
                prev. post, though might be even _more_ complicated when you are running
                external SIP with your asterisk instead of a landline.

                >
                > I let you translate it into SIP and hope some asterisk users (that
                > really know how asterisk works) will correct what I wrote.
                You are completely right. In your case asterisk has to know (=correct config)
                how to handle the transfer from one extension to another. From extension's
                (twinkle) point of view, there is no difference between asterisk acting as
                a "SIP-proxy" gateway for the landline FE, and any UA SIP-farend.

                >
                > regards
                > olivier
                >
                > PS: blind transfer really works fine (except if the extension is on hold)
                Probably the parenthesis note is right to the point! Attended transfer allways
                puts the call on hold.

                cheers
                j
              • joerg
                ... ****** music on hold?! so FE _is_not_really_ put on hold at all!? maybe that s reason for your 486 busy here - source FE may not off hold destination
                Message 7 of 15 , Dec 6, 2007
                • 0 Attachment
                  Am Fr 30. November 2007 schrieb v0bza:
                  > Hello Michel
                  >
                  > very many thanks! But I think, the problem has a tchnical background.
                  > Here is the asterisk log with twinkle 0.9 (extension 2000):
                  >
                  > Nov 9 14:08:05 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > NoOp("SIP/5324501-08af6000", ""XXXXXXXX" <XXXXXXXX>") in new stack
                  > Nov 9 14:08:05 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Dial("SIP/5324501-08af6000", "SIP/2000|20|tT") in new stack
                  > Nov 9 14:08:05 roo asterisk[432]: VERBOSE[432]: -- Called 2000
                  > Nov 9 14:08:05 roo asterisk[432]: VERBOSE[432]: -- SIP/2000-
                  > 08b00000 is ringing
                  > Nov 9 14:08:14 roo asterisk[432]: VERBOSE[432]: -- SIP/2000-
                  > 08b00000 answered SIP/5324501-08af6000
                  > Nov 9 14:11:19 roo asterisk[432]: VERBOSE[432]: -- Started music
                  > on hold, class 'default', on SIP/5324501-08af6000
                  > Nov 9 14:11:26 roo asterisk[432]: VERBOSE[432]: -- Stopped music
                  > on hold on SIP/5324501-08af6000
                  > Nov 9 14:11:26 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, 2001, 0) exited non-zero on 'SIP/5324501-08af6000'
                  > Nov 9 14:11:26 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Dial("SIP/5324501-08af6000", "SIP/2001|60|tT") in new stack
                  > Nov 9 14:11:26 roo asterisk[432]: VERBOSE[432]: -- Called 2001
                  > Nov 9 14:11:26 roo asterisk[432]: VERBOSE[432]: -- SIP/2001-
                  > 08ae7000 is ringing
                  > Nov 9 14:11:30 roo asterisk[432]: VERBOSE[432]: -- SIP/2001-
                  > 08ae7000 answered SIP/5324501-08af6000
                  > Nov 9 14:16:49 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, 2001, 1) exited non-zero on 'SIP/5324501-08af6000'
                  > Nov 9 14:16:49 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Hangup("SIP/5324501-08af6000", "") in new stack
                  > Nov 9 14:16:49 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, h, 1) exited non-zero on 'SIP/5324501-08af6000'
                  >
                  > and that's a new one with twinkle 1.1 and blind (unattended)
                  > transfer, here are the CDRs too, it probably better explains the
                  > problem
                  >
                  > Nov 30 15:37:16 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > NoOp("SIP/5324501-08efd000", ""XXXXXXXX" <XXXXXXXX>") in new stack
                  > Nov 30 15:37:16 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Dial("SIP/5324501-08efd000", "SIP/2000|20|tT") in new stack
                  > Nov 30 15:37:16 roo asterisk[432]: VERBOSE[432]: -- Called 2000
                  > Nov 30 15:37:17 roo asterisk[432]: VERBOSE[432]: -- SIP/2000-
                  > 08fba000 is ringing
                  > Nov 30 15:37:22 roo asterisk[432]: VERBOSE[432]: -- SIP/2000-
                  > 08fba000 answered SIP/5324501-08efd000
                  > Nov 30 15:37:40 roo asterisk[432]: VERBOSE[432]: -- Started music
                  > on hold, class 'default', on SIP/5324501-08efd000

                  ****** music on hold?! so FE _is_not_really_ put on hold at all!? maybe that's
                  reason for your "486 busy here" - source FE may not "off hold" destination
                  FE, cause it's not at all in hold state, but "talking music" instead. Music
                  is a plain established active call, i guess (might be some PRACK issues
                  there. I don't know by heart).
                  Just an idea...

                  > Nov 30 15:37:53 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Dial("SIP/2000-08fb4000", "SIP/2001|60|tT") in new stack
                  > Nov 30 15:37:53 roo asterisk[432]: VERBOSE[432]: -- Called 2001
                  > Nov 30 15:37:53 roo asterisk[432]: VERBOSE[432]: -- SIP/2001-
                  > 08fd2000 is ringing
                  > Nov 30 15:37:55 roo asterisk[432]: VERBOSE[432]: -- SIP/2001-
                  > 08fd2000 answered SIP/2000-08fb4000
                  >
                  > ==> /var/log/asterisk/cdr-csv/Master.csv <==
                  > "","2000","2001","anrufen","""2000"" <2000>","SIP/2000-08fb4000","SIP/
                  > 2001-08fd2000","Dial","SIP/2001|60|tT","2007-11-30 15:37:53","2007-11-
                  > 30 15:37:55","2007-11-30 15:37:57",4,2,"ANSWERED","DOCUMENTATION"
                  >
                  > ==> /var/log/asterisk/messages <==
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, 2001, 1) exited non-zero on 'SIP/2000-08fb4000'
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Hangup("SIP/2000-08fb4000", "") in new stack
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, h, 1) exited non-zero on 'SIP/2000-08fb4000'
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Stopped music
                  > on hold on SIP/5324501-08efd000
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, 2001, 0) exited non-zero on 'SIP/5324501-08efd000'
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Dial("SIP/5324501-08efd000", "SIP/2001|60|tT") in new stack
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Called 2001
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Got SIP
                  > response 486 "Busy here" back from 192.168.88.151
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- SIP/2001-
                  > 08fb1000 is busy
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: == Everyone is
                  > busy/congested at this time (1:1/0/0)
                  > Nov 30 15:37:57 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Busy("SIP/5324501-08efd000", "") in new stack
                  >
                  > ==> /var/log/asterisk/cdr-csv/Master.csv <==
                  > "","020187818535","5324501","von-
                  > provider","""XXXXXXXX"" <XXXXXXXX>","SIP/5324501-08efd000","SIP/2001-
                  > 08fb1000","Busy","","2007-11-30 15:37:16","2007-11-30 15:37:22","2007-
                  > 11-30 15:38:06",50,44,"ANSWERED","DOCUMENTATION"
                  >
                  > ==> /var/log/asterisk/messages <==
                  > Nov 30 15:38:06 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, 2001, 102) exited non-zero on 'SIP/5324501-08efd000'
                  > Nov 30 15:38:06 roo asterisk[432]: VERBOSE[432]: -- Executing
                  > Hangup("SIP/5324501-08efd000", "") in new stack
                  > Nov 30 15:38:06 roo asterisk[432]: VERBOSE[432]: == Spawn extension
                  > (anrufen, h, 1) exited non-zero on 'SIP/5324501-08efd000'
                Your message has been successfully submitted and would be delivered to recipients shortly.