SECN-1 with Softphone Support

[T Gillett]

Hello All

Based on some excellent work by Keith, I have posted a patch for the SECN-1 firmware that adds support for softphones.

This allows cell phones and PCs running a softphone application such at Sipdroid, Linphone or 3CXPhone to be able to attach to MPs on a network and to make calls to the MPs and to each other.

It is a basic implementation at this stage, but does allow simple use of cell phones to make calls on a network of MP devices.

The patch also includes the web configuration interface and extended IVR commands previously included in Patch01.
Just point your browser to the IP address of the MP.

The latest patch file is Patch-287-02c.tar.gz and is available along with usage notes under the VT web site Downloads tab at:
http://villagetelco.org/download/secn/SECN-1/Patch/

If you have an opportunity to do some testing on this, all feedback is welcome.

It should be considered as experimental, and not for production use at this point.

Regards
Terry

[Giang Nguyen]

Will this feature be supported in SECN-2?  This would greatly improve the usage of the MP in our environment.

Great work again!

[Glen]

Are there any plans with the softphones to allow the Media to be sent to the softphones directly ?

as at the moment all the rtp seems to hairpin on the .252 MP (Master)  which isnt ideal if the Master is a few hops or more away

eg using the map of http://villagetelco.org/wp-content/uploads/2012/03/piracanga.jpeg

Let say MP04 is the Master running the softphone instance

we have a user of softphone300 located at MP33

we have a user of softphone301 located at MP30

if these 2 users were to talk with each over the softphone, all the RTP data would first be sent to MP04, then back again to each SoftPhone, resulting in about 5 Hops on the Mesh when it could of just been going between MP33 and MP30 ? ( assuming that MP04 cant hear MP30, and the mesh doesn't broadcast it)

I think it would also do this if the ATA port of MP33 or MP30 was to call a softphone as it invites 30x@Master_ip_address to route the call if set to Client softphone support

I think the asterisk option may be directmedia=yes to allow the RTP media to flow directly.  But not 100% sure.

[Sjur Eivind Usken]

Are there any plans with the softphones to allow the Media to be sent to the softphones directly ?

you can just set that in Asterisk.

check the following settings (in sip.conf file, either as global variables or on each sip profile)

reinvite = yes 

nat =  no

and the 

directmedia = yes

my asterisk knowledge is a little outdated, but these should do it...

[Keith Williamson]

This is definitely an area we want to investigate for improved
softphone support for SECN2.0. This should work fine for Softphone to
Softphone calls however looks more troublesome for Softphone to MP
calls. I don't believe the MP's ATA entity (UA) was designed to
operate independently of it's local asterisk instance but perhaps
Elektra can comment. In other words, can the MP ATA access the L2 mesh
network like any other SIP client? That would be pretty cool but I
don't think it works that way.

Still the Softphone <--> Softphone calls should be able to use
reinvite to talk peer-to-peer. That has great potential for improving
call quality, and more evenly distributing mesh network load which
should result in improved scalability.

Thanks for opening the topic!

Cheers,

Keith

[Elektra]

Hi Keith -

not sure I understand the problem right.

The IP-to-IP calling feature in the MP dialplan works independently from any server requirement. Same goes for softphones, if they have a independent IP-to-IP dialling feature. All I have to do with a softphone like twinkle is to set up a profile for IP-to-IP calls and dial sip:4000@MP-IP. Same goes for making calls in the opposite direction. The Asterisk extension in the MP initiates a call to sip:4000@Softphone-IP if you dial XXX or XXX*XXX*XXX*XXX, so the caller id configuration in the softphone should be set to 4000.

Calls go directly - so the mesh takes the best routing path and there is no server required. Besides: All versions of BATMAN can route asymmetrically if that is the best option.

As far as I understand, RTP traffic flows directly between the phones. A SIP server is only required to initiate the call. Take a look at this picture:

http://de.wikipedia.org/w/index.php?title=Datei:SIP_signaling.svg&filetimestamp=20111003154001

But I might be missing.

Cheers,
Elektra

[Michel Daggelinckx]

As far as i understand asterisk connects to the ATA part of the MP and
takes care of the calling part.
This basicaly means the ATA part will NOT work unless there is an
asterisk/freeswitch/yate or other telephony engine with support for the
ATA running on the MP.

one solution might be to run a stripped down version of freeswitch which
can scale down to being a "softphone" to make the MP act as a gateway.

this will require a voip server somewhere (preferably inside the mesh)
to connect the gateway to.

Michel

[Keith Williamson]

Hi Elektra,

Yes, the diagram you reference is the correct call flow for SIP UA's calling via a SIP call server. Asterisk is not a SIP server in the pure sense but a B2BUA (Back-to-back User Agent) that receives a call from the originating UA and then places a call to the destination UA, and finally binds the two call legs together. That is, the default behavior of Asterisk is to stay in the call path. It does this for a number of reasons..maintain CDRs for billing, provide transcoding for SIP UAs using different codecs, and providing escape to IVR menus, etc.

That said, Asterisk can be configured to just determine the address and media options (SDP) of the destination SIP device and then provide that information to the originating SIP device in the form of a "re-invite" so that the originating SIP device can then send a new SIP INVITE directly to the destination device thus getting Asterisk out of the RTP path.

We just have never configured Asterisk to do that (AFAIK). The issue I believe we have with the MP, is that the MP is comprised of an FXS and ATA (essentially creating a SIP phone) tightly bound to it's local Asterisk instance via the MP channel driver (which I don't think is IP based). A conventional SIP client connects to Asterisk over a SIP channel instance (which uses SIP and RTP over UDP/IP). So unlike the independent SIP client, I don't think the MP's ATA can connect directly over the network to another SIP device but I could be all wrong here. It depends on how it was architected.

So I imaging we can use reinvite for Softphone <-> Softphone calls but not easily for Softphone <-> MP calls. However, a possibility might still be that while the local Asterisk instance in the MP has to stay in the loop (to provide it's ATA with access to the network), the Asterisk instance on the MASTER device might still be able to get out of the loop if the destination MP Asterisk instance will accept a (re)invite directly from a "foreign" SIP device. All MPs would have to have sip.conf entries for all softphones though. The idea of the MASTER is that it creates one designated Asterisk instance on the SECN network that the Softphones register/authenticate to. If we allowed Softphones to register with any of the many Asterisk instances on the network, how would the originating Asterisk know the address of the Asterisk instance that the destination SIP device is registered to? We would need the SIP equivalent of a tandem switch somewhere on the network that all the Asterisk instances report their client SIP URI's to. So to avoid that mess, I just came up with the idea of a single designated "MASTER" Asterisk that all Softphones would register with and use the SECN mesh as a virtual L2 switch that connects all Softphones to the MASTER. Quick and dirty, it works but as has been pointed out, throws all the Softphone calling load on a single device and puts a heavier load on the mesh routes to that device.

This approach was all based on my study of Asterisk which, like my life long study of German, occurs in fits and starts with much knowledge lost between efforts!

Cheers,

Keith

--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/village-telco-dev?hl=en.

[Keith Williamson]

Elektra,

Re-reading my email, I realized that one more bit of clarification (or muddying?) is needed.

In a pure MP SECN network, calls all go directly from MP to MP. Even if there is an MP configured as MASTER (to support some softphones), the MPs ONLY address calls to the MASTER if the MP is calling one of the softphones. MPs can call MPs directly because each MP has exactly one and only one phone associated with it. So the destination of 4000@MP_IP_ADDR goes to the phone at that IP address.

I just want to assure you that I haven't modified the MP to MP call flow.

With SECN 2.0, hopefully the MASTER's roll will be reduced to call setup for Softphone <-> Softphone and PERHAPS just call setup for MP <-> Softphone.

-Keith

[Glen Steedman]

Hi Keith,

I didn't test calling from the MP(ata) set to client, but im assuming
it just routing calls to ext 30x to 30x@Master_Ip_Address_252
which no doubt would mean the RTP path is from MP Ata, to Master then
back again to the softphone. In cisco speak the Sip Proxy can operate
in media flow around (endpoints directly with RTP) or flow through
(RTP hairpins in the proxy server) Usually the later is used for any
codec conversion, dtmf conversions , security / qos etc etc

so keep with the same example
MP33 ATA calls Softphone 300 , RTP would hairpin all the way to the
Master MP (04 in this example) Rather then staying on MP33 where the
Softphone and ATA are.

Ill do some more testing next week tweaking the media options from
Sjur's post and see what works (and what stays and doesn't stay after
a reboot)

I guess another option could be, if its going to be a static
deployment of SoftPhones you could then hardcode the IP address to the
Softphone, then modify the DialPlan of the MP's to call the IP address
of 300 directly without going through the Master MP ( assuming the
Softphone client will accept a direct sip invite, some may only accept
it from the sip proxy they are registered too)

Cheers, Glen

[Keith Williamson]

Hi Glen, Elektra (and all),

So this turns out to just work (at least as far as my testing went this afternoon). I just changed canreinvite from "no" to "yes" and nat from "yes" to "no" in the two entries in softphone.sip.conf used for my EVO smartphone (running linphone) and my Toshiba tablet (running 3CXphone).

The calls between them worked just great and I verified that the RTP media stream was NOT going through the MASTER asterisk server (in Asterisk console, "rtp set debug on"). Prior to the change, console shows constant stream of RTP packets, after change, RTP packets stop after a few at the beginning of the call.

I also tested calls between MP and softphone and got same result! So it appears that Asterisk on the MP accepts the redirected media stream by default.

Note that I didn't need to set "directmedia=yes" as that's the default setting for that. Will still need to ensure we haven't broken the ability for the softphones to make calls through an external VSP (if configured). If so, there are a few globals we can add to the sip config:

directmediadeny=0.0.0.0/0
directmediaaccept=10.130.1.0/24  /* Change for local network address

This only allows the media to be redirected to p2p if both SIP endpoints are on the local network.

I'll leave it up to others further testing and consensus as to whether we want to sneak this change into SECN1.1 RC3. It would only affect the softphone.sip.conf fixed configuration file.

Cheers,

Keith

[Pascal Laurent]

Keith,

I have an ATA device (HandyTone HT286) connecting to a TL-Link router configured with SECN RC2, I have been struggling to make it work. Any suggestion? 

Thanks,
--P

[Keith Williamson]

Hi Pascal,

You're probably getting burned by the bug I mentioned earlier today.
So..

1) ssh into the TP-Link
2) uci set secn.asterisk.enable_ast="checked"
3) in the advanced tab of the SECN webui, select "MASTER".
4) if the TP-Link is going to be the DHCP server, enable that on the
same tab ensuring that the DHCP parameters are appropriate for your
network
5) hit the "save and reboot" button at the bottom of the webui
6) choose one of the preconfigured sip accounts in /etc/asterisk/
softphone.sip.conf (e.g. softph300). Note the password for the
selected sip entry.
7) configure your ATA device for the above user/authuser/password and
set the SIP server to <your-network-id>.252 (10.130.1.252 by default).
8) connect the ATA to the router via Ethernet (or WiFi if the ATA
supports that)

That should do it. Verify by picking up the phone and dial 2664. If
all is working, you should hear Elektra say "The ethernet IP address
is" followed by Allison reading out the digits of the IP.

Cheers,

Keith

On Apr 7, 6:42 pm, Pascal Laurent <tip...@gmail.com> wrote:
>  Keith,
>
> I have an ATA device (HandyTone HT286) connecting to a TL-Link router
> configured with SECN RC2, I have been struggling to make it work. Any
> suggestion?
>
> Thanks,
> --P
>

> > On Sat, Apr 7, 2012 at 5:39 PM, Glen Steedman <gsteed...@gmail.com> wrote:
>
> >> Hi Keith,
>
> >> I didn't test calling from the MP(ata) set to client, but im assuming
> >> it just routing calls to ext 30x to 30x@Master_Ip_Address_252
> >> which no doubt would mean the RTP path is from MP Ata, to Master then
> >> back again to the softphone. In cisco speak the Sip Proxy can operate
> >> in media flow around (endpoints directly with RTP) or flow through
> >> (RTP hairpins in the proxy server)  Usually the later is used for any
> >> codec conversion, dtmf conversions , security / qos etc etc
>
> >> so keep with the same example
> >> MP33 ATA calls Softphone 300 , RTP would hairpin all the way to the
> >> Master MP (04 in this example)  Rather then staying on MP33 where the
> >> Softphone and ATA are.
>
> >> Ill do some more testing next week tweaking the media options from
> >> Sjur's post and see what works (and what stays and doesn't stay after
> >> a reboot)
>
> >> I guess another option could be, if its going to be a static
> >> deployment of SoftPhones you could then hardcode the IP address to the
> >> Softphone, then modify the DialPlan of the MP's to call the IP address
> >> of 300 directly without going through the Master MP ( assuming the
> >> Softphone client will accept a direct sip invite, some may only accept
> >> it from the sip proxy they are registered too)
>
> >> Cheers, Glen
>

[Keith Williamson]

Oops..left out a step.

After doing the uci set in step 2, do:
uci commit secn

-Keith

[Pascal Laurent]

Keith,

Sure I'll give that a try.

Thanks,
--P