rotate your logs after setting sipxbridge and proxy to debug logging levels. then make the test call and run
merge-logs from the cli. post the resulting /var/log/sipxpbx/merged.xml and open with sipviewer or post to the list. change your logging levels back. On Mon, Sep 19, 2011 at 10:07 AM, Tony Graziano < [email protected]> wrote: > Well, I still dont think "you_get_it" when it comes to providing a sip > trace... > > 1. Your pcap never showed the initial invite. Critical you run the pcap > before you make the test call. > 2. Your call trace is NOT a sipx call trace, and is unuseable to > troubleshoot when you just provide a heavily modified text file. > 3. You have not identified if the ITSP is sending the DID in the INVITE or > the TOP header. A proper sip trace would also indicate that. > > When you are willing to provide useable and menaingful information, I'm > sure you will be assisted. > > IF the ITSP is sending you the invite on port 5080 and you are not > translating it to 5080 at your firewall, and your outbound NAT for sixp at > your firewall is symmetric (still have not said what your firewall is), then > your siptrace using the instructions on the wiki will be most insightful. > > Providing sipxbridge or proxy logs will not help at this point, you are not > showing the interactions between the different mechanisms in sipx until you > provide a trace file in xmp format. Agaion see the wiki. > > On Mon, Sep 19, 2011 at 9:23 AM, Nils Adolfsson > <[email protected]>wrote: > >> Thanks for all the replies. >> >> I've tried entering all kinds of number combinations as aliases now, so if >> it "should" be as easy as just entering the DID number there it should have >> worked by now. >> After reading what Michael Picher wrote I've also tried to use dial plans. >> After all, it does make sense to be able to use a rule that can be applied >> to a group of people to lower the amount of repetitive labour. >> >> I've also spoken to a co-worker of mine to see if we can set up an old >> asterisk based system to connect to the SIP trunk. >> That way we can see if the messages sent between the trunk and the two >> different systems differ in any way. >> I'm beginning to suspect my ITSP a bit because I need to set the "INVITE >> From ITSP Account" flag in the gateway (which apparently does not follow the >> RFC - btw, is that RFC 3261?). >> If I don't, I get a "604 does not exist anywhere" message back from the >> ITSP when I try to call out from a soft phone, that is connected to my SipX >> server, to a regular phone. >> I'm not saying that it works with it checked though. Because what happens >> is that the SipX server goes to the SIP trunk and successfully starts the >> call. >> The soft phone then starts sending a lot of RTP packets to the SipX >> server. >> However, my phone does not ring and no RTP packets are sent from the SipX >> server to the SIP trunk, nor does the soft phone receive any RTP packets. >> I will come back later when I've tested this more thoroughly and know more >> about the "604 does not exist anywhere" error message. >> >> And yes, mr Graziano, I know that all of this can be found in the wiki, >> which you can see in my original post. >> Basically, the reason why I started this thread was because the tips found >> here >> http://wiki.sipfoundry.org/display/sipXecs/Trouble+shooting+and+problem+reporting >> did not help when I was trouble shooting after following the guide in the >> wiki. Therefore I turned to the people in this mailing list who >> have considerable more experience of sipx than me. >> In that way someone might have been able point out where I could go next >> in my hunt for solutions of my troubles. >> >> I've got some pointers now, and I'm very thankful for that >> >> Regards >> Nils >> >> 2011/9/17 Todd Hodgen <[email protected]> >> >>> Are you including incoming calls when you say “all”**** >>> >>> ** ** >>> >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Michael Picher >>> *Sent:* Friday, September 16, 2011 4:31 PM >>> >>> *To:* Discussion list for users of sipXecs software >>> *Subject:* Re: [sipx-users] Trouble with setting up SIP trunking**** >>> >>> ** ** >>> >>> Fyi, dial plans process all calls after user extensions/aliases... not >>> just outbound calls.**** >>> >>> On Sep 16, 2011 12:42 PM, "Todd Hodgen" <[email protected]> wrote: >>> > Tony brings up a good point here, that there really isn't a great >>> document >>> > describing in detail when you look at the overall architecture of >>> sipxecs. >>> > The dial plans in sipXecs are only used for Outgoing calls, and have no >>> > effect on incoming calls. And, just to re-iterate what I've seen >>> answered >>> > here many times on this list, when the dial plans are used on a call, >>> it >>> > looks for the first match, and then takes that route - so if you are >>> having >>> > issues with outgoing calls, start at the top of our plans and start >>> looking >>> > for matches until you find one - and your problem. >>> > >>> > >>> > >>> > For your incoming calls, ensure the number is in an alias somewhere, >>> and >>> > ensure it is the right length in characters. Putting the entire number >>> in >>> > that field when the carrier provides the last 4 digits will be of no >>> value. >>> > If your alias doesn't work with an extension in the system, try it on >>> an >>> > auto attendant. >>> > >>> > >>> > >>> > If it works on one, and not the other, you need to start looking for >>> issues >>> > between the system and the carrier. >>> > >>> > >>> > >>> > From: [email protected] >>> > [mailto:[email protected]] On Behalf Of Tony >>> Graziano >>> > Sent: Friday, September 16, 2011 3:39 AM >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] Trouble with setting up SIP trunking >>> > >>> > >>> > >>> > I am having a hard time following you because the dial plan is not used >>> for >>> > incoming calls. >>> > >>> > the user alias or the service alias for d I d number is were you put >>> the >>> > incoming number in the format it's provided. >>> > >>> > no 1 can provide you with that because you manually edit did that out >>> of >>> > your log file. >>> > >>> > everything in this thread so far is in the wiki. >>> > >>> > On Sep 16, 2011 5:34 AM, "Nils Adolfsson" <[email protected]> >>> wrote: >>> >> Sorry for reviving a dead thread. >>> >> For those who find this conversation on any search engine: >>> >> >>> >> The problem I had was solved by changing the To and From parameters >>> from >>> >> <sip:username@ITSP_provider_domain> to <sip:username@my_domain>. >>> >> >>> >> The problem I'm having now is to call in from a regular phone on the >>> > public >>> >> phone net to through the SIP trunk and to the SipX server. >>> >> Before saying any more, the server is located OUTSIDE the company's >>> > firewall >>> >> using a public address (I will deal with possible firewall problems >>> later >>> >> when the SipX configuration works). >>> >> >>> >> As it looks right now, the SipX server has a SIP trunk gateway that >>> >> successfully registers with the ITSP's SIP trunk. >>> >> However, when calling to the SipX server from a regular phone it >>> fails. >>> >> Every phone extension has its own public phone number, i.e. I'm using >>> > DID's >>> >> if I understand everything correctly. >>> >> I have tried to set up dial plans to route incoming calls from the DID >>> >> number to the local extension, enter the DID as the alias of the user >>> and >>> >> make a user who's extension is its DID. >>> >> And none of this works. >>> >> >>> >> It seems as if the calls come into the SipX bridge and to the proxy, >>> > however >>> >> then it says "404 Not found" and sends an error message back to the >>> SIP >>> >> trunk. >>> >> >>> >> I have followed several guides showing how to set things up but it >>> doesn't >>> >> seem to work when I do as they do. >>> >> >>> >> The short version of the logs of both the proxy and the bridge is the >>> >> following: >>> >> >>> >> IN: Invite >>> >> OUT: Trying >>> >> OUT: Invite >>> >> IN: Trying >>> >> IN: 404 Not found >>> >> OUT: ACK >>> >> OUT: 404 Not found >>> >> IN: ACK >>> >> >>> >> The whole log entries can be found in the attached .txt file. >>> >> >>> >> Regards >>> >> Nils Adolfsson >>> >> >>> >> 2011/9/9 Tony Graziano <[email protected]> >>> >> >>> >>> Oh, juniper needs to have the SIP ALG function turned off, and 1:1 >>> nat >>> >>> enabled. Im guessing you don't have the SIP off in it. it's >>> intentionally >>> >>> mangling the ports. >>> >>> >>> >>> >>> >>> On Fri, Sep 9, 2011 at 8:03 AM, Tony Graziano < >>> >>> [email protected]> wrote: >>> >>> >>> >>>> I don't think you get it. >>> >>>> >>> >>>> provide the ITSp name. Maybe someone has done this before. Some are >>> >>>> quirky. >>> >>>> >>> >>>> State the firewall. If you dont have symmetric nat ebaled it WILL >>> NOT >>> >>>> WORK. >>> >>>> >>> >>>> Make sure your intranet subnets is stated properly. >>> >>>> >>> >>>> it times out/cant be found because it cant resolve the name or your >>> IP >>> >>>> address you are entering for the itsp can't be reached. >>> >>>> >>> >>>> you are being asked question, repeatedly, but you are avoiding >>> answering >>> >>>> them. >>> >>>> >>> >>>> On Fri, Sep 9, 2011 at 7:48 AM, Nils Adolfsson >>> > <[email protected]>wrote: >>> >>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> I am currently trying to set up a SIP trunk so that I can call to >>> > regular >>> >>>>> phones through my SipX server. >>> >>>>> I am having some problems though to authenticate with the ITSP's >>> SIP >>> >>>>> trunk service. >>> >>>>> Log messages from sipxbridge.log shows that the request either >>> times >>> > out >>> >>>>> or that it is not found (errors 404 and 408). >>> >>>>> I do not believe that it is the fire wall, because I have tried to >>> open >>> >>>>> both port 5060 and port 5080 both to and from the SipX server. >>> >>>>> Another reason why it should not be problem with the firewall is >>> > because >>> >>>>> that my SipX server is the one who registers to the ITSP server, >>> i.e. >>> > the >>> >>>>> SipX server opens a connection. >>> >>>>> >>> >>>>> I find it a bit interesting that it writes the local address in the >>> SIP >>> >>>>> messages (as you can see in the log message below). >>> >>>>> The SipX server knows that it is under NAT and that it should use >>> NAT >>> >>>>> traversal, as well as that it knows its public IP address. >>> >>>>> I also find it interesting that the source and destination >>> addresses >>> > are >>> >>>>> identical saying "username@ITSP_provider_domain", especially when >>> the >>> >>>>> ITSP (I called them to see if they had any logs of what was wring) >>> said >>> > that >>> >>>>> it should be "username@my_domain". >>> >>>>> >>> >>>>> I have tried to use port 5080 on my server and send authentication >>> >>>>> requests to port 5060 on the ITSP's server. >>> >>>>> I have also tried to use port 5060 on my SipX server while using >>> the >>> >>>>> option where SipX listens to that port for SIP trunking messages. >>> >>>>> >>> >>>>> The two main guides I've followed are: >>> >>>>> http://wiki.sipfoundry.org/display/sipXecs/SIP+Trunking >>> >>>>> http://blog.myitdepartment.net/?p=191 >>> >>>>> >>> >>>>> Other info >>> >>>>> -------------- >>> >>>>> The firewall is a Juniper SSG5 (firmware 6.3.0R8.0) >>> >>>>> ITSP: DGC (http://www.dgc.se/sv/om-dgc/About-DGC-ENG/) >>> >>>>> Name of the SipX server: sipx1.prod.sipx >>> >>>>> >>> >>>>> Log messages from /var/log/sipxpbx/sipxbridge.log >>> >>>>> >>> >>>>> Outgoing message: >>> >>>>> ---------------------------- >>> >>>>> >>> > >>> "2011-09-09T10:04:07.209000Z":20:OUTGOING:INFO:sipx1.prod.sipx:Timer-0:00000 >>> > 000:sipXbridge:"Sent >>> >>>>> SIP Message :\n----Remote Host:192.168.10.12---- Port: >>> > 5060----\nREGISTER >>> >>>>> sip:ITSP_provider_domain SIP/2.0\r\nCall-ID: >>> >>>>> [email protected]\r\nCSeq: 2 >>> >>>>> REGISTER\r\nFrom: >>> > <sip:username@ITSP_provider_domain>;tag=892685948627891857\r\nTo: >>> >>>>> <sip:username@ITSP_provider_domain>\r\nVia: SIP/2.0/TCP >>> >>>>> >>> > 192.168.10.12:5080 >>> ;branch=z9hG4bK65a6742857b86280cbfa7e40924e361e383035\r\nM >>> > ax-Forwards: >>> >>>>> 70\r\nUser-Agent: sipXecs/4.4.0 sipXecs/sipxbridge >>> (Linux)\r\nAllow: >>> >>>>> INVITE,BYE,ACK,CANCEL,OPTIONS\r\nSupported: timer\r\nRoute: >>> >>>>> <sip:192.168.10.12:5060;transport=tcp;lr>\r\nContact: < >>> >>>>> sip:[email protected] <mailto:sip%[email protected]> >>> > ;transport=tcp>\r\nExpires: >>> >>>>> 600\r\nContent-Length: >>> >>>>> 0\r\n\r\n--------------------END--------------------\n" >>> >>>>> >>> >>>>> Incoming message: >>> >>>>> ---------------------------- >>> >>>>> >>> > >>> "2011-09-09T10:04:12.336000Z":22:INCOMING:INFO:sipx1.prod.sipx:PipelineThrea >>> > d-0:00000000:sipXbridge:"Read >>> >>>>> SIP Message:\n----Remote Host:192.168.10.12---- Port: >>> 5060----\nSIP/2.0 >>> > 408 >>> >>>>> Request timeout\r\nFrom: >>> > <sip:username@ITSP_provider_domain>;tag=892685948627891857\r\nTo: >>> >>>>> <sip:username@ITSP_provider_domain>;tag=CHszxZ\r\nCall-ID: >>> >>>>> [email protected]\r\nCSeq: 2 >>> >>>>> REGISTER\r\nVia: SIP/2.0/TCP >>> > 192.168.10.12:5080 >>> ;branch=z9hG4bK65a6742857b86280cbfa7e40924e361e383035\r\nS >>> > erver: >>> >>>>> sipXecs/4.4.0 sipXecs/sipXproxy (Linux)\r\nContent-Length: >>> >>>>> 0\r\n\r\n====================END====================\n" >>> >>>>> >>> >>>>> Sniffing with Wireshark shows pretty much the same thing as these >>> logs. >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> sipx-users mailing list >>> >>>>> [email protected] >>> >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> ====================== >>> >>>> Tony Graziano, Manager >>> >>>> Telephone: 434.984.8430 >>> >>>> sip: [email protected] >>> >>>> Fax: 434.465.6833 >>> >>>> >>> >>>> Email: [email protected] >>> >>>> >>> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >>> >>>> Telephone: 434.984.8426 >>> >>>> sip: [email protected] >>> >>>> >>> >>>> Helpdesk Contract Customers: >>> >>>> http://support.myitdepartment.net >>> >>>> >>> >>>> <http://support.myitdepartment.net>Blog: >>> >>>> http://blog.myitdepartment.net >>> >>>> >>> >>>> Linked-In Profile: >>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> >>>> >>> >>>> Ask about our Internet faxservices! >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> -- >>> >>> ====================== >>> >>> Tony Graziano, Manager >>> >>> Telephone: 434.984.8430 >>> >>> sip: [email protected] >>> >>> Fax: 434.465.6833 >>> >>> >>> >>> Email: [email protected] >>> >>> >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> >>> Telephone: 434.984.8426 >>> >>> sip: [email protected] >>> >>> >>> >>> Helpdesk Contract Customers: >>> >>> http://support.myitdepartment.net >>> >>> >>> >>> <http://support.myitdepartment.net>Blog: >>> >>> http://blog.myitdepartment.net >>> >>> >>> >>> Linked-In Profile: >>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> >>> >>> >>> Ask about our Internet faxservices! >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> sipx-users mailing list >>> >>> [email protected] >>> >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >>> > **** >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.465.6833 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Contract Customers: > http://support.myitdepartment.net > > <http://support.myitdepartment.net>Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > Ask about our Internet faxservices! > > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net <http://support.myitdepartment.net>Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices!
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
