gmane.comp.voip.sipx.devel

Re: Fax through sipxbridge issue -- re-INIVTE changes receive port.

Andy Spitzer — 2008-10-07T21:17:47

Woof! On Tue, 07 Oct 2008 13:30:15 -0400, M. Ranganathan gmail.com> wrote: CED is the 2100 Hz tone the recieving fax machine emits when it goes to answer a call. It tells the calling FAX machine that a fax machine answered, and not a person. The trouble is CED is the exact same frequency that data modems use (it was actually intended to trigger the disabling of echo cancelation). Some devices like credit card swipers still use dialup, so switching to T.38 on CED might cause the gateway to incorrectly switch to T.38 on data calls. The PREAMBLE is the V.21 training sequence the two Fax modems send to each other to exchange capabilities. This is different from data modem tones (well, not if you still use 300 baud modems) so it is much safer to trigger on. It takes longer to get to PREAMBLE (both sides have to realize the other can hear them), so it might just be a timing thing that it didn't work. --Woof!

Re: Fax through sipxbridge issue -- re-INIVTE changesreceive port.

M. Ranganathan — 2008-10-07T17:30:15

Excellent! Yes that all worked as you describe it. In order to get it to work though, I had to do something that I don't fully understand. What is the difference between : Detect T38 on CED vs. Detect T38 on PRE-AMBLE ? The former did the trick, whereas the latter did not. I think I need a quick primer on how T38 works with SIP. If you have a good pointer to SIP + T38, please share it. Thanks! Ranga

Re: Fax through sipxbridge issue -- re-INIVTE changes receive port.

Andy Spitzer — 2008-10-07T17:21:00

Woof! On Tue, 07 Oct 2008 12:31:43 -0400, M. Ranganathan gmail.com> wrote: I don't see that. The origin field in the first invite is: o=AudiocodesGW 714893621 714893506 IN IP4 192.168.6.201 -----------------------------^ And in the second invite is: o=AudiocodesGW 714893621 714893507 IN IP4 192.168.6.201 -----------------------------^ The session id is the same, and the session version is increased as it is supposed to be, indicating a change in SDP. Nope. Drop the old, open the new. Stop sending to G.711 to 6000. Start sending T.38 to 6002. No. T.38 doesn't use RTP. It uses "udptl" which doesn't have the 2nd port or even number port (if I recall correctly) restrictions of RTP. m=image 6002 udptl t38 --------------^ --Woof!

Re: DTMF transport incompatibility

Andy Spitzer — 2008-10-07T16:54:33

Woof! On Tue, 07 Oct 2008 11:00:32 -0400, Scott Lawrence nortel.com> wrote: Seems plausable...do we just flat out reject all IVR calls unless 2833 is offered? That's seems easy enough. But if you want to allow SOME calls, such as those leaving a VM might don't need to press any digits at all, whereas those picking up message MUST have 2833, would be a bit trickier. --Woof!

Re: ITSP test

Scott Lawrence — 2008-10-07T16:35:16

On Tue, 2008-10-07 at 11:43 -0400, M. Ranganathan wrote: I just checked in the change to the minor version numbers... the next successful builds will update the web site.

Fax through sipxbridge issue -- re-INIVTE changesreceive port.

M. Ranganathan — 2008-10-07T16:31:43

Hello, I am testing sending of FAX via sipxbridge. I find that the Audiocodes INVITEs using G711 offer and then Re-INVITEs using a t38 offer but now with a different receive port. However, the session ID for the SDP is the same. Does this mean there are actually separate receive ports associated with the same session? Attached is the merged.xml which would clarify the situation. Note on Frame 1, Audiocodes wants to receive on Port 6000 Then on Frame 28 Audiocodes re-INVITES within the same dialog but now it wants to receive on port 6002. What happens to the data that was destined to port 6000 at this point? I ask because in the context of sipxbridge, I want to know whether or not to create a second bridge for this port. Second, do I need RTCP support for fax? Thank you! Ranga

Re: ITSP test

M. Ranganathan — 2008-10-07T15:43:02

You will be seeing 3.11.7.xxx very soon. 3.11.6.013604 should be good for you to examine. Please read the instructions on the wiki page on how to set up and please share your settings with the community ( send me your settings without any sensitive information and I will update the wiki page). http://sipx-wiki.calivia.com/index.php/SIP_Trunking_with_sipXecs:_Overview_and_Configuration The screen shots are slightly dated. Will be revised after we finalize things. There is also a suggested set of tests here: http://www.sipfoundry.org/images/sipxbridge-regression-tests.xls Note that the tests above are preliminary. Thanks! Regards Ranga

Re: ITSP test

xavier houghton — 2008-10-07T15:21:53

HI Ranga - thnaks for that but i can´t find the build you are talking about. I´ve looked in http://sipxecs.sipfoundry.org/temp/sipXecs/main/ but all i can see are src files and rpms relating to 3.11.6 looking at http://sipxecs.sipfoundry.org/build/ i can see that the latest ISO build 51 was completed 07 oct at 01:09 - this seems to tie in to the iso file 3.11.4 in http://sipxecs.sipfoundry.org/temp/sipXecs/ISO/ which was updated at the same time. i can also see ecs-centos5 latest build 75 ties in time wise with 3.11.6 in http://sipxecs.sipfoundry.org/temp/sipXecs/main/CentOS/5/i386/RPM/ and has the same revision number in the file name 008781. are we currently at 3.11.6.xxxx which means i use the rpms in http://sipxecs.sipfoundry.org/temp/sipXecs/main/CentOS/5/i386/RPM/ or is there some sort of file naming issue which means that i can use either the rpms or the iso. thanks xavier M. Ranganathan wrote:

DTMF transport incompatibility

Scott Lawrence — 2008-10-07T15:00:32

One of our frequent problems are reports that Voicemail or AA does not respond correctly to DTMF; these nearly always turn out to be that the sender is not sending the DTMF using telephone-event encoding (RFC 2833 or its successor) in the RTP. Since this failure could be detected at the INVITE when we see that the SDP does not support the only DTMF transport we support, shouldn't we just reject these calls with a some 4xx media unsupported response code and a nice informative message explaining the problem?

Re: ITSP test

M. Ranganathan — 2008-10-07T13:41:01

Please use the nightly unstable builds. Currently we are at 3.11.7.xxxx Regards Ranga

Re: process management restructure question

Carolyn Beeton — 2008-10-07T12:35:44

There is no guarantee that any process will start, if some of its dependencies are not met. The "old" ProcMgmtRpc code waited for 15 seconds (for one process) or 45 seconds (for a list of processes), but the sipXconfig xmlrpc code which sends the request only waits for 5 seconds. All of this waiting for something which might not come seems pointless to me. I think the ProcMgmtRpc code should just acknowledge the request, and sipXconfig can then query the actual status (which might be Starting, or indicate ResourceRequired etc). Carolyn

not able to get High Availability implementation

Vikas Sharma — 2008-10-07T11:07:52

ITSP test

xavier houghton — 2008-10-07T10:56:52

Hi - I´m looking to test sip trunking with an itsp that i use in Europe. I´d be looking to set all components on the same server using ISO what would be the best build to use? 3.11.4?

Re: Problem in creating SSL certificates for distributedserver in HA

Vikas Sharma — 2008-10-07T05:02:31

Re: High-level redirect plug-in interfacechangeproposal for XECS-1306

Scott Lawrence — 2008-10-06T20:53:04

On Fri, 2008-10-03 at 14:19 -0400, Joly, Robert (CAR:9D30) wrote: Looks good to me, Robert. A couple of small suggestions: * In the class description of RedirectPlugin, make it clear that only one of the lookup or observe methods will be called for any given message. * Similarly, in the class description for SipRedirectServer, the section headed "Effects of the authority level attribute", make this explicit. You describe the effect correctly, but never actually mention that the effect is acheived by selecting which RedirectPlugin method is chosen. * In the class description for SipRedirectServer, you mention the 'Contact list' several times - if you change those to ContactList, they'll be links to that class, which would be good. One implementation note that you (and others) may not be aware of: You must not modify any UtlContainable object in a way that would change its key value if that object i

Re: XECS-1589: sipXecs does not gracefully handlebrokenTCPstreams

Dale Worley — 2008-10-06T20:41:58

OK, even after I revised the problem description, the sipX problem is not clearly described. The general sipX problem is: If a sipX server wants to send a message to a destination (e.g., a phone), via TCP, it will attempt to use an already-established TCP stream to that destination. But if the destination has been rebooted or reset since the TCP stream was established, the destination will not know of the TCP stream. sipX (or rather the kernel) sends the TCP data packets to the destination, which rejects them with a packet with "RST" set. At that point, sipX should attempt to open a new TCP stream to the target on which to send the message, or should attempt alternative transports. Instead, sipXtack returns a transport error to the higher-level code, which causes the higher-level code to think the destination is unreachable, often leading to functional failures. The observed failure is: A Polycom phone has subscribed to BLF information and receives the NOTIFYs via TCP from the RLS. The phone reboot

Re: Assigning authority levels to redirector plugins

Dale Worley — 2008-10-06T19:53:57

I've added a new issue to discuss the pick-up/gateway/pattern-match problem, XECS-1756. It also has a link to the previous sipx-dev discussion of the changes that are needed. Dale

Re: process mgmt: dependent processes etc

Scott Lawrence — 2008-10-06T19:52:38

On Mon, 2008-10-06 at 14:40 -0400, Carolyn Beeton wrote: I don't think we need to do that. These dependency relationships are just to get client/server relationships right - the server should start first. Since we don't need to do the restarts, any order will do... but the real question is whether or not we need the restartAll function at all. Well, even if we need it (I don't think we do), it should only block until either everything is done or some error is detected. If any such mechanism is needed, it can be implemented within the service (if the service script just waits forever, sipXsupervisor won't know the real service isn't running). I think we can just eliminate the script output and delegate any progress reporting back to sipXsupervisor. I have a temporary hack that enables sipXconfig as long as the host name matches the CONFIG_SERVER_HOST in config.defs, which helps. I'm composing another note on a longer-term strategy for this... I'm thinking we should try to wrap up a couple of

Re: sipXecs 13608 keccles: really XECS-1556,svn log corrected

Kathleen Eccles — 2008-10-06T19:39:27

Revision 13608: Author:keccles Date:Mon Oct 6 19:03:04 2008 UTC (34 minutes, 20 seconds ago) On Mon, 2008-10-06 at 15:03 -0400, svn< at >sipxecs.sipfoundry.org wrote: Project sipXecs New Revision 13608 Committer keccles (Kathy Eccles) Date 2008-10-06 15:03:04 -0400 (Mon, 06 Oct 2008) Log Message: XECS-1556 - DialogEventPublisher.cpp does not publish dialog events for outgoing calls Patch from Arjun Nair - thanks.

new alarm e-mail notification table is non-standard

Damian Krzeminski — 2008-10-06T19:36:34

This table seems to be misleading. You press "Enable e-mail notifications" and it if the checkbox is not checked it actually disables notification. I think it would be better if e-mail notification column had "Disable/Enable" toggle and was saved with the same "Apply" button as everything else. If we want to keep Checkbox column we need two buttons below the table: "Enable e-mail notification" and "Disable e-mail nofication". (but I like it a lot less then a drop-down toggle in each row). In sipXconfig buttons below the table have to affect all "selected" rows in a way consistent with a button label. We cannot have a button affect the row differently based on the selection status. D.

Re: Also having errors abouthttpd-sipxchange-common.conf and httpd-sipxchange-common-ssl.conf

Andy Spitzer — 2008-10-06T18:45:02

Woof! On Mon, 06 Oct 2008 14:07:24 -0400, Daniel Bartz cox.net> wrote: As you want to the new functionality, then being on the unstable development repo is the correct place. But you will have to deal with broken builds, and non-functioning systems, unsuitable for man or beast. That's just life on the development fast lane. You actually didn't ask for help, (that I saw), you pointed out that the system is currently unstable and broken--we all know that--that's why it's the "unstable" repo! There are several JIRA issues open on the exact things you are complaining about, and many list entries describing the same thing. When someone who says they aren't savvy with these things jumps in and points out the unstable repos is, well, unstable, we tend to usher them towards the stable repos, as (hopefully) that one isn't broken. If you can fix these on your own, please do, and let us know what the fix is. A patch would be ideal, but not always needed. If you are not able t