Thomas Ries

1) conditional rewriting using plugin_regex: plugin_regex_desc = prefix outgoing 10 digit numbers with a leading '1' #plugin_regex_pattern = ^(sips?:)(\+?)(.{10}@) plugin_regex_pattern = ^(sips?:)(\+?)([0-9]{10}@) plugin_regex_replace = \1\21\3 or maybe (without '+' prefixed, 10 digit numbers only) plugin_regex_desc = prefix outgoing 10 digit numbers without leading '+' with a leading '1' plugin_regex_pattern = ^(sips?:)([0-9]{10}@) plugin_regex_replace = \11\2 only 10 digit numbers will be processed....

Please try without plugin_prefix being active. Looking at the log, I have the impression that the PBX issues a re-INVITE (directed towards flowroute) for the ongoing call that is being affected by plugin_prefix and causes the call to fail. If plugin_prefix is causing an issue in this setup, there are other ways to prefix outgoing calls with the digit 1 (plugin_regex, allows conditionally rewriting outgoing call targets via regular expressions).

ping@invalid -> seems to be used by the provider (34.226.36.32) as dummy "From" address in OPTION requests, probably a "ping" feature to check if the client (your PBX) is alive. NULL@192.168.0.189 -> Response Point does send Contact Headers with no user part (only the hostname part) in INVITE requests. This is technically legal and should not cause any issues with siproxd. In the logs, this missing user part is shown as "NULL" to indicate the missing user. There seems to be an unwanted trigger of...

My guess would be, you have messed up the siprunk configuration (siptrunk_account): b4: plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyy8000@us-east-va.sip.flowroute.com <<<<< plugin_siptrunk_numbers_regex = ^+?1yyyyyy985([1-9])$ now: plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyy9853@us-east-va.sip.flowroute.com <<<<< plugin_siptrunk_numbers_regex = ^\+?1yyyyyy985([1-9])$

12:36:16.415 ERROR:plugin_siptrunk.c:168 Regular expression [^+?1yyyyyy985([1-9])$] failed to compile: Invalid preceding regular expression My bad, missed the '\' character in the REGEX (must have gotten lost between brain and keyboard). Actually, the HTML editor of sourceforge does make them disappear. ^\+?1yyyyyy985([1-9])$ That should be the correct REGEX (at least the preview does show it properly).

Your provider uses two different number formats. In the Request URI a format without leading '+' is used, in the To Header the number format does include the leading '+'. check here: 19:36:56.272 plugin_siptrunk.c:203 Request URI: [1yyyyyy9853] 19:36:56.272 plugin_siptrunk.c:209 To: header: [+1yyyyyy9853] 19:36:56.272 plugin_siptrunk.c:231 plugin_siptrunk: matched trunk on rule 0 [^1yyyyyy985([1-9])$] 19:36:56.273 plugin_siptrunk.c:234 plugin_siptrunk: Trunk [Response Point], Account [sip:1yyyyyy8000@us-east-va.sip.flowroute.com]...

The debug log looks fine, I cannot see anything bad in the behavior of siproxd. All outgoing packets look correct. What happens is basically: (You can check RFC3261, page 11 for a graphical representation of the signalling flow) <--- INVITE ---> 100 Trying ---> 180 Ringing phone being picked up ---> 200 OK The required 'ACK' request (completes the call establishmend) from the remote side is never received. Either the outgoing SIP packets never make it to your provider, or the ACK is not sent / sent...

The number you register is 1yyyyyyy8000. This means, at this point only this number is known and handled by siproxd. If you have a whole number broch attached to this account (account being "1yyyyyyy8000"), then you need to pass this information to siproxd using the plugin_siptrunk. load_plugin=plugin_siptrunk.la plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyyy8000@us-east-va.sip.flowroute.com plugin_siptrunk_numbers_regex = ^<REGEX to match the whole number block>$ Waring:...