3 Jul
2007
3 Jul
'07
11:57 p.m.
Hi all,
I'm fairly new to SER (just heard about it this afternoon), but I've
already run up against a problem that's vexing me.
We have a Polycom phone sitting behind a Linksys WRT54G router/firewall
with DD-WRT firmware. This version of DD-WRT is the "voip" edition,
meaning it has SER and rtpproxy installed to help ease NAT issues with
SIP. No configuration of SER is necessary, we enter the WRT54G's IP
address into the phone's outbound proxy field and it just works.
The only drawback is that when using this method, the caller ID on an
incoming call from the PSTN contains a SIP URI (in the form of
sip:5551212@207.179.x.x) instead of a simple telephone number. Our
end-users are pretty voip illiterate and thus haven't the slightest
clue how VoIP works. They are only going to get confused when a SIP URI
shows up on their caller ID instead of the actual PSTN phone number of
the person who called them. How can this be remedied?
I can't tell what version of ser is on this device because the -h and -V
flags return nothing. (Probably to make it slightly smaller for the
embedded platform.) The 'strings' utility wasn't helpful either.
Attached is the ser.cfg that comes with DD-WRT. Any help is greatly
appreciated. Let me know if I need to provide more information.
Thanks!
--
Charles Ulrich
Ideal Solution, LLC -- http://www.idealso.com
6 Jul
6 Jul
11:41 a.m.
At 22:57 03/07/2007, Charles Ulrich wrote:
Hi all,
I'm fairly new to SER (just heard about it this afternoon), but I've
already run up against a problem that's vexing me.
We have a Polycom phone sitting behind a Linksys WRT54G router/firewall
with DD-WRT firmware. This version of DD-WRT is the "voip" edition,
meaning it has SER and rtpproxy installed to help ease NAT issues with
SIP.
Hi Charles,
Is the 'voip edition' somewhere available? I would be eager to give it
a try on my WRT too.
I'm a bit sceptical how much we can do about it, since the URIs are part
of the SIP protocol machinery and it is up to discretion of a telephone
implementation to show what it wants to show (there is no standard for
what a telephone shall display).
IMO you are then left with experimenting and changing SIP requests in
a way that increases the chance that the phone shows what you want to
be shown. There is no guarantee however it will work for all phones
in a consistent way.
If I were you, I would try appending P-asserted-identity or Remote-Party-ID
header fields with tel URIs (benefit: use of a header field does not change
request URI, which might have side effects otherwise, and use of TEL
URI eliminates the domain). If that does not work, I would try to
put TEL URI in request-URI.
-jiri
No configuration of SER is necessary, we enter the
WRT54G's IP
address into the phone's outbound proxy field and it just works.
The only drawback is that when using this method, the caller ID on an
incoming call from the PSTN contains a SIP URI (in the form of
sip:5551212@207.179.x.x) instead of a simple telephone number. Our
end-users are pretty voip illiterate and thus haven't the slightest
clue how VoIP works. They are only going to get confused when a SIP URI
shows up on their caller ID instead of the actual PSTN phone number of
the person who called them. How can this be remedied?
I can't tell what version of ser is on this device because the -h and -V
flags return nothing. (Probably to make it slightly smaller for the
embedded platform.) The 'strings' utility wasn't helpful either.
Attached is the ser.cfg that comes with DD-WRT. Any help is greatly
appreciated. Let me know if I need to provide more information.
Thanks!
--
Charles Ulrich
Ideal Solution, LLC -- http://www.idealso.com
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
1:26 p.m.
Jiri Kuthan wrote:
At 22:57 03/07/2007, Charles Ulrich wrote:
get
http://dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fstable%2Fdd-wrt.v23%20…
or directly the one for your router
http://dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fstable%2Fdd-wrt.v23+SP…
Regards
Stefan Sayer
--
iptego - VoIP security
www.iptego.de
Hi all,
I'm fairly new to SER (just heard about it this afternoon), but I've
already run up against a problem that's vexing me.
We have a Polycom phone sitting behind a Linksys WRT54G router/firewall
with DD-WRT firmware. This version of DD-WRT is the "voip" edition,
meaning it has SER and rtpproxy installed to help ease NAT issues with
SIP.
Hi Charles,
Is the 'voip edition' somewhere available? I would be eager to give it
a try on my WRT too.
9 Jul
9 Jul
5:19 p.m.
On Friday 06 July 2007 04:41, Jiri Kuthan wrote:
Hi Charles,
Is the 'voip edition' somewhere available? I would be eager to give
it a try on my WRT too.
Sure. There's no direct link, so you have to click through the following
trail of links:
* Go to www.dd-wrt.com
* Downloads
* stable
* dd-wrt.v23 SP2
* voip
* dd-wrt.v23_voip.bin
Use this if you have a WRT54Gv4 or WRT54GL, otherwise check the
documentation to find out which firmware image you need. DD-WRT works
on a couple of other router brands too, such as Buffalo, Belkin, and
ASUS.
I'm a bit sceptical how much we can do about it,
since the URIs are
part of the SIP protocol machinery and it is up to discretion of a
telephone implementation to show what it wants to show (there is no
standard for what a telephone shall display).
You mean SIP doesn't have some kind of caller ID header? When these
phones are registered directly with Asterisk, caller ID works exactly
like a legacy non-SIP phone: Only a name and a number (or extension)
appear on the display on an incoming call. Using SER as a proxy, we get
the SIP URI instead of simply the telephone number.
IMO you are then left with experimenting and changing
SIP requests in
a way that increases the chance that the phone shows what you want to
be shown. There is no guarantee however it will work for all phones
in a consistent way.
If I were you, I would try appending P-asserted-identity or
Remote-Party-ID header fields with tel URIs (benefit: use of a header
field does not change request URI, which might have side effects
otherwise, and use of TEL URI eliminates the domain). If that does
not work, I would try to put TEL URI in request-URI.
I'll see what I can come up with but it looks like using SER as an
outbound proxy isn't quite solving the main issue (NAT traversal)
anyway.
Thanks!
--
Charles Ulrich
Ideal Solution, LLC -- http://www.idealso.com
10 Jul
10 Jul
12:16 p.m.
Charles Ulrich wrote:
You mean SIP doesn't have some kind of caller ID
header? When these
phones are registered directly with Asterisk, caller ID works exactly
like a legacy non-SIP phone: Only a name and a number (or extension)
appear on the display on an incoming call. Using SER as a proxy, we get
the SIP URI instead of simply the telephone number.
The display name part of the From header has been designed to serve
this purpose. You should have a close look at the messages generated
by your Asterisk server to determine the differences between these
and those generated by SER.
Regards,
Olaf
2:13 p.m.
At 16:19 09/07/2007, Charles Ulrich wrote:
Indeed it cannot. You have to use rtp-proxy in addition to SER -- SER
does only signaling, rtp-proxy fixes media.
-jiri
On Friday 06 July 2007 04:41, Jiri Kuthan wrote:
perhaps you are using Asterisk in H.323 mode? Messages from asterisk,
as long as in SIP mode, follow the same protocol as SER does...
Hi Charles,
Is the 'voip edition' somewhere available? I would be eager to give
it a try on my WRT too.
Sure. There's no direct link, so you have to click through the following
trail of links:
* Go to www.dd-wrt.com
* Downloads
* stable
* dd-wrt.v23 SP2
* voip
* dd-wrt.v23_voip.bin
Use this if you have a WRT54Gv4 or WRT54GL, otherwise check the
documentation to find out which firmware image you need. DD-WRT works
on a couple of other router brands too, such as Buffalo, Belkin, and
ASUS.
I'm a bit sceptical how much we can do about
it, since the URIs are
part of the SIP protocol machinery and it is up to discretion of a
telephone implementation to show what it wants to show (there is no
standard for what a telephone shall display).
You mean SIP doesn't have some kind of caller ID header? When these
phones are registered directly with Asterisk, caller ID works exactly
like a legacy non-SIP phone: Only a name and a number (or extension)
appear on the display on an incoming call. Using SER as a proxy, we get
the SIP URI instead of simply the telephone number. IMO you are
then left with experimenting and changing SIP requests in
a way that increases the chance that the phone shows what you want to
be shown. There is no guarantee however it will work for all phones
in a consistent way.
If I were you, I would try appending P-asserted-identity or
Remote-Party-ID header fields with tel URIs (benefit: use of a header
field does not change request URI, which might have side effects
otherwise, and use of TEL URI eliminates the domain). If that does
not work, I would try to put TEL URI in request-URI.
I'll see what I can come up with but it looks like using SER as an
outbound proxy isn't quite solving the main issue (NAT traversal)
anyway. Thanks!
--
Charles Ulrich
Ideal Solution, LLC -- http://www.idealso.com
--
Jiri Kuthan http://iptel.org/~jiri/
7 Jul
7 Jul
7:31 a.m.
Hi!
Charles Ulrich wrote:
The only drawback is that when using this method, the
caller ID on an
incoming call from the PSTN contains a SIP URI (in the form of
sip:5551212@207.179.x.x) instead of a simple telephone number.
That's just how SIP URIs are supposed to look ;)
Your phone receiving the calls might be able to use additional
fields/headers to display a number/displayname that does not contain
the IP.
Try setting the displayname on the caller side.
More appropriate would be to use P-Asserted-Identity (RFC3325) or
Remote-Party-ID if that gets the job done on your phones.
If you trust your callers you can use SER to copy the userpart (aka
phonenumber in your case) from the From URI into a P-Asserted-Identity.
I hope that helps,
Hendrik
--
Hendrik Scholz <hscholz(a)raisdorf.net> http://www.wormulon.net/
6349
days inactive
6356
days old
6 comments
5 participants
participants (5)
-
Charles Ulrich -
Hendrik Scholz -
Jiri Kuthan -
Olaf Bergmann -
Stefan Sayer