From: Nils Ohlmeier <lists@ohlmeier.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org,
Christian Hentschel <chentschel@arnet.com.ar>,
Harald Welte <laforge@gnumonks.org>,
Harry Behrens <harry@behrens.com>
Subject: Re: SIP helper review
Date: Mon, 20 Feb 2006 21:45:20 +0100 [thread overview]
Message-ID: <200602202145.20377.lists@ohlmeier.org> (raw)
In-Reply-To: <43F9FDC3.50102@trash.net>
On Monday 20 February 2006 18:34, Patrick McHardy wrote:
> Nils Ohlmeier wrote:
> > 1) As far as I got it the skp_epaddr_len function in ip_conntrack_sip.c
> > expects to find a username in the SIP URI in the Contact header. As
> > usernames are generally optional in SIP URIs there are several User
> > Agents (UA), especially the cheaper hardware UA's which support only one
> > SIP account, which do not put a username into their Contact's. Thus I
> > would propose that the searching for the username in the Contact header
> > should be optional as well.
>
> I think this is what made the helper fail with my crappy chinese SIP
> ATA. Without the username, is there still an '@'-character (in which
> case it should work as it is) or does the string start directly with
> the address?
The two valid alternatives are (omitting secure SIP, because it couldn't be
patched anyway):
- sip:user@host
- sip:host
The first alternative is used by the majority of the devices. But if you have
a simple hardware with only one account there is no plus in adding a username
to the URI. Their are some devices which use the later. So some more devices
could be supported by netfilter if the username would not be mandatory.
> > 2) As far as I got it the epaddr_len function looks for 'UDP' in Via
> > headers. Is it by intention that the IP address replacement would only
> > work for the UDP transport but not for TCP? Allthough TCP is not very
> > widely used yet I think it should be easy to do the replacement for TCP
> > as well, or?
>
> It should be easy to change. Is TCP used for SIP itself? In that case
> it would also have to register for TCP in addition to UDP.
Yes. In fact TCP should have precedence if it is supported by both sides. But
currently most of the providers do not offer/support it (on their server
side). So currently the add-on value by supporting TCP as well would be
small. But I think it will become more important in the future.
Allthough I understand that the payload fragmentation with TCP would be a
problem for the netfilter module, I would assume that the Via header should
always appear early in a message. So it might be worth thinking about it for
the future.
Greetings
Nils
prev parent reply other threads:[~2006-02-20 20:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-19 22:12 SIP helper review Nils Ohlmeier
2006-02-20 17:34 ` Patrick McHardy
2006-02-20 20:45 ` Nils Ohlmeier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200602202145.20377.lists@ohlmeier.org \
--to=lists@ohlmeier.org \
--cc=chentschel@arnet.com.ar \
--cc=harry@behrens.com \
--cc=kaber@trash.net \
--cc=laforge@gnumonks.org \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.