Jump to content

eyeless

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by eyeless

  1. Yes, but the last: "Then you need to put your phone number into the setting Trunk ANI of the PBX." might not be needed as I received the exact same result with it filled in or not. Thanks!!
  2. I understand. I will try and work this out with the trunk provider, and it should in their interest to be able to help out in such cases, so … . Will post the solution here if I get one.
  3. I see. Not very helpful though as I only want the SnomOne to send out headers just like it always has done up to version 4.5.x … when there has been no problem. Apparently the trunk providers are using Asterix servers themselves and do not understand SnomOne … . So was the reason for changing this to get people to buy the SnomOne 5 instead? One wonders … .
  4. Well, the provider did not understand what was wrong or how to change to a custom header. I tried all the different alternatives in the Number/Call Identification section now (well, almost all, at least all in the drop-down menu). Here is the log if it makes anything more clear (I only have added to the Trunk ANI field the phone number after upgrade - this field was blank before, but adding the number there did not change anything) - the hidden outgoing number is 031109430 (account name is both 30 & 031109430): [5] 2013/02/08 16:11:29: SIP Rx tls:10.0.3.234:3448: INVITE sip:0317018939@10.0.3.10;user=phone SIP/2.0 Via: SIP/2.0/TLS 10.0.3.234:3448;branch=z9hG4bK-hcuffvg1f2s0;rport From: "Eva Levin" <sip:30@10.0.3.10>;tag=s1609stbfc To: <sip:0317018939@10.0.3.10;user=phone> Call-ID: 3c31d1beece8-lhkffaqe75rn CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:30@10.0.3.234:3448;transport=tls;line=omt9jyts>;reg-id=1 X-Serialnumber: 00041331E1F5 P-Key-Flags: keys="3" User-Agent: snom320/8.4.18 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, 100rel, replaces, from-change Session-Expires: 3600;refresher=uas Min-SE: 90 Proxy-Require: buttons Content-Type: application/sdp Content-Length: 518 v=0 o=root 484433817 484433817 IN IP4 10.0.3.234 s=call c=IN IP4 10.0.3.234 t=0 0 m=audio 64710 RTP/AVP 9 0 8 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:E2SAYAZBeodnsVnNhmM1XR7Y9uOpVl68nShKlNlx a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp-xr:voip-metrics stat-summary=loss,dup,jitt a=sendrecv [8] 2013/02/08 16:11:29: Packet authenticated by transport layer [9] 2013/02/08 16:11:29: Using outbound proxy sip:10.0.3.234:3448;transport=tls because of flow-label [9] 2013/02/08 16:11:30: Last message repeated 3 times [5] 2013/02/08 16:11:30: SIP Tx tls:10.0.3.234:3448: SIP/2.0 100 Trying Via: SIP/2.0/TLS 10.0.3.234:3448;branch=z9hG4bK-hcuffvg1f2s0;rport=3448 From: "Eva Levin" <sip:30@10.0.3.10>;tag=s1609stbfc To: <sip:0317018939@10.0.3.10;user=phone>;tag=8d078c94b0 Call-ID: 3c31d1beece8-lhkffaqe75rn CSeq: 1 INVITE Content-Length: 0 [8] 2013/02/08 16:11:30: Incoming call: Request URI sip:0317018939@10.0.3.10;user=phone, To is <sip:0317018939@10.0.3.10;user=phone> [8] 2013/02/08 16:11:30: Set the To domain based on From user 30@10.0.3.10 [9] 2013/02/08 16:11:30: Resolve 10167: url sip:sip.voicetech.se [9] 2013/02/08 16:11:30: Resolve 10167: naptr sip.voicetech.se [9] 2013/02/08 16:11:30: Resolve 10167: srv tls _sips._tcp.sip.voicetech.se [9] 2013/02/08 16:11:30: Resolve 10167: srv tcp _sip._tcp.sip.voicetech.se [9] 2013/02/08 16:11:30: Resolve 10167: srv udp _sip._udp.sip.voicetech.se [9] 2013/02/08 16:11:30: Resolve 10167: aaaa udp sip.voicetech.se 5060 [9] 2013/02/08 16:11:30: Resolve 10167: a udp sip.voicetech.se 5060 [9] 2013/02/08 16:11:30: Resolve 10167: udp 212.3.0.180 5060 [5] 2013/02/08 16:11:30: SIP Tx udp:212.3.0.180:5060: INVITE sip:0317018939@sip.voicetech.se;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-d480b58ea53b1be72eb8bf65a62c4c8a;rport From: "Eva Levin" <sip:031109430@10.0.3.10;user=phone>;tag=879293534 To: <sip:0317018939@10.0.3.10;user=phone> Call-ID: 173c1240@pbx CSeq: 25139 INVITE Max-Forwards: 70 Contact: <sip:031109430@10.0.3.10:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snomONE/4.5.1.1107 Zeta Perseids P-Asserted-Identity: "Eva Levin" <sip:031109430@sip.voicetech.se> Privacy: id Content-Type: application/sdp Content-Length: 378 v=0 o=- 1818723674 1818723674 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 50058 RTP/AVP 0 8 9 18 2 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [5] 2013/02/08 16:11:30: set codec: codec pcmu/8000 is set to call-leg 139 [5] 2013/02/08 16:11:30: SIP Tx tls:10.0.3.234:3448: SIP/2.0 183 Session Progress Via: SIP/2.0/TLS 10.0.3.234:3448;branch=z9hG4bK-hcuffvg1f2s0;rport=3448 From: "Eva Levin" <sip:30@10.0.3.10>;tag=s1609stbfc To: <sip:0317018939@10.0.3.10;user=phone>;tag=8d078c94b0 Call-ID: 3c31d1beece8-lhkffaqe75rn CSeq: 1 INVITE Contact: <sip:30@10.0.3.10:5061;transport=tls> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snomONE/4.5.1.1107 Zeta Perseids Require: 100rel RSeq: 1 Content-Type: application/sdp Content-Length: 474 v=0 o=- 1414671445 1414671445 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 58816 RTP/AVP 0 8 9 18 2 3 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:ssWlPg8UG7cr5hZuHpunzJ9JfCBJFmfdgZAPsbPa a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [5] 2013/02/08 16:11:30: SIP Rx udp:212.3.0.180:5060: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-d480b58ea53b1be72eb8bf65a62c4c8a;rport=47104 From: "Eva Levin" <sip:031109430@10.0.3.10:5060;user=phone>;tag=879293534 To: <sip:0317018939@10.0.3.10:5060;user=phone>;tag=7000166881dd2f9a2a8458b004d02617.ff08 Call-ID: 173c1240@pbx CSeq: 25139 INVITE Proxy-Authenticate: Digest realm="sips.teleman.com", nonce="511519265cc9bda9b08f820a70c78daa8fc448af" Server: OpenSer (1.1.0-tls (x86_64/linux)) Content-Length: 0 Warning: 392 212.3.0.180:5060 "Noisy feedback tells: pid=29552 req_src_ip=81.216.208.134 req_src_port=47104 in_uri=sip:0317018939@sip.voicetech.se;user=phone out_uri=sip:0317018939@sip.voicetech.se;user=phone via_cnt==1" [8] 2013/02/08 16:11:30: Answer challenge with username 031109430 [9] 2013/02/08 16:11:30: Resolve 10169: udp 212.3.0.180 5060 udp:1 [5] 2013/02/08 16:11:30: SIP Tx udp:212.3.0.180:5060: ACK sip:0317018939@sip.voicetech.se;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-d480b58ea53b1be72eb8bf65a62c4c8a;rport From: "Eva Levin" <sip:031109430@10.0.3.10:5060;user=phone>;tag=879293534 To: <sip:0317018939@10.0.3.10:5060;user=phone>;tag=7000166881dd2f9a2a8458b004d02617.ff08 Call-ID: 173c1240@pbx CSeq: 25139 ACK Max-Forwards: 70 Content-Length: 0 [9] 2013/02/08 16:11:30: Resolve 10170: udp 212.3.0.180 5060 udp:1 [5] 2013/02/08 16:11:30: SIP Tx udp:212.3.0.180:5060: INVITE sip:0317018939@sip.voicetech.se;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-60034bf93976763369c60cb96a63233e;rport From: "Eva Levin" <sip:031109430@10.0.3.10;user=phone>;tag=879293534 To: <sip:0317018939@10.0.3.10;user=phone> Call-ID: 173c1240@pbx CSeq: 25140 INVITE Max-Forwards: 70 Contact: <sip:031109430@10.0.3.10:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snomONE/4.5.1.1107 Zeta Perseids P-Asserted-Identity: "Eva Levin" <sip:031109430@sip.voicetech.se> Privacy: id Proxy-Authorization: Digest realm="sips.teleman.com",nonce="511519265cc9bda9b08f820a70c78daa8fc448af",response="b49cb9031c05e2a49124edc6790d170a",username="031109430",uri="sip:0317018939@sip.voicetech.se;user=phone",algorithm=MD5 Content-Type: application/sdp Content-Length: 378 v=0 o=- 1818723674 1818723674 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 50058 RTP/AVP 0 8 9 18 2 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [9] 2013/02/08 16:11:30: Message repetition, packet dropped [5] 2013/02/08 16:11:30: SIP Rx udp:212.3.0.180:5060: SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-60034bf93976763369c60cb96a63233e;rport=47104 From: "Eva Levin" <sip:031109430@10.0.3.10:5060;user=phone>;tag=879293534 To: <sip:0317018939@10.0.3.10:5060;user=phone> Call-ID: 173c1240@pbx CSeq: 25140 INVITE Server: OpenSer (1.1.0-tls (x86_64/linux)) Content-Length: 0 Warning: 392 212.3.0.180:5060 "Noisy feedback tells: pid=29553 req_src_ip=81.216.208.134 req_src_port=47104 in_uri=sip:0317018939@sip.voicetech.se;user=phone out_uri=sip:0317018939@sip4.teleman.com;user=phone via_cnt==1" [9] 2013/02/08 16:11:30: Message repetition, packet dropped [5] 2013/02/08 16:11:30: SIP Rx tls:10.0.3.234:3448: PRACK sip:30@10.0.3.10:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 10.0.3.234:3448;branch=z9hG4bK-oy0pueeg4a5m;rport From: "Eva Levin" <sip:30@10.0.3.10>;tag=s1609stbfc To: <sip:0317018939@10.0.3.10;user=phone>;tag=8d078c94b0 Call-ID: 3c31d1beece8-lhkffaqe75rn CSeq: 2 PRACK Max-Forwards: 70 Contact: <sip:30@10.0.3.234:3448;transport=tls;line=omt9jyts>;reg-id=1 RAck: 1 1 INVITE Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Proxy-Require: buttons Content-Length: 0 [8] 2013/02/08 16:11:30: Packet authenticated by transport layer [5] 2013/02/08 16:11:30: SIP Tx tls:10.0.3.234:3448: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.234:3448;branch=z9hG4bK-oy0pueeg4a5m;rport=3448 From: "Eva Levin" <sip:30@10.0.3.10>;tag=s1609stbfc To: <sip:0317018939@10.0.3.10;user=phone>;tag=8d078c94b0 Call-ID: 3c31d1beece8-lhkffaqe75rn CSeq: 2 PRACK Contact: <sip:30@10.0.3.10:5061;transport=tls> User-Agent: snomONE/4.5.1.1107 Zeta Perseids Content-Length: 0 [5] 2013/02/08 16:11:30: SIP Rx udp:212.3.0.180:5060: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.0.3.10:5060;branch=z9hG4bK-60034bf93976763369c60cb96a63233e;rport=47104 Record-Route: <sip:212.3.0.180;lr=on;ftag=879293534> Contact: <sip:0317018939@212.3.0.165:5060;transport=udp> To: <sip:0317018939@10.0.3.10:5060;user=phone>;tag=97be3903 From: "Eva Levin"<sip:031109430@10.0.3.10:5060;user=phone>;tag=879293534 Call-ID: 173c1240@pbx CSeq: 25140 INVITE Content-Type: application/sdp Content-Length: 367 v=0 o=- 19337546 0 IN IP4 88.131.198.35 s=Cisco SDP 0 c=IN IP4 62.80.216.14 t=0 0 m=audio 43684 RTP/AVP 8 101 100 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194,200-202 a=X-sqn:0 a=X-cap: 1 audio RTP/AVP 100 a=X-cpar: a=rtpmap:100 X-NSE/8000 a=X-cpar: a=fmtp:100 192-194,200-202 a=X-cap: 2 image udptl t38 [5] 2013/02/08 16:11:30: set codec: codec pcma/8000 is set to call-leg 140
  5. Yes, I saw that field, but was not sure if it would be meaningful to change it … will see what I can do to get it to work …. .
  6. Hi, We upgraded to the latest version of SnomOne 4: Zeta Perseids (4.5.1.1107) (Mac OS X) Apart from having to upgrade the Snom M9 telephones in order to get two-way voice, we only have one problem left and that is that all outgoing calls are now displayed as hidden to the recipient and I cannot simply find a way to make the recipient see what number the calls are coming from any longer. Anyone who has a hint of what might have changed from version 4.2-4.3 to the 4.5 version that could affect this? All the best, Jerry
  7. But hopefully it will get better ... . Will try and analyze what is causing this ... .
  8. Sounds like something to follow up on (yes, now that you point it out it is strange with the two IPs - will look into that). However, soon after I somewhat frustrated posted this, I got learn about a problem at the telephony station affecting our DSL connection (strange organisational arrangements at the location), which may be the reason why this has started to happen recently (as far as I can make out). I get back here if I find out something more of relevance as the problems might have different parts ... .
  9. Hi, Tried to post in the Snom phones forum section, but could not find out any way in which to do so as I could not login there no matter what ... (but not sure this problem is about the Snom phones after all). Since some weeks back (before we upgraded to the latest version of the SnomOne server) and continuing now after upgrade, phone calls are dropped every now and then (seems like 1 in 5 calls during the day) on all types of Snom phones. It is not exactly acceptable ... . This has only started to happen recently (as far as I can make out). Since the latest version of SnomOne started to make e-mail functionality working, I today also received a message when a call was dropped, but when I later today got a call from one of the users which also got dropped (I could not hear her, but she could hear me - voice out got cut), I received no message about this. So we have all sorts of problems going on here every hour. Here's the full log from the e-mail reporting the dropped call - (what phone and firmware that is used seems to be of no relevance as some are updated and some are not and all have problems now). The call between sip:031109430@opensips.teleman.com;user=phone and sip:0708442407@sip.teleman.com;user=phone has been disconnected because of media timeout (120 seconds), 390/7393 packets have been received/sent 2011/6/20 08:30:06 Rx: udp:213.131.156.66:0 (1055 bytes) INVITE sip:031109430@10.0.3.10:5060;transport=udp;line=c81e728d SIP/2.0 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKd1eb.5655e011.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-acf0121eefbbdd47-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: <sip:0708442407@212.3.0.165:5060;transport=udp> To: "031109430"<sip:031109430@opensips.teleman.com;user=phone> From: "0708442407"<sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 1 INVITE Allow: INVITE, ACK, BYE, CANCEL Content-Type: application/sdp User-Agent: LEICA-1.8.31.4 X-Ecan: On Content-Length: 352 v=0 o=- 691105141 0 IN IP4 213.50.90.4 s=- c=IN IP4 88.131.158.234 t=0 0 m=audio 40312 RTP/AVP 8 0 18 101 a=fmtp:18 annexb=yes a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 8 a=cdsc: 2 image udptl t38 a=cpar:T38FaxUdpEC:t38UDPRedundancy a=cpar:T38FaxVersion:0 a=cpar:T38MaxBitRate:14400 a=sendrecv 2011/6/20 08:30:06 Tx: udp:213.131.156.66:5060 (485 bytes) SIP/2.0 100 Trying Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKd1eb.5655e011.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-acf0121eefbbdd47-1---d8754z-;rport=5060 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> From: "0708442407" <sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a To: "031109430" <sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 1 INVITE Content-Length: 0 2011/6/20 08:30:06 Tx: udp:213.131.156.66:5060 (1071 bytes) SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKd1eb.5655e011.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-acf0121eefbbdd47-1---d8754z-;rport=5060 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> From: "0708442407" <sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a To: "031109430" <sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 1 INVITE Contact: <sip:031109430@10.0.3.10:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snom-PBX/2011-4.2.0.3981 Content-Type: application/sdp Content-Length: 302 v=0 o=- 653521262 653521262 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 57840 RTP/AVP 0 8 18 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv 2011/6/20 08:30:26 Tx: udp:213.131.156.66:5060 (1057 bytes) SIP/2.0 200 Ok Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKd1eb.5655e011.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-acf0121eefbbdd47-1---d8754z-;rport=5060 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> From: "0708442407" <sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a To: "031109430" <sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 1 INVITE Contact: <sip:031109430@10.0.3.10:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snom-PBX/2011-4.2.0.3981 Content-Type: application/sdp Content-Length: 302 v=0 o=- 653521262 653521262 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 57840 RTP/AVP 0 8 18 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:18 g729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv 2011/6/20 08:30:26 Rx: udp:213.131.156.66:0 (613 bytes) ACK sip:031109430@10.0.3.10:5060;transport=udp SIP/2.0 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKd1eb.5655e011.2 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-23e25602506f0c2b-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: <sip:0708442407@212.3.0.165:5060;transport=udp> To: "031109430"<sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba From: "0708442407"<sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 1 ACK Content-Length: 0 P-hint: rr-enforced 2011/6/20 08:30:26 Rx: udp:213.131.156.66:0 (1050 bytes) INVITE sip:031109430@10.0.3.10:5060;transport=udp SIP/2.0 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKa1eb.9d1e5d45.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-4e5cd45fb2852121-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: <sip:0708442407@212.3.0.165:5060;transport=udp> To: "031109430"<sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba From: "0708442407"<sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 2 INVITE Allow: INVITE, ACK, BYE, CANCEL Content-Type: application/sdp User-Agent: LEICA-1.8.31.4 X-Ecan: On Content-Length: 325 P-hint: rr-enforced v=0 o=- 691105141 1 IN IP4 213.50.90.4 s=- c=IN IP4 88.131.158.234 t=0 0 m=audio 40312 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 a=cdsc: 2 image udptl t38 a=cpar:T38FaxUdpEC:t38UDPRedundancy a=cpar:T38FaxVersion:0 a=cpar:T38MaxBitRate:14400 a=sendrecv 2011/6/20 08:30:26 Tx: udp:213.131.156.66:5060 (986 bytes) SIP/2.0 200 Ok Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKa1eb.9d1e5d45.0 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-4e5cd45fb2852121-1---d8754z-;rport=5060 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> From: "0708442407" <sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a To: "031109430" <sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 2 INVITE Contact: <sip:031109430@10.0.3.10:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: snom-PBX/2011-4.2.0.3981 Content-Type: application/sdp Content-Length: 231 v=0 o=- 653521262 653521262 IN IP4 10.0.3.10 s=- c=IN IP4 10.0.3.10 t=0 0 m=audio 57840 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv 2011/6/20 08:30:26 Rx: udp:213.131.156.66:0 (613 bytes) ACK sip:031109430@10.0.3.10:5060;transport=udp SIP/2.0 Record-Route: <sip:213.131.156.66;lr=on;ftag=252a9b6a> Via: SIP/2.0/UDP 213.131.156.66;branch=z9hG4bKa1eb.9d1e5d45.2 Via: SIP/2.0/UDP 212.3.0.165:5060;branch=z9hG4bK-d8754z-ee1c8d3d713a886d-1---d8754z-;rport=5060 Max-Forwards: 69 Contact: <sip:0708442407@212.3.0.165:5060;transport=udp> To: "031109430"<sip:031109430@opensips.teleman.com;user=phone>;tag=5576c1abba From: "0708442407"<sip:0708442407@sip.teleman.com;user=phone>;tag=252a9b6a Call-ID: Y2YyOGYwYWQwYjcxNmZjODE4MmI5MzA1ZGM0OTY5MjU. CSeq: 2 ACK Content-Length: 0 P-hint: rr-enforced
  10. Think I did not give a good answer. First, I actually am totally clueless about what Provisioning is and how it works and if I use it or not. I think it pertains to how devices can get some some settings from somewhere else, but do not understand how this is supposed to work and do not know where to activate or deactivate it in case that should be relevant. Maybe this could explain why I have some problems at times with registering the mobile devices, but not sure. Maybe it could also change settings in inconsistent ways, but that seems unlikely as has not happened before. (Only account info and server address and phone specific settings are made on the Snom 320 and base stations, all general settings are made on the server. Only ringtones settings have been made directly on the mobile devices. Sometimes language settings has to be made at various places.) The m3 was somewhat easy to set up and get registered in the first place and has worked fine for ca. 2 months and before that for two years at another customer with firmware 1.0 (it was not possible to upgrade and I cannot figure out how to do it - the manual surely does not help anyway). Before I changed the group setting on the phone, the call was registered in the log on the base station, but was not visible on the phone itself. I can find no place to on either the server or the base station to set this setting ... (the base station for the m3 almost have no settings at all anyway (unlike for the m9)). Well, the outgoing voice is heard on the other side whether or not the speaker phone mode is activated, but in order to hear something on my side I have to press the speaker phone button. And, yes, to hear the other side when making an outgoing call one also has to press the speaker button. It is just strange that this happened precisely after I upgraded the server ... .
  11. I think it was provisoned ... (said something about it in the log - sorry for not being better on this, but only deals with these phones now and then). I am not 100% sure I was not inadvertently changing something when I played around with the settings both on the phone, on the web interface and then maybe something happened when resetting the base station and re-registering etc.) - anyway found that setting. I suspect the problem really came down to a damaged internal speaker, since I have to press the speaker button for every phone call now in order to hear anything, but given that I put on the external speaker, the phone now works otherwise well. They still have problem with calls that are cut on some phones, calls that are not forwarded and instead directed to the Voice mail, bad quality of voice, bad operating distance for the esp. the m9 phones, calls where one side stops hearing, etc. Many of these problems could likely be handled if the phones were in the hands of computer savvy people, but they are not and thus complaints are common and difficult to get a good solution for. The stationary phones (Snom 320 works much more reliably). There might have been some new network problems recently as I also experienced a strange "locking" when remote controlling the server, but could see it ping an external server quite normally while my session was "held up" - will need to know first if the SnomOne update helped or not. For some reason things always works better when I am present ... ;-).
  12. Should also note that the e-mail messaging now magically started to work again after applying the latest upgrade to the SnomOne.
  13. Well, somehow it had unregistered itself from the call group in that setting on the phone. Still I have to press the speaker phone on each call in order to receive any incoming voice - can't find a solution to that, but maybe the internal speaker has died or something ... .
  14. The m3 registers incoming calls, but does not ring or show that someone is trying to call it ... maybe that what one has to live with in order to get incoming voice ... hmm.
  15. I think the problem was simply that they had pushed the speaker phone button on the side, which had muted all incoming sound ... why and how it can do so I do not know, but apparently this is how it works here ... . However, now that incoming voice can be heard on the handset, it can no longer receive incoming calls ... (Will try and restart the SnomOne server, because that is about the only thing I have not tried.) Managing to register a handset (either m3 & m9) always involves magic and rites ... but usually works after some hours ... .
  16. Yes, we have Snom 320 phones there too on different connections and one on the same connection as the m3. When the m3 did not work they started to use the Snom 320 instead and it works perfectly in the same network and with the "same" setup.
  17. Upgrade went fine, but now they can only have voice one way on their Snom m3 telephone despite rebooting. Logs from the SnomOne: (outbound call - both inbound and outbound works the same way, the person on the Snom m3 hears nothing, but the person on a phone not on this system hears everything): [8] 2011/06/15 14:47:10: Could not find a trunk (7 trunks) [7] 2011/06/15 14:47:10: Set packet length to 20 [6] 2011/06/15 14:47:10: Sending RTP for GL6VyB8alxudabhc7FP7wMMq@[server] to [client]:5008, codec not set yet [8] 2011/06/15 14:47:10: Call from an user 40 [8] 2011/06/15 14:47:10: To is <sip:0317018939@[server]>, user 0, domain 1 [8] 2011/06/15 14:47:10: From user 40 [8] 2011/06/15 14:47:10: Set the To domain based on From user 40@[server] [8] 2011/06/15 14:47:10: Call state for call object 54: idle [5] 2011/06/15 14:47:10: Dialplan "Company": Match 0317018939@[server] to <sip:0317018939@sip.voicetech.se;user=phone> on trunk Voicetech-031109428 [5] 2011/06/15 14:47:10: Charge user 40 for redirecting calls [8] 2011/06/15 14:47:10: Play audio_moh/noise.wav [7] 2011/06/15 14:47:10: set_codecs: for GL6VyB8alxudabhc7FP7wMMq@[server] codecs "", codec_preference count 7 [1] 2011/06/15 14:47:10: UDP: TOS could not be set [1] 2011/06/15 14:47:10: Last message repeated 2 times [7] 2011/06/15 14:47:10: set_codecs: for 7adcf6b2@pbx codecs "", codec_preference count 7 [7] 2011/06/15 14:47:10: Set packet length to 20 [6] 2011/06/15 14:47:10: Codec pcmu/8000 is chosen for call id GL6VyB8alxudabhc7FP7wMMq@[server] [8] 2011/06/15 14:47:10: DNS: Add NAPTR sip.voicetech.se (ttl=60) [8] 2011/06/15 14:47:10: DNS: Add SRV _sips._tcp.sip.voicetech.se (ttl=60) [8] 2011/06/15 14:47:10: DNS: Add SRV _sip._tcp.sip.voicetech.se (ttl=60) [8] 2011/06/15 14:47:10: DNS: Add SRV _sip._udp.sip.voicetech.se (ttl=60) [8] 2011/06/15 14:47:10: DNS: Add AAAA sip.voicetech.se (ttl=60) [8] 2011/06/15 14:47:10: Answer challenge with username 031109428 [8] 2011/06/15 14:47:10: Packet authenticated by transport layer [6] 2011/06/15 14:47:11: Sending RTP for 7adcf6b2@pbx to 213.50.91.3:40444, codec not set yet [6] 2011/06/15 14:47:11: Codec pcmu/8000 is chosen for call id 7adcf6b2@pbx [8] 2011/06/15 14:47:11: Call state for call object 54: alerting [7] 2011/06/15 14:47:11: GL6VyB8alxudabhc7FP7wMMq@[server]: RTP pass-through mode [7] 2011/06/15 14:47:11: 7adcf6b2@pbx: RTP pass-through mode [8] 2011/06/15 14:47:12: Packet authenticated by transport layer [8] 2011/06/15 14:47:18: Last message repeated 3 times [7] 2011/06/15 14:47:18: Call 7adcf6b2@pbx: Clear last INVITE [7] 2011/06/15 14:47:18: Determine pass-through mode after receiving response [8] 2011/06/15 14:47:18: Call state for call object 54: connected [8] 2011/06/15 14:47:20: Packet authenticated by transport layer [8] 2011/06/15 14:47:38: Last message repeated 4 times [7] 2011/06/15 14:47:38: 7adcf6b2@pbx: Media-aware pass-through mode [8] 2011/06/15 14:47:38: Hangup: Call 139 not found [8] 2011/06/15 14:47:38: Last message repeated 2 times [7] 2011/06/15 14:47:38: Call 7adcf6b2@pbx: Clear last request [5] 2011/06/15 14:47:38: BYE Response: Terminate 7adcf6b2@pbx On the phone log: 0101000242 [N](09):Outgoing Call from UA #0 (CallId #3) 0101000242 [N](09):Outgoing Call 3 answered 0101000242 [N](07):RTP Opened. Ch: 0, Len: 160, RxPort: 5008, TxPort: 57972 0101000242 [N](07):Codec routed to RTP Ch: 0, PCM Ch: 0, Codec Type: 0 0101000310 [N](ff):RTP Closed. Ch: 0 (I think this was from a similarly failed incoming call: 0101000000 [N](09):Registration of user 40 at UA #0 succeeded 0101000031 [N](09):Incoming call to UA #0 - given call id #1 0101000034 [N](07):RTP Opened. Ch: 0, Len: 160, RxPort: 5004, TxPort: 61382 0101000034 [N](07):Codec routed to RTP Ch: 0, PCM Ch: 0, Codec Type: 0 0101000041 [N](ff):RTP Closed. Ch: 0)
  18. I see that this is a different download page than the one where I found the DMG file. Can I use the files on the DMG mount as well and would I need to chmod those files too? I also see that you have included a 'snom ONE Admin' application for some reason .... what is the idea with that? Supposedly one is only supposed to put the SnomOne folder into the applications folder (and I guess that files elsewhere are installed upon launching, which is why this is only to be used for new installations, I guess ...). Just wondering and maybe someone else will ... . /Jerry
  19. Ah, was not looking carefully ... . Will see if the new version may be more stable ... . Thanks, Jerry
  20. Hi, Maybe there is some information on this, but cannot find it. On the downloads page it says the latest SnomOne DMG file is only for new installations, but what if one wants to upgrade? I find the current version we use to be quite unstable 4.2.0.3958 -- had to restart the server three times before it started to operate normally today. I notice that the Installation from the DMG makes things easy, but places files in totally different places from before on the Mac -- so the question is two-fold -- is the new version more stable and can one replace or move certain files around in order to upgrade? Thanks, Jerry
  21. eyeless

    Snom m9

    Hanged up after completing the previous post and then called again and then get many tones, so it seems like it has something to do with the ending/closing of the calls after they have been picked up, but what they do remains a mystery ... (or if this may just be random behaviour).
  22. eyeless

    Snom m9

    No, Intercom is not on. I get one signal on my side and then I get through and can hear everything on the other side, but they never hear a signal on their side and only hears me if I say something load enough. The behaviour was back now -- I was inspecting the phones and restarting them earlier today and then all worked fine (of course). The log from the m9: 2011/03/31 20:30:27 [sIP-Reg:5]: SIP Tx tls:10.0.3.10:5061: SUBSCRIBE sip:41@pbx.company.com SIP/2.0 Via: SIP/2.0/TLS 10.0.3.231:4228;branch=z9hG4bK-gw2esf;rport From: "Noaks Ark 29" <sip:41@pbx.company.com>;tag=5uy9iw To: "Noaks Ark 29" <sip:41@pbx.company.com> Call-ID: 5n6e66sb@snom CSeq: 15722 SUBSCRIBE Max-Forwards: 70 Contact: <sip:41@10.0.3.231:4228;transport=tls;line=48asmd>;reg-id=1;+sip.instance="<urn:uuid:d48a0e1e-bba2-4c33-a19a-5804d0708584>" Supported: outbound, gruu Event: message-summary Accept: application/simple-message-summary User-Agent: snom-m9/9.2.42-b Expires: 120 Content-Length: 0 2011/03/31 20:30:26 [sIP-Reg:5]: SIP Rx tls:10.0.3.10:5061: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.231:4228;branch=z9hG4bK-r3vgqe;rport=4228 From: "Noaks Ark" <sip:40@pbx.company.com>;tag=toa3ao To: "Noaks Ark" <sip:40@pbx.company.com>;tag=67f953fa50 Call-ID: 3ze5h53f@snom CSeq: 7067 SUBSCRIBE Contact: <sip:10.0.3.10:5061;transport=tls> Require: outbound Expires: 120 Content-Length: 0 2011/03/31 20:30:26 [sIP-Reg:5]: SIP Tx tls:10.0.3.10:5061: SUBSCRIBE sip:40@pbx.company.com SIP/2.0 Via: SIP/2.0/TLS 10.0.3.231:4228;branch=z9hG4bK-r3vgqe;rport From: "Noaks Ark" <sip:40@pbx.company.com>;tag=toa3ao To: "Noaks Ark" <sip:40@pbx.company.com> Call-ID: 3ze5h53f@snom CSeq: 7067 SUBSCRIBE Max-Forwards: 70 Contact: <sip:40@10.0.3.231:4228;transport=tls;line=54j08s>;reg-id=1;+sip.instance="<urn:uuid:475442e6-c2c3-4b7f-a6bd-2be1849f0a0b>" Supported: outbound, gruu Event: message-summary Accept: application/simple-message-summary User-Agent: snom-m9/9.2.42-b Expires: 120 Content-Length: 0 2011/03/31 20:30:14 [sIP-Call:5]: SIP Rx tls:10.0.3.10:5061: ACK sip:40@10.0.3.231:4228;transport=tls;line=6tb41i SIP/2.0 Via: SIP/2.0/TLS 10.0.3.10:5061;branch=z9hG4bK-7dac033c448ca302ec96fad6439d558e;rport From: "Anonymous" <sip:anonymous@10.0.3.10;user=phone>;tag=1081400685 To: "Noaks Ark" <sip:40@10.0.3.10>;tag=pdkdqy Call-ID: e519427a@pbx CSeq: 16426 ACK Max-Forwards: 70 Contact: <sip:40@10.0.3.10:5061;transport=tls> Content-Length: 0 2011/03/31 20:30:14 [sIP-Call:5]: SIP Tx tls:10.0.3.10:5061: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.10:5061;branch=z9hG4bK-b95f12d24d36faf9b7bb6131074719e0;rport=5061 From: "Anonymous" <sip:anonymous@10.0.3.10;user=phone>;tag=1081400685 To: "Noaks Ark" <sip:40@10.0.3.10>;tag=pdkdqy Call-ID: e519427a@pbx CSeq: 16426 INVITE Contact: <sip:40@10.0.3.231:4228;transport=tls;line=6tb41i> Supported: 100rel, replaces, norefersub User-Agent: snom-m9/9.2.42-b Content-Type: application/sdp Content-Length: 303 v=0 o=root 181735547 181735548 IN IP4 10.0.3.231 s=- c=IN IP4 10.0.3.231 t=0 0 m=audio 61490 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp-xr:rcvr-rtt=all voip-metrics a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:5U9Whv7bgZbRLzPV8JiAKB7bWpJyc7hYNvmtNgN7|2^31 a=sendrecv 2011/03/31 20:30:14 [DECT:5]: Send Call Status: encrypted 2011/03/31 20:30:14 [DECT:5]: hanset 3 picked up the call 2011/03/31 20:30:13 [sIP-Call:5]: SIP Tx tls:10.0.3.10:5061: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.10:5061;branch=z9hG4bK-e720444c43d23cdf46ca8876f3bd7cab;rport=5061 From: "Anonymous" <sip:anonymous@10.0.3.10;user=phone>;tag=1081400685 To: "Noaks Ark" <sip:40@10.0.3.10>;tag=pdkdqy Call-ID: e519427a@pbx CSeq: 16427 PRACK Contact: <sip:40@10.0.3.231:4228;transport=tls;line=6tb41i> Supported: 100rel, replaces, norefersub Content-Length: 0 _________ "hanset 3" seems to be good on picking up calls and I guess we will have to replace it .... .
  23. eyeless

    Snom m9

    I will also try and inspect the handset (maybe it is only one, not quite sure yet) -- might be some mechanical problem ... .
  24. eyeless

    Snom m9

    Hmm -- yes, one problem we realised after getting the m9s was that the customer in question really need long range connections and they are no good in that respect and apparently there are no "repeaters" available either. Another problem is probably the users -- nursery employees, where they have to play with kids outside and still need their phones with them .... . DND - ah, I forgot how to change that on the m9s -- so then I know for sure it is on their Snom 320 (on the same extension) where they have fiddled with the button ... maybe I could disable it ... . But the main problem here is calls going through without anyone picking up the handsets and that creates a security problem which is very important (crucial) here. /Jerry
  25. eyeless

    Snom m9

    Hi, We have problem with (as it seems) only m9 handsets picking up incoming calls without anyone doing anything. Thus the user can only accept incoming calls by hearing a someone shouting "is anyone there" on the other end. A restart of the base station helps, but we cannot do that several times a day. Here is the log on the phone side: 2011/03/30 16:09:38 [sIP-Call:5]: SIP Tx tls:10.0.3.10:5061: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.10:5061;branch=z9hG4bK-96ce8b1a3be25e5b4a1162c64e04f6ec;rport=5061 From: "Anonymous" <sip:anonymous@10.0.3.10;user=phone>;tag=414020219 To: "Noaks Ark" <sip:40@10.0.3.10>;tag=bc65ma Call-ID: a418de07@pbx CSeq: 30181 INVITE Contact: <sip:40@10.0.3.231:4228;transport=tls;line=mfhmb9> Supported: 100rel, replaces, norefersub User-Agent: snom-m9/9.2.42-b Content-Type: application/sdp Content-Length: 305 v=0 o=root 1282523677 1282523678 IN IP4 10.0.3.231 s=- c=IN IP4 10.0.3.231 t=0 0 m=audio 54836 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtcp-xr:rcvr-rtt=all voip-metrics a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:BFLvj6eg7F0KU1MjKryxLq7Vutxvf+QrdVsD4Kxp|2^31 a=sendrecv 2011/03/30 16:09:38 [DECT:5]: Send Call Status: encrypted 2011/03/30 16:09:38 [DECT:5]: hanset 3 picked up the call 2011/03/30 16:09:37 [sIP-Call:5]: SIP Tx tls:10.0.3.10:5061: SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.0.3.10:5061;branch=z9hG4bK-e84a2d62b187fe9e1bf655a18a22e769;rport=5061 From: "Anonymous" <sip:anonymous@10.0.3.10;user=phone>;tag=414020219 To: "Noaks Ark" <sip:40@10.0.3.10>;tag=bc65ma Call-ID: a418de07@pbx CSeq: 30182 PRACK Contact: <sip:40@10.0.3.231:4228;transport=tls;line=mfhmb9> Supported: 100rel, replaces, norefersub Content-Length: 0 And here is the SnomOne server log: [7] 2011/03/30 16:09:35: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: codec_preference size 7, available codecs size 4 [8] 2011/03/30 16:09:35: Play audio_se/ringback.wav [6] 2011/03/30 16:09:35: Codec pcmu/8000 is chosen for call id ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y. [7] 2011/03/30 16:09:35: Call a418de07@pbx: Clear last request [7] 2011/03/30 16:09:35: Call c4a9c5be@pbx: Clear last request [8] 2011/03/30 16:09:36: Packet authenticated by transport layer [7] 2011/03/30 16:09:37: Call a418de07@pbx: Clear last INVITE [6] 2011/03/30 16:09:37: Codec pcmu/8000 is chosen for call id a418de07@pbx [6] 2011/03/30 16:09:37: Sending RTP for a418de07@pbx to 10.0.3.231:54836, codec pcmu/8000 [7] 2011/03/30 16:09:37: Determine pass-through mode after receiving response [8] 2011/03/30 16:09:37: Call state for call object 556: connected [7] 2011/03/30 16:09:37: ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: RTP pass-through mode [7] 2011/03/30 16:09:37: a418de07@pbx: RTP pass-through mode [7] 2011/03/30 16:09:37: Call c4a9c5be@pbx: Clear last request [7] 2011/03/30 16:09:37: Call c4a9c5be@pbx: Clear last INVITE [5] 2011/03/30 16:09:37: INVITE Response 487 Request Terminated: Terminate c4a9c5be@pbx [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: adding codec pcmu/8000 to available list [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: Other side does not support codec pcma/8000 [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: Other side does not support codec g722/8000 [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: Other side does not support codec g729/8000 [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: Other side does not support codec g726-32/8000 [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: Other side does not support codec gsm/8000 [7] 2011/03/30 16:09:37: update_codecs for ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y.: codec_preference size 7, available codecs size 2 [6] 2011/03/30 16:09:37: Codec pcmu/8000 is chosen for call id ZjQ3ZWVkMTQ1YmFmMzgxZjk1NmJjMTgwMjEzZjE5Y2Y. [6] 2011/03/30 16:09:37: Call hold from trunk [8] 2011/03/30 16:09:37: Packet authenticated by transport layer [8] 2011/03/30 16:09:37: SRTP MAC mismatch: a5fa72d9 != df10d397 [7] 2011/03/30 16:09:37: Discard SRTCP packet from 10.0.3.231:54837 with wrong MAC [8] 2011/03/30 16:09:38: Packet authenticated by transport layer [8] 2011/03/30 16:09:39: Last message repeated 3 times [8] 2011/03/30 16:09:39: SRTP MAC mismatch: e815da8b != 5e45a75f [7] 2011/03/30 16:09:39: Discard SRTCP packet from 10.0.3.231:54837 with wrong MAC [8] 2011/03/30 16:09:40: Packet authenticated by transport layer (not sure if I cut that right). Any idea? It could well be that the people using the phones have hit a button by mistake, but it is not the reply button when one is calling as they never hears any signals in the first place. (But they have managed to activate DND by mistake a number of times.) I cannot figure out what is going on though ... . Thanks, Jerry
×
×
  • Create New...