18 Jun
2004
18 Jun
'04
11:23 a.m.
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(a)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(a)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(a)sip.4ecalls.com>;tag=0b2f302e
Call-ID: a11e2f28e61050565418b228c70caf17(a)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(a)sip.4ecalls.com'
15(20655) doSoftphoneRegistration: email Address = '1004(a)sip.4ecalls.com'
15(20655) verifyEmailAddress: entered with = '1004(a)sip.4ecalls.com'
15(20655) verifyEmailAddress: Username = '8 54'
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(a)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(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers