Callback Application

New features you'd like see on SIP Sorcery
Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Mon Aug 18, 2008 11:18 am

Hi All,

The Callback application has reached a complexity level where we're going to need a proper design in order to understand it from an implementation point of view and also to understand the limitations from a user point of view.

Below is a SIP flow diagram with explanations for my current understanding of what a few people have expressed as their desired behaviour. I could have missed or misunderstood something or there may be a better way to do it. If you have any ideas as such please post them.

Image

1. An incoming call arrives at mss and initiates a Callback. The first leg of the Callback is established with Provider 1,

2. The second leg of the Callback is established with a Media server capable of decoding DTMF. The call leg from step 1 and the Media server call are re-Invited to each other,

3. Two RTP packets are spoofed, one each from either end of the call created in step 2. This is in case either end of the call has a private IP address in its SDP,

4. The Media server will read the DTMF from the user and when completed send a REFER request back to mss. mss will process the REFER request in the same manner as a normal call,

5. The desintation specified in the REFER request from step 4 results in a call being created to Provider 2,

6. The calls with Provider 1 and Provider 2 are re-Invited to each other,

7. Two RTP packets are spoofed, one each from either end of the call created in step 6. This is in case either end of the call has a private IP address in its SDP.

The main point of weakness in this approach is the spoofed RTP. In particular if step 6 resulted in both legs of the call being on private IP addresses, which is likely if the legs are SIP accounts registered with mss, then it would not be possible to establish any audio at all.

If the end points of the calls will always be public IP based SIP providers then the RTP spoofing could probably be dispensed with and I think the application would become a lot more reliable.

The question is whether the main use for the Callback application is likely to involve SIP accounts registered with mss or whether it will always be between two termination providers?

Regards,

Aaron

elwebmaster
Posts: 20
Joined: Mon Jul 07, 2008 9:48 pm

Post by elwebmaster » Mon Aug 18, 2008 6:51 pm

Aaron wrote: The question is whether the main use for the Callback application is likely to involve SIP accounts registered with mss or whether it will always be between two termination providers?
Why would someone want to use callback with a SIP account? As far as I understand most people need Callback in order to get cheap calling from their cellphones, I've not really heard of any other use for Callback. Unless someone has an account at MSS forwarded to a PSTN, but even in that case they can use a workaround (with a voxalot account between the callback and the forwarding MSS accounts). I believe the application will work just fine even if it doesn't support MSS accounts as part of the process.
Your diagram seams fine, that's how it's implemented at liberailvoip (at least from user point of view).
I would just ask you to please keep the way callback works right now alive as well, so people can choose between using the old method or the new application with the media server. Sometimes the old method is more useful: you can predefine the two legs of the call, then you just give the number to a friend, they call and hang up, the system calls them and connects them to you, you don't need to explain anything about punching in numbers or whatever, I believe it also has advantages even though it's not as flexible as the new application.

jack9901
Posts: 277
Joined: Tue Jan 29, 2008 7:30 pm

Post by jack9901 » Mon Aug 18, 2008 8:58 pm

Hi Aaron,

I think that's the way to go and as elwebmaster said, a real callback will have at least one leg to PSTN which has a provider on public IP. There is no reason to use callback if two legs are both SIP accounts with private IP's that have good internet connection.

And to elwebmaster,

If I understand it correctly, the new application shall not break the "old" way sys.Callback works. The only difference is that, with the "old" way, you meant sys.Callback(first_number, second_number), whereas the new application is sys.Callback(first_number, 306@194.213.29.54:5061) which is merely one application of sys.Callback with one leg to help you to key in some numbers.

Regards,
Jack

emoci
Posts: 127
Joined: Mon Aug 20, 2007 11:27 pm

Post by emoci » Mon Aug 18, 2008 8:58 pm

Aaron when you say: "if the legs are SIP accounts registered with mss"

By SIP accounts, you mean MySiPSwitch accounts to which an ATA is registered, or does it also include third party SIP Providers that have been set up in MSS for Incoming/Outgoing calls?

In any case, I think it would be useful to keep the current callback method and split the new method into its own module (or at least I'm splitting them up for the sake of explaining):

So

sys.Callback
-Support connecting two call legs that are Phone Numbers via VoIP providers
-Support connecting two call legs, where either both or one of legs are SIP URIs
-Support connecting two call legs where one of the legs is a MySipSwitch acct.

(I believe you've already added all of the above features into the current callback method)

sys.CallbackMedia

For the first leg of the call:
-Support connecting two call legs where the first is a phone number (connected via a VoIP provider configured in MSS)
-Support connecting two call legs where the first is a SIP URI (that said, I don't see any usefulness or applicability to this)
-Support connecting a call leg where one is a MySipSwitch acct. (this also seems pointless, if you're already connected to MSS, why would you want to use CallBack)

Original Second Call Leg:
-Support connection to Media Server to collect DTMF

Refered second call leg:
-Support reaching a Phone Number dialed via an MSS configured provider (or better yet if possible treat this as an outgoing call from the MSS acct. hence making use of the Outgoing DialPlans in MSS as well)
-Considering only numbers are supported by the Media Server, it appears pointless to deal with connecting to SIP URIs, or other MSS accts. here

jvwelzen
Posts: 716
Joined: Thu Sep 11, 2008 1:56 pm

Post by jvwelzen » Mon Feb 23, 2009 4:13 pm

Is this working already

I am trying to get it work but it seems not to callback at all

Is there something wrong in what i am trying to do

this is my code tot test

Code: Select all

#Ruby 

## New processing block for MESSAGE requests. 
if req.Method.ToString() == "MESSAGE".ToString() then 

sys.Log("message=#{req.Body}") 
sys.Callback("0357110469@huizenwireless.nl", "#{req.Body}@huizenwireless.nl") 

else 

## Put your existing Ruby dial plan here. 
  if sys.In               # If incoming call... 

    name = req.Header.From.FromName.to_s     # create a copy of FromName 

    # if FromName isn't empty and isn't all digits (caller's phone #) 
    # replace it with username from caller's URI 

    name = req.Header.from.FromURI.User.to_s if name =~ /^$|\D/ 

    # Prefix 10-digit numbers with "1" (US country code). 
    # Some DID send Caller ID without country code 
    # Change FromURI.User, too - or else Bria won't find contact in its phonebook! 

    req.Header.from.FromURI.User = name = ('1' + name) if name =~ /^[2-9]\d{9,9}$/ 
 
    sys.Log("FromName: '#{name}'") 
    req.Header.From.FromName = name    # Set FromName for sys.Dial 

                    # If my ATA is registered 
    sys.Dial("#{sys.Username}@huizenwireless.nl", 38)   # forward all incoming calls to it afther 33 seconde forward to voicemail
   
    sys.Log("#{sys.Username} is not online. or not picking up") 
    sys.Respond(486, "#{sys.Username} Not online") 
  else 
  end
## The forward to get the MESSAGE request with the number generated is. 
sys.Dial("306@194.213.29.54:5061") 

end

AviMarcus
Posts: 153
Joined: Sun May 16, 2010 7:07 am

Re: Callback Application

Post by AviMarcus » Sun Jun 20, 2010 8:45 pm

Cool. The 306@.. application still works. But I'm not seeing anything in my console log for the req.Body or even req.Method
How would I use this?
Help document SIP Sorcery on the wiki!
If you solved an issue you were having or figured out how to do something, please share on the wiki! It will save everyone lots of time and frustration.

Post Reply