lirees Posted January 14, 2011 Report Share Posted January 14, 2011 i need to forwarding to Cell Phone on a different stages ... i explain ... stage 1 call the cell phone 123456789 after 20 sec if not responding go to the stage 2 and call the cell phone 987654321 after 20 sec go to the stage 3 ecc... i tried to make it with the hunt group but the forward does not go over the first stage ... ring only the first cell phone .. i tried to insert the extension in the stage of the hunt group rather the number of the cell phone and i have enabled the "When calling the extension in a hunt group" under redirection parameters but nothing change ... only the first cell phone ring it is a bug of the snom one ??? someone can give me some advice please ? thanks Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 14, 2011 Report Share Posted January 14, 2011 What version are you on? Does it work with no cell phones involved (just regular extensions with no cell phone forwarding)? Quote Link to comment Share on other sites More sharing options...
lirees Posted January 18, 2011 Author Report Share Posted January 18, 2011 What version are you on? Does it work with no cell phones involved (just regular extensions with no cell phone forwarding)? hi, my version is 4.2.0.3974 on centos 32bit, if i insert the extensions in the stages there is not problem, also if i use the my voip provider there is not problem... the issue appears when i use the isdn line connected with the snom one through the patton 4554 !!! is a configuration problem or a problem of telecom ? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 19, 2011 Report Share Posted January 19, 2011 Well the problem could be that the call connects as soon as you dial the number, then the hunt group would obviously stop. For example, when calling the cell phone the mailbox could pick up. Terminating traffic in the analog world is not so wasy and many gateways send the connected signal immediatly (you will still just hear ringback tone); that's because it is so hard to figure out if the call is connected or not in the analog world. You can check in the SIP messages if the gateway sends a 200 Ok response on the INVITE request. Quote Link to comment Share on other sites More sharing options...
lirees Posted January 20, 2011 Author Report Share Posted January 20, 2011 Well the problem could be that the call connects as soon as you dial the number, then the hunt group would obviously stop. For example, when calling the cell phone the mailbox could pick up. Terminating traffic in the analog world is not so wasy and many gateways send the connected signal immediatly (you will still just hear ringback tone); that's because it is so hard to figure out if the call is connected or not in the analog world. You can check in the SIP messages if the gateway sends a 200 Ok response on the INVITE request. in fact ... after the invite message there is not the "OK" but the there is the "100 trying" message So the only solution is to use a voip provider ? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 20, 2011 Report Share Posted January 20, 2011 Well 100 Trying is typically not the last result you will see coming from the gateway. Search for other messages with the same "Call-ID". If you see a code between 180 and 199 then you will hear ringback (which is good), if you see a 200 code that means the call got connected (not good if is comes right after the INVITE request was sent out). VoIP providers are usually better as they dont have to run the calls through analog lines, which makes it a lot easier to find out if the call got connected. That is actually a killer reason IMHO for SIP trunking. You know when the call actually got connected... Quote Link to comment Share on other sites More sharing options...
lirees Posted January 29, 2011 Author Report Share Posted January 29, 2011 Well 100 Trying is typically not the last result you will see coming from the gateway. Search for other messages with the same "Call-ID". If you see a code between 180 and 199 then you will hear ringback (which is good), if you see a 200 code that means the call got connected (not good if is comes right after the INVITE request was sent out). VoIP providers are usually better as they dont have to run the calls through analog lines, which makes it a lot easier to find out if the call got connected. That is actually a killer reason IMHO for SIP trunking. You know when the call actually got connected... this is the complete message sip when i try to call from a ext to a hunt gruop with two different cell phone setting in the first e second stage : the isdn patton smart node 4554 is configured without autentication with the snom one, may depend from this ? [7] 2011/01/29 12:00:01: SIP Rx tls:172.16.10.37:2070: INVITE sip:71@172.16.10.201;user=phone SIP/2.0 Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-pz055tq2tqgw;rport From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone> Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 1 INVITE Max-Forwards: 70 Contact: <sip:20@172.16.10.37:2070;transport=tls;line=2wbbgcc9>;reg-id=1 X-Serialnumber: 00041331A667 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: 524 v=0 o=root 1254679951 1254679951 IN IP4 172.16.10.37 s=call c=IN IP4 172.16.10.37 t=0 0 m=audio 57660 RTP/AVP 9 0 8 2 3 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:edjvoHy8AcFJNH2yvJpIQdW00KW3sVMc+/X2tupc 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 [7] 2011/01/29 12:00:01: SIP Tx tls:172.16.10.37:2070: SIP/2.0 100 Trying Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-pz055tq2tqgw;rport=2070 From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 1 INVITE Content-Length: 0 [7] 2011/01/29 12:00:01: SIP Tx tls:172.16.10.37:2070: SIP/2.0 183 Session Progress Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-pz055tq2tqgw;rport=2070 From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 1 INVITE Contact: <sip:20@172.16.10.200:5061;transport=tls> 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.3974 Require: 100rel RSeq: 1 Content-Type: application/sdp Content-Length: 429 v=0 o=- 1449931 1449931 IN IP4 172.16.10.201 s=- c=IN IP4 172.16.10.201 t=0 0 m=audio 58452 RTP/AVP 0 8 9 2 3 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:MeNKoVukSlSggKuXWOzmhNLuc8u1gfcTz80bJY8L a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 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 [7] 2011/01/29 12:00:01: SIP Tx udp:172.16.10.205:5060: INVITE sip:348xxxxxxx@172.16.10.205:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 172.16.10.200:5060;branch=z9hG4bK-a433dfa59d493e40369041e8a83b99e7;rport From: "Int 20" <sip:20@172.16.10.201;user=phone>;tag=356689874 To: <sip:348xxxxxxx@172.16.10.205:5060;user=phone> Call-ID: 19ebdeb8@pbx CSeq: 29855 INVITE Max-Forwards: 70 Contact: <sip:039xxxxxxxx@172.16.10.200: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.3974 P-Asserted-Identity: "Isdn" <sip:039xxxxxxxx@172.16.10.205:5060> Content-Type: application/sdp Content-Length: 265 v=0 o=- 1949439694 1949439694 IN IP4 172.16.10.201 s=- c=IN IP4 172.16.10.201 t=0 0 m=audio 56242 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv [7] 2011/01/29 12:00:01: SIP Rx tls:172.16.10.37:2070: PRACK sip:20@172.16.10.200:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-zzk68e8yqt22;rport From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 2 PRACK Max-Forwards: 70 Contact: <sip:20@172.16.10.37:2070;transport=tls;line=2wbbgcc9>;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 [7] 2011/01/29 12:00:01: SIP Tx tls:172.16.10.37:2070: SIP/2.0 200 Ok Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-zzk68e8yqt22;rport=2070 From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 2 PRACK Contact: <sip:20@172.16.10.200:5061;transport=tls> User-Agent: snom-PBX/2011-4.2.0.3974 Content-Length: 0 [7] 2011/01/29 12:00:01: SIP Rx udp:172.16.10.205:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 172.16.10.200:5060;branch=z9hG4bK-a433dfa59d493e40369041e8a83b99e7;rport=5060;received=172.16.10.200 From: "Int 20" <sip:20@172.16.10.201;user=phone>;tag=356689874 To: <sip:348xxxxxxx@172.16.10.205:5060;user=phone> Call-ID: 19ebdeb8@pbx CSeq: 29855 INVITE Server: Patton SN4554 2BIS EUI 00A0BA05EA30 R5.5 2010-09-03 SIP M5T SIP Stack/4.0.28.28 Content-Length: 0 [7] 2011/01/29 12:00:05: SIP Rx udp:172.16.10.205:5060: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 172.16.10.200:5060;branch=z9hG4bK-a433dfa59d493e40369041e8a83b99e7;rport=5060;received=172.16.10.200 From: "Int 20" <sip:20@172.16.10.201;user=phone>;tag=356689874 To: <sip:348xxxxxxx@172.16.10.205:5060;user=phone>;tag=1624736971 Call-ID: 19ebdeb8@pbx CSeq: 29855 INVITE Contact: <sip:348xxxxxxx@172.16.10.205:5060> Server: Patton SN4554 2BIS EUI 00A0BA05EA30 R5.5 2010-09-03 SIP M5T SIP Stack/4.0.28.28 Content-Length: 0 [7] 2011/01/29 12:00:08: SIP Rx udp:172.16.10.205:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.10.200:5060;branch=z9hG4bK-a433dfa59d493e40369041e8a83b99e7;rport=5060;received=172.16.10.200 From: "Int 20" <sip:20@172.16.10.201;user=phone>;tag=356689874 To: <sip:348xxxxxxx@172.16.10.205:5060;user=phone>;tag=1624736971 Call-ID: 19ebdeb8@pbx CSeq: 29855 INVITE Contact: <sip:348xxxxxxx@172.16.10.205:5060> Server: Patton SN4554 2BIS EUI 00A0BA05EA30 R5.5 2010-09-03 SIP M5T SIP Stack/4.0.28.28 Supported: replaces Content-Type: application/sdp Content-Length: 221 v=0 o=MxSIP 0 43 IN IP4 172.16.10.205 s=SIP Call c=IN IP4 172.16.10.205 t=0 0 m=audio 4948 RTP/AVP 0 8 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv [7] 2011/01/29 12:00:08: Call 19ebdeb8@pbx: Clear last INVITE [7] 2011/01/29 12:00:08: SIP Tx udp:172.16.10.205:5060: ACK sip:348xxxxxxx@172.16.10.205:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.10.200:5060;branch=z9hG4bK-6fdeb9310a1a93e0390932bb5b0ca802;rport From: "Int 20" <sip:20@172.16.10.201;user=phone>;tag=356689874 To: <sip:348xxxxxxx@172.16.10.205:5060;user=phone>;tag=1624736971 Call-ID: 19ebdeb8@pbx CSeq: 29855 ACK Max-Forwards: 70 Contact: <sip:039xxxxxxxx@172.16.10.200:5060;transport=udp> P-Asserted-Identity: "Isdn" <sip:039xxxxxxxx@172.16.10.205:5060> Content-Length: 0 [7] 2011/01/29 12:00:08: SIP Tx tls:172.16.10.37:2070: SIP/2.0 200 Ok Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-pz055tq2tqgw;rport=2070 From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 1 INVITE Contact: <sip:20@172.16.10.200:5061;transport=tls> 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.3974 Content-Type: application/sdp Content-Length: 429 v=0 o=- 1449931 1449931 IN IP4 172.16.10.201 s=- c=IN IP4 172.16.10.201 t=0 0 m=audio 58452 RTP/AVP 0 8 9 2 3 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:MeNKoVukSlSggKuXWOzmhNLuc8u1gfcTz80bJY8L a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 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 [7] 2011/01/29 12:00:09: SIP Rx tls:172.16.10.37:2070: ACK sip:20@172.16.10.200:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 172.16.10.37:2070;branch=z9hG4bK-lofu8rngdav2;rport From: "Int 20" <sip:20@172.16.10.201>;tag=hnoxz8pdmi To: <sip:71@172.16.10.201;user=phone>;tag=34bf619e2a Call-ID: 3c3486a9556c-w3p5he6qu0xz CSeq: 1 ACK Max-Forwards: 70 Contact: <sip:20@172.16.10.37:2070;transport=tls;line=2wbbgcc9>;reg-id=1 Proxy-Require: buttons Content-Length: 0 Quote Link to comment Share on other sites More sharing options...
pbx support Posted January 29, 2011 Report Share Posted January 29, 2011 Based on this trace, the call is connected. So there is no need to go to the next stage. If the gateway did not send the "200 OK", then PBX would have tried the next number after 20 seconds. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 30, 2011 Report Share Posted January 30, 2011 Why don't you use the "press 1 to accept the call" for the cell phones? in this case, don't put PSTN numbers into the hunt group, just the extensions. Then check that hunt groups may also call the extension's cell phone and tell the PBX to wait for the "1" confirmation tone from the cell phone. All set, even if the call goes to the cell phones mailbox it will still for connect such a call. Quote Link to comment Share on other sites More sharing options...
lirees Posted February 21, 2011 Author Report Share Posted February 21, 2011 Why don't you use the "press 1 to accept the call" for the cell phones? in this case, don't put PSTN numbers into the hunt group, just the extensions. Then check that hunt groups may also call the extension's cell phone and tell the PBX to wait for the "1" confirmation tone from the cell phone. All set, even if the call goes to the cell phones mailbox it will still for connect such a call. great ... it worked !!! thanks Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.