Inbound OPTIONS are of no interest. If you have a problem, you need the debug output for an INVITE or REGISTER.
By the way dogwatch should be watchdog. Outbound, these are used by Asterisk to implement the qualify option.
It is, I guess, possible, that the other switch considers the link down, because it is getting errors back for the OPTION methods. It is possible that Asterisk is failing to match them against any sip.conf entry - I’d need to read the code to see exactly when it sends Not Found for OPTIONS. Even in that case, turning off the function on the other side should be enough.
Yes. 404 is generated if there is no sip.conf match, i.e. you don’t have a friend or peer with 172.20.116.13 in its host field. The Contact header is empty, which means you probably can’t have a user match.
there is not so much an issue from what your showing.
asterisk is constantly sending options, with an ‘unknown’ sender - you probably have qualify=yes in your host definition. set it to no and it will reduce drastically. alternatively, as we dont have the ips, it could be the oxe sending these. no big deal either.
you need to look at what’s happening when you initiate the call… option can be sent at that time, but that doesnt matter. if you see no invite reaching Ast, then either none are sent, or they are blocked by a fw somewhere (iptables on your ast ?)
as the alcatel is sending options to your asterisk, it means network is fine.
either, as david said, the oxe is confused by the answer to the option being 404 (should not, but who knows with alcatel), or the config of the alcatel is incomplete / incorrect
strange thing is, that i had a server with asterisk 1.6 with the same trunk configuration - and the trunk worked fine.
today I replaced the server with a new server running 1.8.4.2 and gave him the IP of the old one.
So @Alcatel - nothing was changed. and the trunk-config @asterisk is exactly the same:
Asterisk has no concept of SIP trunks; that’s imposed by the GUIs.
If the Alcatel is unchanged, the difference has to be in the reaction to OPTIONS. It is possible that there has been a change in the handling of the Alcatel’s protocol violation in sending an empty addr-spec in the Contact header:
hi,
what do you mean with “problem function” a special function or just a function which could make the problem?
The change chould be in the chan_sip.c, right?
Do you have an idea where it could be? It is my first time looking in the source code - and comparing the files is not really the best way for finding the change…because there are a lot of changes…
There is likely to be some option on the Alcatel similar to the qualify option in Asterisk. Try finding it and disabling it.
The basic starting point in chan_sip.c is handle_request_options, however the change is most likely to be in the find peer logic that this calls.
You can look through the SVN logs to see if any change might cause a problem. If you have a good idea where the code change is, you can use svn blame to get a revision number and then locate the log entry, and possibly the issue report, that generated that change. With the revision number, you can get the complete change set that was applied.
hey guys,
does anybody of you has the possibility to have a deeper look in the sourcecode concerning that problem?
Unfortunately I don’t find something in there!
Hi Malte, I am an ACSE and I have in my lab an Asterisk box v 1.8.4.4 connected to OXE v. 9.0 patch 50a. Everything are working fine, in both direction. Can you post a Alcatel configuration? I mean, which type of Trunk group are you using? ABC-F or ISDN ? ( of course, type SIP ).
Please post External Gw config.
Hey Spady,
it’s really great to hear from you, that it should be working. And it is also really great that we can compare the configruation right now:
MY OXE version seems to be Patch 50. I hope that the “a” is not the problem here! Unfortunately I’m not able to patch the OXE, but I could ask our service provider for doing that.
My Asterisk version ist 1.8.4.2. Perhaps I should patch the Asterisk!
Here is my GW-Config:
SIP External GW ID: 2
GW Name: Asterisk-Test
SIP remote domain: IP of asterisk server
SIP Port number: 5060
SIP Tranport Type: UDP
Registration Timer: 0
Super Vision Timer: 10
Trunk Group Number: 13
Pool Number: -1
RFC 3325 supported by the distant: Checked
DNS Type: DNS A
Mini auth mode: SIP None
Dynamic Payload Type for DTMF: 97
Trunk group settings:
Q931 signal variant: ABC-F
SS7 signalling variant: No Variant
Number compatible with: -1
Number of digits to send: 0
Channel selection type: quantified
Remote Network: 13
Auto.DTMF…: YES
T2 Specification: SIP
Homogenous network for direct RTP: No
Public Network COS: 2
Special Services: Nothing
Activation node: 0
Priority Level: 0
Preempter: 0
Incoming calls restriction COS: 10
Outgoing…COS: 10
Callee number…:No
Overlap Dialing: Yes
Call diversion in ISDN: No
Do you need any more information - I’ll find them out for you!
Here is the configuration on the Asterisk-side:
[SIP_Trunk_Alcatel]
host=172.20.116.13
type=peer
qualify=yes
context=from-alcatel
Hi Malte, first of all I really think that OPTION packets sent by OXE are because you have setted “Super Vision Timer: 10” up. Try to put " 0 " or " -1 " ( i don’t remenber the value, but you can know by press TAB button on mgr and you’ll see ).
Configuration seems ok but something is missing. How Do you call asterisk? I mean, what did you set up like Prefix? Routing number? Network number? ARS? Which Network are you using? are you associated it with Sip Ext Gw #2 ?
If you do a " motortrace 3 " and then " traced", what is the trace? Can you post it?
