Jump to content

Louis Yssel

  • Posts

  • Joined

  • Last visited

About Louis Yssel

  • Birthday 03/05/1965

Contact Methods

  • MSN
  • ICQ

Profile Information

  • Gender
  • Location
    South Africa

Louis Yssel's Achievements


Newbie (1/14)



  1. It seems like the codec that PBXnSIp uses to talk to OCS is not right. In the OCS trunk I do not specifiy and Codec Preference, and at System level I now changed the preferred codec to G.711. but still not. m=audio 59148 RTP/AVP 18 101 I find the above line all over in the SIP trace and I know it is then trying codec 18 (G.729) which OCS does not seem to like, and then 101, which I do not know what it is. Thanks
  2. In the PBXnSIP log file I now found the following: [5] 20090313163438: SIP Rx tcp: SIP/2.0 100 Trying FROM: "+27829089222"<sip:+27829089222@ysl.yslzone.net:5060;user=phone>;tag=22266 TO: "Louis Yssel"<sip:0878053505@ysl.yslzone.net> CSEQ: 13449 INVITE CALL-ID: 0b085c08@pbx VIA: SIP/2.0/TCP;branch=z9hG4bK-7981d3c3feaf5e6c7bb079f42d33ec63;rport CONTENT-LENGTH: 0 [9] 20090313163438: Resolve 781884: aaaa udp 2051 [9] 20090313163438: Resolve 781884: a udp 2051 [9] 20090313163438: Resolve 781884: udp 2051 [9] 20090313163438: Resolve 781885: udp 1040 [9] 20090313163438: Resolve 781886: aaaa udp 4263 [9] 20090313163438: Resolve 781886: a udp 4263 [9] 20090313163438: Resolve 781886: udp 4263 [9] 20090313163438: Resolve 781887: aaaa udp 2051 [9] 20090313163438: Resolve 781887: a udp 2051 [9] 20090313163438: Resolve 781887: udp 2051 [9] 20090313163438: Resolve 781888: aaaa udp 2051 [9] 20090313163438: Resolve 781888: a udp 2051 [9] 20090313163438: Resolve 781888: udp 2051 [9] 20090313163438: Resolve 781889: aaaa udp 2051 [9] 20090313163438: Resolve 781889: a udp 2051 [9] 20090313163438: Resolve 781889: udp 2051 [5] 20090313163438: SIP Rx tcp: SIP/2.0 488 Invalid incoming Gateway SDP: Did not find common codecs in media stream line in SDP offer FROM: "+27829089222"<sip:+27829089222@ysl.yslzone.net:5060;user=phone>;tag=22266 TO: "Louis Yssel"<sip:0878053505@ysl.yslzone.net>;tag=a6d092cddb CSEQ: 13449 INVITE CALL-ID: 0b085c08@pbx VIA: SIP/2.0/TCP;branch=z9hG4bK-7981d3c3feaf5e6c7bb079f42d33ec63;rport CONTENT-LENGTH: 0 SERVER: RTCC/ MediationServer [7] 20090313163438: Call 0b085c08@pbx#22266: Clear last INVITE [9] 20090313163438: Resolve 781890: url sip:+878053505@;transport=tcp [9] 20090313163438: Resolve 781890: a tcp 5060 [9] 20090313163438: Resolve 781890: tcp 5060 [5] 20090313163438: SIP Tx tcp: ACK sip:+878053505@;transport=tcp SIP/2.0 Via: SIP/2.0/TCP;branch=z9hG4bK-7981d3c3feaf5e6c7bb079f42d33ec63;rport From: "+27829089222" <sip:+27829089222@ysl.yslzone.net:5060;user=phone>;tag=22266 To: "Louis Yssel" <sip:0878053505@ysl.yslzone.net>;tag=a6d092cddb Call-ID: 0b085c08@pbx CSeq: 13449 ACK Max-Forwards: 70 Contact: <sip:0878053505@;transport=tcp> Content-Length: 0 [5] 20090313163438: INVITE Response 488 Invalid incoming Gateway SDP: Did not find common codecs in media stream line in SDP offer: Terminate 0b085c08@pbx [7] 20090313163438: Other Ports: 35 What would the Invalid incoming gateway SDP be. I have not set any preferred codec in the trunk settings.
  3. I have aliases in PBXnSIp for all possible formats for internal and external. 0878053505 +878053505 +3505 +8053505 +0878053505 +27878053505 When I run the logging tool in OCS on the Mediation server, the caals from PBXnSIP is not even reaching the OCS server, the call goes directly to Exchange UM. So country code is only used in the last variation of the alias. My OCS URI is +878053505 and the manual registration in PBXnSIP looks like: REGISTER 0878053505 sip:+878053505@;transport=tcp check-sync When I register a SNOM phone directly to 0878053505, it works 100% Thanks,
  4. Since we upgraded PBXnSIP to ver 3, we cannot recieve calls to the Communicator clients anymore. Is there a document available for the integration for ver 3.x as the one available is for ver 2. We did not change anything else, yet incoming calls to Communicator from PBXnSIp no longer works.
  5. The SOAP message in version changed drastically and all logging is not working. The TimeConnected and TimeAnswered fields is now showing the duration of the call and the Duration is only showing the seconds connected and ignoring the minutes. We are in the process of redoing the logging to SQL, but would like to make sure that these logs are correct as we do not want to change the code behind with every new version. <?xml version="1.0" encoding="utf-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sns="http://soap.com/pbx"> <env:Body> <sns:CDR> <CallID>3c29273a9c40-dzjn3pcjzf74@snom300-000413259650#c6eec00552</CallID> <Type>extcall</Type> <Domain>midlands.yslzone.net</Domain> <Language>en</Language> <From>"Midlands Speed dial" <sip:0878053621@midlands.yslzone.net></From> <To><sip:9@midlands.yslzone.net></To> <Extension>0878053621</Extension> <Number>9</Number> <FromUser>0878053621@midlands.yslzone.net</FromUser> <IvrUser>0878053621@midlands.yslzone.net</IvrUser> <ToTrunk> </ToTrunk> <TimeStart>1234282044</TimeStart> <LocalTime>20090210180724</LocalTime> <TimeConnected>93</TimeConnected> <TimeAnswered>93</TimeAnswered> <DurationHHMMSS>0:01:33</DurationHHMMSS> <Duration>33</Duration> <StatisticsReverse>0</StatisticsReverse> </sns:CDR> </env:Body> </env:Envelope>
  6. My carrier sends in a call without a + in front of it and calls to my GLOBAL ALIAS with a + in front don't work. Is there a way round this?
  7. We have a major dilemma, as this security feature is completely inhibitive on our hosting environment, as we have standard groupings of users in different domains, and this prevents us from upgrading to ver 3.0, as this trunk setup between domains will simply not work in our environment, and will cause undue administration. Having said that, not being able to go to version 3, we loose on the fix on the CDR's with speed dials and many other feautures we requested in the past. Will it not be possible to have a switch to enable/disable this security feature in ver 3, so at leasst we could pgrade and not have the trouble with inter domain calling. This is major and I am sure will be the case with a number of hosters using PBXnSIP.
  8. THis issue is related to the same client where we have the 1000 entry limit. The entries used in the address book comes from the Estate Management System in a download format that could be uploaded into the DOmain Address book in PBXnSIP. The idea is to on s regular basis update the address book in an automated way, whereby the entire address book is deleted and the new one uploaded. This will be far simpler thatn to develop an Synchronization mechanism. The problem is that you cannot delete and entire address book. You need to delete them entry by entry, and with 1000 + entries, this is taking way too long. Is this address book stored somewhere on the disk where one can produce a new xml file and just overwrite, or is it only through the web interface that this address book could be accessed.
  9. We use PBXnSIP in a Gated Community where the Domain address book is used for speed dials. This is used for security purposes, where the security guard can announce visitors by dialling a short code (Stand number) which then dial the full number in the address book. In this particular estate, we have 2500 stands, and we find we cannot get more than 1000 numbers into the address book. This is a problem which could cause the client to throw out the solution. I assume it could be that the numbers in the Address book are a 3 digit numeric field. Could this be adjusted?
  10. We are on version and planning to upgrade to ver 3.0 this weekend
  11. We are using Addressbook in PBXnSIP extensively for gatehouses to dial a stand number, which in turn phones the client. Theproblem is that the CDR created shows the speed dial code rather than the actual number phones, which means the gatehouse making the calls cannot be billed accurately (or at all) as the dialled number in the CDR shows *1234 rather than +27 12 661 1177. This is a major issue as billing is a nightmare to compare the CDR's to addressbook to determine the number that was dialled. Urgent assistance required.
  12. It would not work. We have 5000 short dials we need to use. 2 digits will not help. Even something like using a # for shortdials rather than the * it might also work.
  13. We are using speed dials extensively. The dilemma is that the people that are the main users of the Address Book, are calling card extension holders. When using a calling card, you cannot dial * and #, as is required by the short codes for speed dialling. Is there a way around this?
  14. How does one change the index. Not found on Wiki or in web interface.
  • Create New...