Jan,

Sorry about that.

Here is my config file and some trace.... Any functions that are not standard are own own developed one in a plugin.

Re the debug info, there was way too much to send in a mail, but the basic gist is that, somewhere, possibly during the ACK (although it happens during REGISTER and INVITE as well), is where the server gets caught in a loop, and all other requests are blocked at this point.

A quick sample of the debug supplied after the config file.

My initial feelings is that there is something basically wrong with the config file - maybe I'm not breaknig out at the right point. The annoying thing is that sometimes, this doesn't happen. Sometimes, the registration and call goes through fine.

BTW - if anyone else has a solution, feel free to suggest it.

TIA Derek

# ------------------------- request routing logic -------------------

# main routing logic

route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests

if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; };

# This is when a UA wishes to register with the Server if(method=="REGISTER") { log("Attempting to register a UA ...\n"); if (!performRegistration("4ecalls.com")) { sl_send_reply("404", "Not Found"); break; };

save("location");

sl_send_reply("200", "OK"); };

# This is when a call attempts to take place... if(method=="INVITE") { log("Attempting to re-route call ...\n");

if (!lookup("location")) { log("Lookup failed - possibly a PSTN call...\n"); if (!performInvite("4ecalls.com")) { log("Am checking to see if it is in our domain...\n"); if(uri=~"^sip:0[0-9]*@sip.4ecalls.com") { sl_send_reply("180", "Trying"); log("Am attempting to re-route call \n");

# Forward to the SIP gateway forward(x.x.x.x, 5060); log("Have re-routed that call ...\n");

# Record so we get a return message record_route();

break; }; } else { log("The call was not logged ...\n"); }; log("The call was redirected - hopefully ...\n"); } else { performInvite("4ecalls.com"); };

setflag(1); };

# An ACK can occur for many reasons # DT : I think this is where the loop is starting to go awry if(method=="ACK") { log("Processing for an ACK ...\n"); setStartTimeActiveCall(""); };

# User cancelled the call if(method=="CANCEL") { log("Processing for an CANCEL ...\n"); removeActiveCall(""); };

# Call connected, and is now finished... if(method=="BYE") { log("Processing for an BYE ...\n"); log("Found BYE message ...\n"); log("Checking to see if the destination is a SIP phone or not ...\n");

if (!lookup("location")) { log("Destination is a PSTN number ...\n"); performBillingOperation("4ecalls.com"); } else { removeActiveCall(""); }; };

# Only record route on an INVITE if (method=="INVITE") { log("Processing for an INVITE ...\n"); record_route(); };

# loose-route processing if (loose_route()) { t_relay(); break; };

# forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); }; }

Debug info: ========

The ip address 1.1.1.1 is the IP of the Ser server The ip address 2.2.2.2 is the public IP of our network, from which my softphone is running The ip address 3.3.3.3 is the internal IP of the softphone The ip address 4.4.4.4 is the IP of our MySQL database

This is a small sample, the rest of the loop is very ssimilar to this.

15(20655) SIP Request: 15(20655) method: <REGISTER> 15(20655) uri: sip:sip.4ecalls.com 15(20655) version: <SIP/2.0> 15(20655) parse_headers: flags=1 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.6a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=1 15(20655) parse_headers: this is the first via 15(20655) After parse_msg... 15(20655) preparing to run routing scripts... 15(20655) DEBUG : is_maxfwd_present: searching for max_forwards header 15(20655) parse_headers: flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.5a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) parse_headers: this is the second via 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.4a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.3a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.2a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.1a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.0a379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.f9379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 232, <branch> = <z9hG4bK2abf.e9379564.0>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) Found param type 235, <rport> = <28044>; state=6 15(20655) Found param type 232, <branch> = <z9hG4bK212ae015>; state=16 15(20655) end of header reached, state=5 15(20655) parse_headers: Via found, flags=128 15(20655) end of header reached, state=9 15(20655) DEBUG: get_hdr_field: <To> [34]; uri=[sip:1004@sip.4ecalls.com] 15(20655) DEBUG: to body [Derek sip:1004@sip.4ecalls.com ] 15(20655) get_hdr_field: cseq <CSeq>: <2> <REGISTER> 15(20655) DEBUG: is_maxfwd_present: value = 61 15(20655) Attempting to register a UA ... 15(20655) performRegistration: Entered 15(20655) performRegistration: headers = Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.6a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.5a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.4a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.3a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.2a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.1a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.0a379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.f9379564.0 Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK2abf.e9379564.0 Via: SIP/2.0/UDP 2.2.2.2:28044;rport=28044;branch=z9hG4bK212ae015 To: Derek sip:1004@sip.4ecalls.com From: Derek sip:1004@sip.4ecalls.com;tag=0b2f302e Call-ID: a11e2f28e61050565418b228c70caf17@3.3.3.3 CSeq: 2 REGISTER Max-Forwards: 60 Expires: 0 Contact: sip:1004@2.2.2.2:28044 User-Agent: SIP EyeP Phone (Build: EMSipFtw 4.0.23 EM) Content-Length: 0 15(20655) parse_headers: flags=4 15(20655) parse_headers: flags=8 15(20655) parse_headers: flags=16 15(20655) parse_headers: flags=64 15(20655) parse_headers: flags=32 15(20655) performRegistration: - about to create RADIUSRequest...15(20655) doRegistrationProcess(): Dealing with an REGISTER 15(20655) getSIPAttribute: endStr = '>;tag=0b2f302e Call-ID: a11e2f28e61050565418b228c70caf17@3.3.3.3 CSeq: 2 REGISTER Max-Forwards: 60 Expires: 0 Contact: sip:1004@2.2.2.2:28044 User-Agent: SIP EyeP Phone (Build: EMSipFtw 4.0.23 EM) Content-Length: 0 ' 15(20655) getSIPAttribute: startStr = '1004@sip.4ecalls.com>;tag=0b2f302e Call-ID: a11e2f28e61050565418b228c70caf17@3.3.3.3 CSeq: 2 REGISTER Max-Forwards: 60 Expires: 0 Contact: sip:1004@2.2.2.2:28044 User-Agent: SIP EyeP Phone (Build: EMSipFtw 4.0.23 EM) Content-Length: 0 ' 15(20655) getSIPAttribute: return string = '1004@sip.4ecalls.com' 15(20655) doSoftphoneRegistration: email Address = '1004@sip.4ecalls.com' 15(20655) verifyEmailAddress: entered with = '1004@sip.4ecalls.com' 15(20655) verifyEmailAddress: Username = '854' 15(20655) verifyEmailAddress: PIN = '' 15(20655) verifyEmailAddress: Customer ID = '136135424' 15(20655) verifyEmailAddress: About to open connection 15(20655) verifyEmailAddress: Username username 15(20655) verifyEmailAddress: Password password 15(20655) verifyEmailAddress: Host 4.4.4.4 15(20655) verifyEmailAddress: Name radius 18(20672) DEBUG: timer routine:4,tl=0x422ef38c next=0x422f6b7c 18(20672) DEBUG: timer routine:4,tl=0x422f6b7c next=(nil) 18(20672) DEBUG: timer routine:5,tl=0x422de1ac next=0x422ce924 18(20672) DEBUG: timer routine:5,tl=0x422ce924 next=(nil)

-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: Wednesday, June 16, 2004 11:03 AM To: Derek Toner Cc: 'serusers@lists.iptel.org' Subject: Re: [Serusers] (newbie to) b2bua And Ser

Well, except problem description you did not send any additional information for debugging, so how can we help you ? The problems can be anywhere in the chain.

Jan.

On 15-06 15:02, Derek Toner wrote:

Hi all,

I am attempting to put together a system involving Ser, so that customers can make VoIP calls, and depending on the destination, they get billed. We would like to be able to cut people off if they run out of credit, so we have decided to use b2bua.

...

From what I've been reading about this (b2bua working with ser), it would

seem that it works. However, I'm having a few problems, and was kinda hoping someone would be good enough to spare some time to answer my questions.

Currently, what we have is this (in a nutshell): Softphone <-----> Ser Server (+ developed Plugin) <-----> b2bua <---------> SIP Gateway.

With the flow of call being as follows: Softphone initiates the call, and passes an INVITE message to the Ser The Ser does his biz on the message (the config file is available if required), and once all goes well, forwards the message to the b2bua b2bua does his biz again on the INVITE, and forwards the message to the Sip Gateway. Sip Gateway connects the call, and call proceeds until someone disconnects. Call is billed, if it is a PSTN call.

All seems simple so far. However, my main problems are as follows:

1. Sometimes the messages (INVITE, ACK, BYE) seem to get caught in a

vicious loop, and won't break out of it, even though the max forward headers is set to 10. I assume this is a bad config file error, and results in this loop. However, I've changed the file so amny times at this point, I'm not exactly sure where the loop is beginning.

2. Sometime when I make a call, the tmie it takes to connect results

in the call being disconnected before it connects (or just after). As a result, the destination customer wouldn't humanly have enough time to get to the phone and answer it (unless they had the phone surgically attached to them). I feel that there is a bottleneck/delay somewhere (perhaps related to question 1), and as a result the time to connect is way too long. Is it a case of I have too many components, and there is a delay, or something similar.

These problems are bad enough when I'm performing single user testing, but when we take on board 20/50/100/500 customers, it's going to become a rather large head-ache :-)

Any help would be most appreciated. Regards, Derek

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers