Context setting in [general] section of sip.conf

This is probably a basic question and I am sure someone can explain.
When I use a sip service xyz, I defined a section in extension.com [from-xyz]. it simply detects the extension specified of xyz and routes to the desired phone extensions. The question is: do I need to specify from-xyz in the sip.conf/[general]/context=…, or not. Callcentric suggest to include it but localphone didn’t mention that. localphone and a number of others work without including in sip.conf/[general]/context anyway. However, I have recently tried a sip service which does not work without including the [from-xyz] in sip.conf/[general]/context… (The sections from-localphone and for the other service are almost identical.) I made it work, but do I need always do that?

Yes, but you would normally define it in the specific sip.conf section for the peer.

Please use Asterisk Support for future support requests.

David:
Thanks. I already specified in the [xyz] section of sip.conf. It works for all other services but not this particular one.
Sorry I didn’t realize this is not the place to ask such questions. I will ask in the support forum then.

O.K. Now I am in the support forum.
Let me make clear about my question. There is a section of [xyz-in] defined in extensions.conf. It is also defined as the context in the section for handing out going calls [xyz] in sip.conf.
According to Asterisk specification, is it required to be included in the context of the [general] section of the sip.conf for receiving calls, or not? Home any expert can clarify.

A context specified in a sip.conf section only used for outgoing calls will have no effect, as contexts in sip.conf are only used for incoming calls.

It is quite difficult to write an outgoing section that will not also be used as an incoming one. Asterisk itself doesn’t distinguish.

It is bad practice to rely on the general section for incoming calls. However, if you are dealing with multiple, unregistered, source addresses and have to use allowguest=yes (default, but not normally advised), you will need to specify a context, if it is not default.

Thank you David.
This is what confuses me. In the past, for any sip services that I used, I only need to specify [xyz-in] given in the extensions.conf in sip.conf under the [xyz] section in the sip.conf. However, for this particular sip service, if I don’t specify in sip.conf/[general]/context, I got the following in the asterisk CTL:

[2015-04-10 11:25:58] ERROR[2330][C-0000001f]: chan_sip.c:33204 setup_srtp: No SRTP module loaded, can't setup SRTP session. [2015-04-10 11:25:58] NOTICE[2330][C-0000001f]: chan_sip.c:25621 handle_request_invite: Call from '' (104.236.102.59:5060) to extension '101683' rejected because extension not found in context 'sip-incoming'.
where 101683 is the extension specified in the register statement in the sip.conf for this server and context =sip-incoming is in sip.conf/[general].
If I include xyz-in in the sip-incoming, I got on CTL:

[code] – Executing [101683@sip-incoming:1] Dial(“SIP/104.236.102.59-0000003d”, “SIP/202,60,tr”) in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5

-- Called SIP/202
-- SIP/202-0000003e is ringing
-- SIP/202-0000003e answered SIP/104.236.102.59-0000003d

[/code]
and I can receive the call with no problem. Do you think there’s any issue in the implementation of the service provider side?
Thanks.

You don’t have a sip.conf section matching the IP address of the source of the incoming calls, so they are being processed as anonymous calls. This is usually a bad thing as it removes one line of defence against toll fraudsters. Try and find the IP addresses used as sources, and if there aren’t too many, add sp.conf sections to cover them and then disable allowguest.

David:
I did specified gvgw.simonics.com in the sip.conf in the [gvgw] section.
I found the problem was that they use two ip addresses, which are associated with gvgw10.simonics.com and gvgw11.simonics.com. These two are some how tied together under gvgw.simonics.com. If I did a ping to gvgw.simonics.com, it could reply either one depending on the time of ping. I think somehow my asterisk cannot recognize them if I only specify gvgw.simonics.com in my sip.conf. Maybe there are some strange things going on with their ip address mapping.
Again, thank you very much for your help.
I made this work by adding two peers sections in sip.conf. One for gvgw10 and the other for gvgw11 incoming calls.
Do you think is there anyway this can be fixed in the server side? Just curious.

I got an answer from the service provider, according to him it should work without modification because:

"The DNS settings for the gateway service provide both SRV records and round-robin A records. This should cover all standards-compliant software/equipment (that lookup SRV) and duds that only look up A records (old Asterisk).

The round-robin A will not be a problem and you do not need to specify all the IP addresses as peers. Callls will come in from the specific gateway server to which the client is registered. Is Asterisk looking up its peers separately from its registrars?

As the service grows, the SRV records and round-robin list will contain new hosts. I do not recommend pointing to an individual IP address from the list as they could change. Use gvgw.simonics.com."
However, mine just doesn’t work even if I added “srvlookup=yes” in sip.conf.

Is there anything else I can do to fix this problem?

Asterisk only retrieves one address from those provided by DNS.

Note that people normally want to know the valid address range in order to configure firewalls, so if hte ITSP is providing a service ffor B2B use, one would expect them to volunteer this information.

[quote=“david55”]Asterisk only retrieves one address from those provided by DNS.

[/quote]
Not sure what does this mean. My situation can be summarized as follows.
When I looked online (dig.whois.com.au/dig/gvgw.simonics.com), it shows me two ip addresses. If I put the incoming section [gvgw-in] defined in extensions in the context in sip.conf/[general], the incoming call works. However, if I put it in the context in peer section [gvgw] in sip.conf, the incoming call will not work and shows the error code in CLI as I posted previously.
Do you think this is normal? Obviously Asterisk knows the DNS has two ip addresses other wise it won’t work even if it is included in the [general] section. Then why it won’t work when included in the [gvgw] section?
I asked around and no one had told me this works in the later case yet. (Of course, maybe it worked for someone but who didn’t tell me).

When Asterisk reads sip.conf, it looks up one address for each section with a host specified (it has no concept of ingoing and outgoing sections). When a call comes in for a peer (or for a friend and the from user doesn’t match a section name), it compares the source addresses with the ones obtained above. If one matches, it uses the information in one of the matching sections.

If none match, and allowguest=true, it uses the information in general.

The source address from your ITSP does not match any of the ones it got by looking up the value of host=.

Hi, David:
Thank you for your patience to reply to me. However, I am still confused. To summarize, the ITSP’s DNS ip address is gvgw.simonics.com. If I search it on the web, I got two A records:

TTL 899 Data 45.55.163.124 IP: 45.55.163.124 TTL 899 Data 104.236.102.59 IP: 104.236.102.59
I specified in extensions.conf:

[gvgw-in] exten => 18005551212,1,Dial(SIP/201&SIP/202&SIP/203&SIP/204,60,tr) ; phone must be registered exten => 18005551212,2,Hangup
where 180005551212 is the user extension defined in the sip.conf register statement.
If I put in sip.conf:

[genral] context=gvgw-in .....
I can receive the incoming call to 18005551212. However, if I put it in the peer section [gvgw] in the sip.conf, i.e.,

... [gvgw] ... context=gvgw-in ...
and in the [general] section I put “context=default”, I cannot receive the call. The CLI always says "… call was rejected because extension not found in context ‘default’.
Is this normal? If it is not what might be the cause.
Hope I am express the problem clear and sorry for keep bothering you.

Edit:
I tried my callcentric DID. cc has many ip addresses under callcentric.com. The result is the same, the incoming call section cc-in must be included in the context in sip.conf/[general] section for receiving the incoming call. It won’t work if it is only included in the [cc] section but not in the [general] section. I just don’t know if it is by design of Asterisk, or not.

What is the actual source address for the call (use sip set debug on). If it is one of the two A record addresses, you will need two incoming sections, both with explicit IP addresses, or you will have to continue using allowguest. If it is not one of the two , no amount of DNS lookup will help.

David:
This is what I understood also. Thank you very much for your help.
I just wish Asterisk can catch all of the ip addresses even if the DNS is specified in the peer section. I am not sure why it is not done this way but I don’t know much about Asterisk, just user, anyway.