21 Nov
2004
21 Nov
'04
8:30 p.m.
Greger,
I believe the small change to the onfailure_route[] was the thing that made the
difference. Andrei
pointed out a small error to me where I was calling fix_nated_contact() for more messages
than I
should have. (THANKS ANDREI!!!)
The other thing that made a **substantial** improvement was the fact that our PSTN
gateway
provider that uses Sonus equipment as added as an "alias" at the top of the
ser.cfg. This caused
ser to not include "Route:" headers on ACKs and this was causing the Sonus
equipment to drop calls
after two minutes.
It's funny how such small changes to ser.cfg can have dramatic effects.
I'd love to see a complete book published on ser. I'm sure, with the help of the
maintainers and
serusers participants this could become a reality. I mean this is the best damned SIP
router I
know of. Commercial solutions such as Sonus are not really a "solution" because
they run as much
as US$2 million per box and most small companies can't afford "one". And
even if you could afford
=>one<= you may not be able to afford others for scaling your VoIP platform - so
whats the point
of attempting VoIP if you can't scale?
Our solution is modeled after the Google network whereby:
unlimited horizontal scalablity == unlimited cps (calls per second)
And this equates to:
successful VoIP Company == retired employee
If we can indeed do this for our implementation and do it on low end x86 or Opteron boxes
(or
blade servers), then the sky is the limit. Our engineer whom we acquired from RedHat a few
months
ago already has a full TCP/IP and UDP socket patch working so we can seperate ser and
serweb and
scale them independently of each other (over a VPN) since we don't need ser's
existing FIFO.
SEMS is a whole other beast. We are now working on this using the ivr module with sipums
for a
carrier-grade voicemail solution. Early indications is that we still have plenty to do in
order to
get 99.999% reliablity with sems. Our goal is to not have sems run on the same box as ser
as we
already know this is bad. Voicemail and SIP proxy cannot be the same box if you expect to
be a big
VoIP provider, IMHO.
So our high-level VoIP platform uses the following as independent server farms:
MySQL 4.1.7 (farm 1)
ser-0.8.99-dev17 (farm 2)
serweb on Apache2 farm 3)
sems/ivr/sipums (farm 4, still a work in progress)
Third party PSTN gateway *** see comment below
All servers use Whitebox Linux Respin 1 and our network implementation allows us to
completely
administer all servers at any remote co-lo site --- even down to remote installation of
the
operating system. This includes make a change to the master ser.cfg and having it
replicate to all
ser proxies.
Monitoring is a big part of this network architecture and we've only got basic
monitoring right
now, so this will become a focus of our efforts soon.
We also use third parties for providing PSTN access. IMHO, PSTN gateways are much more
trouble
than their worth. We'd rather rely on multiple third parties for this than to try and
do it
ourselves. The cost of DSP boards is expensive, especially if you wanted to handle say
50,000
concurrent callers. For this very reason we use companies such as Level 3 and Global
Crossing and
all we have to do is simply monitor their QoS and route PSTN callers to other PSTN
gateways as
needed. And this is all at the network level, so ser is totally oblivious to this.
Another thing I've love to see is a database whereby VoIP service providers can lookup
10-digit
DIDs in a common database (much like a root DNS server) and determine if a callee is a
VoIP user
and route the SIP call directly from our SIP proxy to their SIP proxy rather than making
a
SIP->PSTN->SIP call. We have the Chairman of the IPCC deeply invovled in our company
and he could
get the ball rolling on this, but we don't want to get distracted right now.
Anyhow, I've rambled long enough.
Regards,
Paul Hazlett
We'll publish our
--- "Greger V. Teigre" <greger(a)teigre.com> wrote:
Paul,
Thanks for posting your resulting config after so many hours of testing!
I did a diff and can see that you have done several (smaller) changes. But
what did the trick? (i.e. for Route problem)
g-)
Java Rockx wrote:
=== message truncated ===
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
Greger,
I finally got everything working without STUN and without an Outbound
Proxy. I an only using rtpproxy/nathelper.
I've tested these settings with the following SIP Phones/ATAs
Sipura
UTstarcom iAN-02EX
Grandstream ATA486
Grandstream BT100
Cisco ATA186
Cisco 7960G
WorldAccxx ATA
X-Ten Pro
X-Ten Lite
We are very happy with everything now. The only piece of the puzzle
that I don't have working yet is sems/sipums for voicemail - but I'm
working on that.
Attached is my complete ser.cfg file that is working. Please note
that I'm using ser-0.8.99-dev17 for this rather than ser-0.8.14
If anyone finds problems in this ser.cfg then please let me know -
but like I said before, things seem very stable right now with -dev17.
Regards,
Paul
--- "Greger V. Teigre" <greger(a)teigre.com> wrote:
> Good to get an authoriative answer on this. I think I should
> allocate some time to read the RFC thoroughly.
> This leads back to my guess that it could be Paul's outbound proxy
> setting that fixed the problem. I would think that are some
> Grandstream people this list, but anyway a bug report should be
> submitted to Grandstream. This was a hard bug to track. Paul?
> g-)
>
> Jan Janak wrote:
>> No, ser does not change Record-Route to Route header field, user
>> agents are supposed to do it. SER does only two things:
>>
>> 1) Adds Record-Route header fields with its own IP address (this is
>> what record_route function does)
>> 2) Removes the topmost Route header field if it contains its own IP
>> address (according to the IP) and forwards the message to the IP
>> in the next Route header field if any. If there is no other Route
>> header field then the Request-URI would be used.
>>
>> If there are some Route header fields missing in ACK then this is a
>> bug in the calling user agent, not SER.
>>
>> Jan.
>>
>> On 18-11 21:16, Greger V. Teigre wrote:
>>> I believe the changes are done in the rr module, in the loose.c
>>> file. RFC3261 defines this (as mentioned by the Sonus guys).
>>> I remember vaguely reading something about equivalence between
>>> defining outbund proxy on the client and a Route header, but I'm
>>> way off stable ground here... However, if I remember correctly, it
>>> is probably the outbound proxy and not the stun settings that does
>>> the trick. I have seen some discussions on loose routing
>>> earlier this fall, maybe a search on loose routing in the archives
>>> can turn up some new approaches?
>>>
>>> I'm afraid I don't have anything more to contribute here. From all
>>> I can see, ser should change the Record-Routes to Route, but
>>> doesn't, and I don't understand why. I think we need somebody
>>> with a more in-depth understanding of the ser inner workings.
>>> g-)
>>>
>>>
>>> ----- Original Message -----
>>> From: "Java Rockx" <javarockx(a)yahoo.com>
>>> To: "Greger V. Teigre" <greger(a)teigre.com>om>; "ser
users"
>>> <serusers(a)lists.iptel.org> Sent: Thursday, November 18, 2004 08:21 PM
>>> Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't
>>> extract bodyfrom the message
>>>
>>>
>>>> Greger,
>>>>
>>>> Do you have any idea how SER decides to include a "Route:"
versus
>>>> a "Record-Route:" header? If so,
>>>> which piece of code in ser would write the second ACK below?
>>>>
>>>> Here is a "200 OK" and two ACKs - The first ACK is good and
the
>>>> second ACK is bad because it
>>>> should have a "Route:" header referring to the Sonus box.
>>>>
>>>> 100.99.99.99.99 is my SER proxy
>>>> 100.10.10.10 is the public side of my firewall
>>>> 216.50.50.50 is the ip of the Sonus box
>>>>
>>>> So the ACK from SER to Sonus is incorrect.
>>>>
>>>> Do you think this is worth posing to Jiri, Andrei, and company?
>>>> All I know is that this ACK is bad
>>>> when STUN is not used and it is good when STUN is used. I did
>>>> upgrade my Grandstream, but that
>>>> didn't help, and I've modified my nat_uac_test to use mode==19
>>>> rather than mode==3, but still get
>>>> the same results.
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> U 2004/11/18 14:13:08.419098 100.99.99.99:5060 ->
>>>> 100.10.10.10:5060 SIP/2.0 200 OK.
>>>> Via: SIP/2.0/UDP
>>>>
192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0.
>>>> To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
>>>> From: "Paul (1002)"
>>>>
<sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>> Call-ID: e37c04be3e50ea72(a)192.168.0.83.
>>>> CSeq: 21752 INVITE.
>>>> Contact: sip:4075551212@216.50.50.50:5060.
>>>> Record-Route: <sip:216.50.50.50:5060;lr>.
>>>> Record-Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
>>>> Accept: multipart/mixed, application/sdp, application/isup,
>>>> application/dtmf,
>>>> application/dtmf-relay.
>>>> Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO.
>>>> Supported: timer.
>>>> Content-Disposition: session;handling=required.
>>>> Content-Type: application/sdp.
>>>> Session-Expires: 240;refresher=uas.
>>>> .
>>>> v=0.
>>>> o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76.
>>>> s=SIP Media Capabilities.
>>>> c=IN IP4 100.99.99.99.
>>>> t=0 0.
>>>> m=audio 35552 RTP/AVP 18 101.
>>>> a=rtpmap:18 G729/8000.
>>>> a=rtpmap:101 telephone-event/8000.
>>>> a=fmtp:101 0-15.
>>>> a=sendrecv.
>>>> a=nortpproxy:yes.
>>>>
>>>> #
>>>> U 2004/11/18 14:13:08.428394 100.10.10.10:5060 ->
>>>> 100.99.99.99:5060 ACK sip:4075551212@216.50.50.50:5060 SIP/2.0.
>>>> Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d.
>>>> Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
>>>> Route: <sip:216.50.50.50:5060;lr>.
>>>> From: "Paul (1002)"
>>>>
<sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>> To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
>>>> Contact: <sip:9990010001@192.168.0.83;user=phone>.
>>>> Call-ID: e37c04be3e50ea72(a)192.168.0.83.
>>>> CSeq: 21752 ACK.
>>>> User-Agent: Grandstream BT100 1.0.5.16.
>>>> Max-Forwards: 70.
>>>> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
>>>> .
>>>>
>>>> #
>>>> U 2004/11/18 14:13:08.429879 100.99.99.99:5060 ->
>>>> 216.50.50.50:5060 ACK sip:216.50.50.50:5060;lr SIP/2.0.
>>>> Via: SIP/2.0/UDP
>>>> 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0.
>>>> Via: SIP/2.0/UDP
>>>>
192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d.
>>>> From: "Paul (1002)"
>>>>
<sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>> To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
>>>> Contact: <sip:9990010001@100.10.10.10:5060;user=phone>.
>>>> Call-ID: e37c04be3e50ea72(a)192.168.0.83.
>>>> CSeq: 21752 ACK.
>>>> User-Agent: Grandstream BT100 1.0.5.16.
>>>> Max-Forwards: 16.
>>>> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
>>>> .
>>>>
>>>>
>>>> --- "Greger V. Teigre" <greger(a)teigre.com> wrote:
>>>>
>>>>> A few comments/questions after having looked at your config file:
>>>>> - You are using 1.0.5.11 firmware on your Grandstream. 1.0.5.16
>>>>> is the latest and a lot of things have happened since 11. I would
>>>>> suggest you upgrade the firmware before you spend more time on
>>>>> it. - The SIP conversation you sent earlier shows a conversation
>>>>> without using
>>>>> STUN. In later messages you write about setting outbound and
>>>>> then stun. Have you tried setting outbound, but not stun? Any
>>>>> difference in Route?
>>>>> - From 1.0.5.7, Grandstream started to send stun-detected ip and
>>>>> port when
>>>>> symmetric NAT was found. My experience is that if stun is set on