[Serusers] (newbie to) b2bua And Ser
Derek Toner
Derek at 4ecalls.com
Fri Jun 18 17:23:26 CEST 2004
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 at sip.4ecalls.com]
15(20655) DEBUG: to body [Derek <sip:1004 at 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 at sip.4ecalls.com> From: Derek
<sip:1004 at sip.4ecalls.com>;tag=0b2f302e Call-ID:
a11e2f28e61050565418b228c70caf17 at 3.3.3.3 CSeq: 2 REGISTER Max-Forwards: 60
Expires: 0 Contact: <sip:1004 at 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 at 3.3.3.3 CSeq: 2 REGISTER Max-Forwards: 60
Expires: 0 Contact: <sip:1004 at 2.2.2.2:28044> User-Agent: SIP EyeP Phone
(Build: EMSipFtw 4.0.23 EM) Content-Length: 0 '
15(20655) getSIPAttribute: startStr = '1004 at sip.4ecalls.com>;tag=0b2f302e
Call-ID: a11e2f28e61050565418b228c70caf17 at 3.3.3.3 CSeq: 2 REGISTER
Max-Forwards: 60 Expires: 0 Contact: <sip:1004 at 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 at sip.4ecalls.com'
15(20655) doSoftphoneRegistration: email Address = '1004 at sip.4ecalls.com'
15(20655) verifyEmailAddress: entered with = '1004 at 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 at iptel.org]
Sent: Wednesday, June 16, 2004 11:03 AM
To: Derek Toner
Cc: 'serusers at 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 at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list