[asterisk-dev] Start testing with res_sip

[Mark Michelson]

On 06/19/2013 02:11 AM, Ron Arts wrote:
> Hi,
>
> I would like to start testing with using res_sip instead of chan_sip. 
> I looked through
> the documentation but it's very scarce. Is there a configuration 
> example that
> shows a sip,conf, and how to do the same in res_sip.conf for example? The
> current res_sip.conf sample is too minimal.

Brad Latus contributed some XML documentation for res_sip.conf. You can 
access this information from the Asterisk CLI by running "config show 
help res_sip". This will then show you further details you can drill 
down into (e.g. "config show help res_sip endpoint"). with this, you can 
know what configuration options are available to you and get a brief 
explanation for what they do.

>
> I presume chan_sip should not be loaded together with res_sip?

It's actually possible to load both, as long as they each bind to 
different ports. Although, if your goal is to test res_sip, then I'd 
suggest not loading chan_sip just so there's no confusion.

>
> I'd like to start with simply connecting two phones and work from there.
> Can someone give me a helicopter overview?

Sure thing! First, the most important thing to do is to install PJSIP 
properly. See the instructions on this wiki page [1] for some details on 
how it is done. Failing to install PJSIP properly can lead to 
interesting failures during testing.

So let me give a quick overview of configuration. All configuration is 
done in res_sip.conf. There are six configuration object types that can 
be configured in res_sip.conf: endpoint, auth, domain_alias, transport, 
aor, and identify. For the purposes of keeping things simple, we'll only 
examine transport, endpoint, and aor here. Each configuration section 
uses a "type=" line in order to indicate what type of object it is 
configuring.

First, we have the transport type. Transports tell Asterisk what IP 
addresses and ports to bind to, what transport protocol to use, and what 
transport-specific options apply (e.g. TLS certificates). A minimal 
transport configuration would look like this:

[udptransport]
type=transport
protocol=udp
bind=0.0.0.0:5060

That would create a UDP transport named "udptransport" that binds to all 
IPv4 addresses on port 5060. IPv6 is supported as well. Unlike with 
chan_sip, you can configured multiple transports of the same type. So if 
you wished to have two UDP transports on 1.2.3.4 and 5.6.7.8, you could 
configure two transports with the appropriate details.

Next, we have the endpoint type. This is more-or-less equivalent to the 
peer and user types of sip.conf. This is where you configure traits 
about a device that you will be calling. Endpoints have, by far, the 
most configuration options available to them. Here is a very minimal 
configuration for an endpoint:

[bob]
type=endpoint
context=default
allow=ulaw

This creates an endpoint called bob whose incoming calls will be 
directed to the default context and that uses ulaw for audio. You'll 
notice something missing here though. There's no information regarding 
how Asterisk can actually contact bob. That is configured in a separate 
aor type. Here is an example:

[bob]
type=aor
contact=sip:bob at 1.2.3.4:5060

This creates an aor called bob that has a contact URI of 
sip:bob at 1.2.3.4:5060. To have the endpoint bob use this aor, you can 
place an "aors = bob" line in endpoint bob's configuration. There is no 
requirement that an endpoint and aor have the same name, but I have done 
so in this example.

If you configure a transport, two endpoints, and their two respective 
aors, that would be enough to get test calls going. You'd then be able 
to expand on your configuration by adding authentication, registration, 
and all the other bells and whistles you're used to with SIP. Currently, 
the channel driver in use is still chan_gulp, but it is expected to 
undergo a name change to chan_pjsip before the beta is released. In your 
dialplan, you can dial a gulp channel by doing Dial(GULP/bob). With this 
minimal configuration, Asterisk will use the username in the From header 
of incoming requests in order to determine what endpoint the requests 
are coming from.

We expect to have much more thorough documentation on the wiki by the 
time we release a beta around the end of July/beginning of August. In 
the mean time, beware that you are testing against a moving target. If 
you come across some problem, remember that it may be solved if you do 
an svn update. Similarly, understand that an svn update may also may 
invalidate what you have configured (though that's not as likely at this 
stage).

[1] 
https://wiki.asterisk.org/wiki/display/AST/New+SIP+channel+driver#NewSIPchanneldriver-Installingpjproject 


>
> Thanks,
> Ron Arts
>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130619/bdab76e5/attachment.htm>