[Users] No memory left errors and Private Memory Size

Max Gregorian gregorian442 at googlemail.com
Thu Jan 4 18:52:00 CET 2007

Thanks for you reply.

On further examination of the very basic logging information I could find on
that server, I am inclined to agree with your theory that it may be a
particular UA causing these errors.

The logs seem to show that this particular error is only generated shortly
after this particular UA attempts registration, as before and after that,
there were no such errors for other users. Further more, This error is only
generated for Registration atempts and does not seem to occur during call
setup, INVITES, etc. - which makes sense from the error descriptoin which
seems to be implying that Openser is having trouble creating/building the
contact header for the REGISTER. The errors are almost certainly to do with
this UA as I have just counted over 20 instances all occurring only after
this UA.

I will certainly look more into this to confirm this.

The trouble is this often happens fairly late at night when every one is
asleep, making it hard to get a live trace as I don't know when exactly this
guy is going to connect, but I'll see what I can do. Unfortunately, we took
off most of the syslog logging from the server as syslog performance was
becoming an issue with performance (read one of my previous posts :)), so I
can't get a full packet dump from the openser  server itself.

Looking further into this I managed to pull up some Ethereal traces from a
different machine we use for tracing and loggin on the same network, and the
device seems to be a Sipura SPA 2002-3.1.2(a).

Since I can't find a Register message, I can only show you an INVITE but I
guess it will still have the same contact header as we are not overwriting
the contact information anywhere I know of:

Session Initiation Protocol
    Request-Line: INVITE sip:5068831424@<SIP AS>:5060 SIP/2.0
        Method: INVITE
        Resent Packet: False
    Message Header
        Record-Route: <sip:<OPENSER IP>;ftag=935c557f841a75c7o0;lr=on>
        Via: SIP/2.0/UDP <OPENSER IP>;branch=z9hG4bK2f26.41279b67.0
        Via: SIP/2.0/UDP;rport=16384;received=;branch=z9hG4bK-b8411887
        From: <sip:071159040628330829@<OPENSER
            SIP from address: sip:071159040628330829@<OPENSER DOMAIN>
            SIP tag: 935c557f841a75c7o0
        To: <sip:5068831424@<OPENSER DOMAIN>>
            SIP to address: sip:5068831424@<OPENSER DOMAIN>
        Call-ID: a0a739df-fb05dce7 at
        CSeq: 101 INVITE
        Max-Forwards: 69
        Contact: <sip:071159040628330829 at>
        Expires: 240
        User-Agent: Sipura/SPA2002-3.1.2(a)
        Content-Length: 428
        Supported: x-sipura
        Content-Type: application/sdp
    Message body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 11350715 11350715 IN IP4
                Owner Username: -
                Session ID: 11350715
                Session Version: 11350715
                Owner Network Type: IN
                Owner Address Type: IP4
                Owner Address:
            Session Name (s): -
            Connection Information (c): IN IP4
                Connection Network Type: IN
                Connection Address Type: IP4
                Connection Address:
            Time Description, active time (t): 0 0
                Session Start Time: 0
                Session Stop Time: 0
            Media Description, name and address (m): audio 16402 RTP/AVP 4 0
2 8 18 96 97 98 100 101
                Media Type: audio
                Media Port: 16402
                Media Proto: RTP/AVP
                Media Format: ITU-T G.723
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.721
                Media Format: ITU-T G.711 PCMA
                Media Format: ITU-T G.729
                Media Format: 96
                Media Format: 97
                Media Format: 98
                Media Format: 100
                Media Format: 101
            Media Attribute (a): rtpmap:4 G723/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 4 G723/8000
            Media Attribute (a): rtpmap:0 PCMU/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 0 PCMU/8000
            Media Attribute (a): rtpmap:2 G726-32/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 2 G726-32/8000
            Media Attribute (a): rtpmap:8 PCMA/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 8 PCMA/8000
            Media Attribute (a): rtpmap:18 G729a/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 18 G729a/8000
            Media Attribute (a): rtpmap:96 G726-40/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 96 G726-40/8000
            Media Attribute (a): rtpmap:97 G726-24/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 97 G726-24/8000
            Media Attribute (a): rtpmap:98 G726-16/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 98 G726-16/8000
            Media Attribute (a): rtpmap:100 NSE/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 100 NSE/8000
            Media Attribute (a): rtpmap:101 telephone-event/8000
                Media Attribute Fieldname: rtpmap
                Media Attribute Value: 101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15
                Media Attribute Fieldname: fmtp
                Media Attribute Value: 101 0-15
            Media Attribute (a): ptime:30
                Media Attribute Fieldname: ptime
                Media Attribute Value: 30
            Media Attribute (a): sendrecv

On 02/01/07, Andreas Sikkema <andreas at ramdyne.nl> wrote:
> On Tuesday 02 January 2007 12:12, Max Gregorian wrote:
> > I am seeing quite a few of these memory errors in the openser log
> > file: *build_contact():
> > No memory left*. These seem to be occurring when the UA tries to
> register
> > with Openser. In the last instance I saw, this lasted almost half an
> hour
> > before clearing up.
> >
> > So I guess what I am trying to find out really is:
> >
> > 1. Is this related to the Private memory size issue I remember reading
> > about a while ago? I am using Openser 1.0.1 and so far have not messed
> with
> > the default memory size settings from the sources I downloaded.
> A colleague of mine thought the same when we encountered some problems
> with
> our OpenSER machines when we wanted to restart OpenSER. What it turned out
> to
> be was some buggy UA registering broken Contacts that "work", but when
> trying
> to restart OpenSER can't load them from the database. Deleting all records
> from the location table and then trying to start will work.
> --
> Andreas Sikkema
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070104/93ac8934/attachment.htm>

More information about the sr-users mailing list