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!
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
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.
get http://dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fstable%2Fdd-wrt.v23%20S... or directly the one for your router http://dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fstable%2Fdd-wrt.v23+SP2...
Regards Stefan Sayer
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 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
At 16:19 09/07/2007, Charles Ulrich wrote:
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.
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...
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.
Indeed it cannot. You have to use rtp-proxy in addition to SER -- SER does only signaling, rtp-proxy fixes media.
-jiri
Thanks!
Charles Ulrich Ideal Solution, LLC -- http://www.idealso.com
-- Jiri Kuthan http://iptel.org/~jiri/
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
-
Charles Ulrich -
Hendrik Scholz -
Jiri Kuthan -
Olaf Bergmann -
Stefan Sayer