[asterisk-dev] chan_sip protocol questions

[Grey Man]

Hi Steve,

I am not the person to provide authoritative answers to your questions
but I do have some comments.

On Fri, Oct 24, 2008 at 10:25 AM, Steve Davies <davies147 at gmail.com> wrote:
> 2) It there any reason why per-peer fromuser and fromdomain are not
> used in OPTIONS peer-poke packets? It seems that there is a specific
> override to cause it to default to global-fromuser and
> global-fromdomain in sip_alloc(). More generally, why would we ever
> NOT use per-peer fromuser and fromdomain when we are sending data in a
> peer context?

As far as I understood the purpose of the OPTIONS request Asterisk
sends is to try and keep NAT connections alive and to provide a way
for Asterisk to determine if a registered SIP device has dropped off
without un-registering, such as would happen with a network failure.

As the number of SIP accounts registered with an Asterisk server
builds up the volume of OPTIONS requests being sent can get very high
very quickly and on my systems I removed this whole function along
with registration from Asterisk at around 1000 registrations.

If there was a lot of processing involved with the responses to those
OPTIONS requests by Asterisk (I'm not sure what there is at the
moment) then it could start to affect the important stuff like getting
the RTP through. And if the OPTIONS response are not being processed
except to say that if a response is received the SIP device is alive
then the I would think it's reasonable to just send a generic OPTIONS
request to the socket the registation came from rather than put more
effort into generating a specifically tailored request for every
device.

In summary I would recommend careful consideration be given to adding
extra processing to the Asterisk OPTIONS mechanisms. A lot of SIP
implementations actually recommend against using OPTIONS request for
keep-alive pruposes due to the extra load they impose on SIP elements.
Devices like the xten softphone instead send 4 byte null packets which
have the affect of keeping NAT connections alive while incurring
negligible load on the SIP server.

> 3) As I understand the RFC, a REGISTER has 2 purposes. One to say "I
> am here" in terms of IP address, and one to say "I have the following
> numbers (URIs) that I can handle for you". First I have found an ITSP
> who really does not like the asterisk default of "s at ip-address" in the
> Contact: header. Strictly speaking, they want to see either no contact
> header at-all, or a contact-header for each DDI on the account. What
> they want is completely reasonable within my reading of the RFC. Is
> "s at ip-address" necessary for some application, or is it just a random
> asterisk default?

I've never heard of registrations being used the second purpose you
mention. A REGISTER request sends a Contact header with the network
address that the registering account can be reached on. While the
Contact URI can include parameters there is certainly nothing in the
SIPv2 standard that maps such parameters to handling of specific DIDs.

It's entirely up to the Registrar (or Location server using the
Registrar's records) as to how to make use of the contact URIs and
that includes any DID mappings to SIP accounts. The default Contact
Asterisk uses of s at ipaddress is a bit strange relative to other user
agents but it's perfectly valid. Although I have seen it cause quite a
few users problems due to not having an s extension set up in their
extensions.conf but that would be the case for whatever defualt
extension was used.

Regards,

Greyman.