Re: [Freeswitch-users] is there something like flash operator panel for freeswitch?
None that I know of, but it should be fairly simple to create FOP for FS with the event socket. 2009/4/29 Antonio Gallo ga...@mctelefonia.com ok i did some test today using the yesterday's trunk with a gxp2010 and a snom360 both with 2 LEDS monitoring each other and themselves. Configuration: gxp2010 user: 1000 led1: 1000 led2: 1001 snom360 user: 1001 led1: 1000 led2: 1001 Problem with both phones: - when a phone reboot and it subscribe it does not get notified of the current status of the subscribed phones i.e. if gxp is on the phone the snom led1 is off/unlit i.e. if snom is on the phone the gxp led2 is off/unlit Problem with GXP only: - both subscribe LED stop working after a 1 or 2 calls until the gxp re-subscribe or re-register To skip using LED on phones is there is something like flash operator panel to display telephone status? Thanks in advance, Antonio (AGX) ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Low rtp-timeout-sec hangs up call in ringing state - expected behaviour?
Thanks! I'll notify them of the problem and see if there's a way around it. 2009/4/28 Anthony Minessale anthony.miness...@gmail.com as soon as FS sees 183 it expects media. if they send 183 and no media it will most certainly timeout On Tue, Apr 28, 2009 at 9:33 AM, Mikael Aleksander Bjerkeland mik...@bjerkeland.com wrote: The scenario I was referring to was actually an outbound call from a locally registered SIP phone to a cellphone. The same thing happens whether I use a SIP or PRI trunk. After 6 s it hangs up. I get SDP on 183 no matter whether I'm calling a cellphone or a fixed line. I also get ringing indication. The 183+sdp is passed on to the Nokia and after 6 s the call is hung up. Both the SIP and PRI trunks claim to send early media but there seems to be no audio/RTP. If I answer the call in 6 s it's not dropped because the media path was established before RTP timeout. The same thing happens on latest trunk. I added the debug line at 1520 and did make /etc/init.d/freeswitch stop make install /etc/init.d/freeswitch start but the debug line didn't show up anywhere in the CLI. Is my upstream provider doing something wrong in sending early media in these cases? Seems pretty odd. It can be avoided by setting a higher rtp-timeout-sec but it will still be an absolute timeout on ringing. A transcript of the log: send 1293 bytes to udp/[1.1.1.1]:5060 at 13:55:56.451865: INVITE sip:21651...@domain.appsvrslip11.prigw.comsip%3a21651...@domain.appsvrslip11.prigw.comSIP/2.0 Via: SIP/2.0/UDP 2.2.2.2;rport;branch=z9hG4bKm3t6teHv30rBK Route: sip:21651...@1.1.1.1 sip%3a21651...@1.1.1.1 Max-Forwards: 69 From: someone sip:23695...@2.2.2.2 sip%3a23695...@2.2.2.2 ;tag=m2SepeSZ63e3g To: sip:21651...@domain.appsvrslip11.prigw.comsip%3a21651...@domain.appsvrslip11.prigw.com Call-ID: 23302ac7-ae9f-122c-198f-001ec9e8d9bc CSeq: 114345142 INVITE Contact: sip:mod_so...@2.2.2.2:5060 User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-13175M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: timer, precondition, path, replaces Allow-Events: talk, presence, dialog, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 383 P-Asserted-Identity: someone sip:23695...@2.2.2.2sip%3a23695...@2.2.2.2 v=0 o=FreeSWITCH 3718974841365302606 4309079514688066219 IN IP4 2.2.2.2 s=FreeSWITCH c=IN IP4 2.2.2.2 t=0 0 m=audio 52706 RTP/AVP 9 8 0 3 101 13 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 m=video 52752 RTP/AVP 99 a=rtpmap:99 H264/9 2009-04-28 15:55:56 [DEBUG] sofia.c:2912 sofia_handle_sip_i_state() Channel sofia/external-eth1/21651...@domain.appsvrslip11.prigw.com;fs_path= sip:21651...@1.1.1.1 sip%3a21651...@1.1.1.1 entering state [calling][0] recv 305 bytes from udp/[1.1.1.1]:5060 at 13:55:56.482864: SIP/2.0 100 Trying From: someonesip:23695...@2.2.2.2 sip%3a23695...@2.2.2.2 ;tag=m2SepeSZ63e3g To: sip:21651...@domain.appsvrslip11.prigw.comsip%3a21651...@domain.appsvrslip11.prigw.com Call-ID: 23302ac7-ae9f-122c-198f-001ec9e8d9bc CSeq: 114345142 INVITE Via: SIP/2.0/UDP 2.2.2.2;rport=5060;branch=z9hG4bKm3t6teHv30rBK Content-Length: 0 recv 1035 bytes from udp/[1.1.1.1]:5060 at 13:55:58.296906: SIP/2.0 183 Session Progress From: someonesip:23695...@2.2.2.2 sip%3a23695...@2.2.2.2 ;tag=m2SepeSZ63e3g To: sip:21651...@domain.appsvrslip11.prigw.comsip%3a21651...@domain.appsvrslip11.prigw.com ;tag=20134330840200942815366 Call-ID: 23302ac7-ae9f-122c-198f-001ec9e8d9bc CSeq: 114345142 INVITE Via: SIP/2.0/UDP 2.2.2.2;rport=5060;branch=z9hG4bKm3t6teHv30rBK content-type: application/sdp contact: sip:1.1.1.1:5060;nt_end_pt=YM0 +~K!-.f0vfc830~P68.cio~H9zwgW0VyisWTdcaM26c610Xbo1.nfS.5NQt3mO~~70!-.f0vft815;nt_server_host=1.1.1.1 supported: 100rel x-nt-party-id: -/ allow: ACK allow: BYE allow: CANCEL allow: INVITE allow: OPTIONS allow: INFO allow: SUBSCRIBE allow: REFER allow: NOTIFY allow: PRACK server: CS2000_NGSS/9.0 Content-Length: 300 v=0 o=IWSPM 573585738 573585738 IN IP4 84.20.97.100 s=- e=unkn...@invalid.net t=0 0 m=audio 45954 RTP/AVP 8 0 18 101 c=IN IP4 84.20.97.100 a=ptime:20 a=fmtp:18 annexb=no
Re: [Freeswitch-users] Behaviour for SIP Contact header without ; transport=
Yeah, that's what's happening, but is it the expected behaviour? It seems to me that either FS or Nokia's doing something wrong here, otherwise Transport Type: Auto is useless unless UDP is the lowest weight in the NAPTR record, since incoming calls will fail when registered with TCP if != transport=TCP. 2009/4/24 Michael Jerris m...@jerris.com If you don't include the transport= in the message, the reply to that register should still go back on tcp, but the calls to that registered endpoint will go on upd. Mike On Apr 24, 2009, at 6:19 AM, Mikael Aleksander Bjerkeland wrote: Hi, I'm registering a Nokia N82 with FreeSWITCH, where the hostname has NAPTR and SRV records pointing to the server in the following order: TLS, TCP and UDP. If I set my Nokia phone to use transport type: Auto it registers to FS with TCP, but it doesn't have transport=TCP in the Contact header. FS receives SIP messages from the phone in TCP but replies in UDP due to the Contact missing transport=TCP. The phone doesn't acknowledge any UDP traffic since it initially registered with TCP. If I change transport type to either TCP or UDP things start to work as the phone adds the appropriate ;transport= tag. Is this the expected behaviour? Is FS or the phone doing something wrong here? Should a UAS assume transport=TCP if the initial traffic (REGISTER) is TCP and the transport= tag is missing? ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] ENUM lookup and simultaneous dialing
Do we really need a config option to let the user choose? If the ENUM lookup returns several records with identical order and preference isn't it implied that the records are equal? IMHO the config option you are referring to is already in the BIND zone file and is called the Order and Preference on a NAPTR record. Excerpt from RFC 3761: In the case where the zone authority wishes to state that two Rules have the same effect or are identical in usage, then the Order for those records is set to the same value. In that case, the Preference is used to specify a locally over-ridable suggestion by the zone authority that one Rule might simply be better than another for some reason. What about: If the preference differs, don't dial simultaneously but chained, in the preferred (Preference) order? I am just concerned about whether the RFC _ALLOWS_ ENUM records with identical Types AND identical Order. Can someone shed some light on this? If these goals can be reached ENUM lookups may be used to route a called number to one or more devices at the same time with optional fallbacks and thanks to DNS it would be distributed. Hunt-groups / Follow-Me could be done just by using ENUM. Example: Order 1 [EMAIL PROTECTED] Order 1 [EMAIL PROTECTED] Order 2 [EMAIL PROTECTED] Would result in this dialstring: [EMAIL PROTECTED],[EMAIL PROTECTED]|[EMAIL PROTECTED] Is this valid per the RFC? On Tue, April 8, 2008 17:24, Michael Jerris wrote: I'm not sure its obvious what our behavior should be here. Maybe a config option to choose? Mike On Apr 8, 2008, at 10:16 AM, Anthony Minessale wrote: Good question, I think it's more of a really, can you do that? On Tue, Apr 8, 2008 at 8:21 AM, Mikael A. Bjerkeland [EMAIL PROTECTED] wrote: When doing an enum lookup where a number has two NAPTR records with the same preference and order enum_auto_route gets set to: sofia/gateway/openser/[EMAIL PROTECTED]| sofia/gateway/openser/[EMAIL PROTECTED] The | sets the dialstring for chained dialing. If the order and pref is identical for both records, shouldn't the dialstring be using , to call both simultaneously? Is this a feature or a bug? Regards, Mikael ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:[EMAIL PROTECTED] GTALK/JABBER/PAYPAL:[EMAIL PROTECTED] IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[EMAIL PROTECTED] iax:[EMAIL PROTECTED]/888 googletalk:[EMAIL PROTECTED] pstn:213-799-1400 ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
