Jump to content

Sota Solutions

  • Posts

  • Joined

  • Last visited

Profile Information

  • Location

Sota Solutions's Achievements


Newbie (1/14)



  1. Yes the CISCO does seem to be altering the SIP REGISTER packets, there seems to be SIP fixup enabled in the CISCO config fixup protocol sip 5060 fixup protocol sip udp 5060 Disabling these has not made a difference though, however we have been able to get incoming calls working by reducing the "Maximum Registration Time" to 1 minute. Whether this is advisable or not as a long term solution though I'm not sure!
  2. Has anyone had any experience of setting up phones behind a CISCO PIX. We have 2 x SNOM phones at a customer location, behind a CISCO PIX firewall, registering to a hosted PBX. The SNOM phones are registering successfully, however in the phone log the phones register every 1800 seconds instead of the usual 15 secs on working phones. [2]9/4/2008 09:56:46: Registered at registrar as 3551@pbx.domain.co.uk (Expires: 1800 secs) This is typical where the phone is behind a device with a SIP ALG, and usually disabling the SIP ALG solves this. We have tried the following command on the PIX no ip nat service sip but continue to have problems with incoming calls. So if anyone has any experience/suggestions they would be gratefully recieved! Thanks Tim
  3. \1 is the 7 digit pattern taken from the left hand side. @ is literally the @ symbol. \r is the registrar or domain from the trunk settings. user=phone indicate that the user part of the URI we're calling is a phone number. In the example below I would actually use ^8([0-9]{7})@.* as otherwise potentially you could match on not just 81234567 but also longer numbers containing the pattern 8+7digits e.g. 12381234567. The ^ forces matching from the Left.
  4. OK this has worked, our dial plans work as expected now. Without this ^ symbol, it appears expressions are evaluated right to left. So I would advise whenever using EREs which match something at the start of a number, its best practice to use ^ to ensure nothing unexpected happens!! Thanks Tim
  5. I have now run the same test with 2.1.5 and get the following information in the logs. Dialplan: Evaluating !1([0-9]{2})@.*!sip:1\1@\r!i against 01632465160@pbx.domain.co.uk Dialplan FFDP: Match 01632465160@pbx.domain.co.uk to <sip:160@> on trunk Vega The dial plan in PBXnSIP is as follows: Pattern: 1([0-9]{2})@.* Replacement: sip:1\1@\r Thanks
  6. I shall try 2.1.5 and see what the logs show. Is there an official release date? Thanks
  7. Since upgrading to PBXnSIP v2, we are having problems with dial plans that have worked perfectly and predicatably in PBXnSIP 1.5x For example given the following dialplan which has historically been used for matching UK BT numbers such as 154 and sending them out via PSTN. 100 VEGA 1([0-9]{2}) sip:1\1@\r we then have oddities such as 11 digit numbers matching this dial plan entry: [5] 2008/01/07 10:50:31: Dialplan: Match 01632465160@pbx.domain.co.uk to <sip:160@> on trunk Vega As you can see somehow we end up with the last 3 digits of the number being dialled???? Yes this can be got around with a simpler 1xx dial plan, but this is for example purposes, we have similar problems with more complex patterns. Has something changed with pattern matching? Thanks in advance Tim
  8. Given the situation where you have two domains on a PBXnSIP server, one domain has 2xx series extensions and the other has 6xx series extension numbers, is there any easy way to enable inter-domain calling by extension number? I have experimented with dial plans and read the WIKI entry on Inter domain calling but so far cannot get this working. Thanks in advance for any advice Tim
  9. Upgrade to PBXnSIP - this version prevents this endless looping.
  • Create New...