Sip trunk

I have problems with calling from Alcatel PBX to Asterisk PBX.
The other way is working fine? Does anybody have an idea what is up there?

I can see this SIP-packets every 40-60 seconds:
What does the 404 mean?

<— SIP read from UDP: —>
OPTIONS sip: SIP/2.0
Accept: application/sdp
User-Agent: OmniPCX Enterprise R9.0 h1.301.50
To: sip:
From: sip:;tag=62716c391811220b641b5eb4eae1948c
Call-ID: eb6df3577ef5a616aa984e9899a530b0@
CSeq: 2146746083 OPTIONS
Via: SIP/2.0/UDP;branch=z9hG4bK1601ad67abbf2016de66b85a26d55672
Max-Forwards: 70
Content-Length: 0

— (11 headers 0 lines) —
Looking for in from-sip-external (domain

<— Transmitting (no NAT) to —>
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP;branch=z9hG4bK1601ad67abbf2016de66b85a26d55672;received=
From: sip:;tag=62716c391811220b641b5eb4eae1948c
To: sip:;tag=as2bd99a98
Call-ID: eb6df3577ef5a616aa984e9899a530b0@
CSeq: 2146746083 OPTIONS
Server: FPBX-2.9.0(
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

Scheduling destruction of SIP dialog ‘eb6df3577ef5a616aa984e9899a530b0@’ in 32000 ms (Method: OPTIONS)
Really destroying SIP dialog ‘76ea6eca58c53dac77356a17d63722e7@’ Method: OPTIONS

its just a dogwatch, and though surprising, the 404 is not be worried about.

hey, thanks.

so if the problem would be on the asterisk side - I should see some more in the trace?

here is another sip-packet I’m wondering about:

Scheduling destruction of SIP dialog ‘e63eb84f61dd3e3d858647b859d44232@’ in 32000 ms (Method: OPTIONS)
Really destroying SIP dialog ‘1618fc8c5a2f9677e9b19094c27f391c@’ Method: OPTIONS
Reliably Transmitting (no NAT) to
OPTIONS sip: SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK184159f2
Max-Forwards: 70
From: “Unknown” sip:Unknown@;tag=as4f28ff73
To: sip:
Contact: sip:Unknown@
Call-ID: 2ff17a880000df6719987c6327fff474@
User-Agent: FPBX-2.9.0(
Date: Thu, 30 Jun 2011 20:51:17 GMT
Supported: replaces, timer
Content-Length: 0

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 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 ?)

The OPTIONS are not from Asterisk!

So, when I call from Asterisk to Alcatel - that is working fine!
But when I call from Alcatel to Asterisk - nothing happens.

the sip debug doens’t show me an INVITE or any other messages.

I stopped iptables and restarted Asterisk - but that didn’t help.

So it might be a network problem?

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 and gave him the IP of the old one.
So @Alcatel - nothing was changed. and the trunk-config @asterisk is exactly the same:


Was there something changed with 1.8 concerning trunks? I didn’t find something in the changelog.

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:

Contact = ("Contact" / "m" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport uri-parameters [ headers ] absoluteURI = scheme ":" ( hier-part / opaque-part ) scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
which seems to require more than just “Contact:” on the line.

thanks for your answer.
Could you give me any idea how to proceed solving that problem?

By the way:
I put the server with Asterisk 1.6 back in service in the morning.
The trunk was directly working fine again.

So the problem must be between Asterisk 1.8 and the Alcatel PBX.

Turn off the problem function in the Alcatel.

Examine the Asterisk source code to see what changed, and patch it to re-instate the original behaviour.

Raise it as an issue on, making it clear that this is an incompatibility with Alcatel, rather than a bug in Asterisk.

The last approach may take many months for anything to happen.

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!



hey guys,
it would be really great if anybody could help me with this problem.
I don’t really have an idea how to solve it via the source code.

Thanks in advance!


Hi Malte, I am an ACSE and I have in my lab an Asterisk box v 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 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
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
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! :smile:

Here is the configuration on the Asterisk-side:

Thanks a lot for your help!


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?