10 Dec
2004
10 Dec
'04
9:05 a.m.
Hello All,
I recenlty installed ser stable version (0.8.14) and I use it with a
couple of Cisco IP Phones and a Cisco 36xx voice Gateway. I installed it
using mediaproxy because some phones are behind a nat and it works fine
for "basic calls" (IP-IP, IP-PSTN and PSTN-IP).
However I have a problem when I try to transfer (using attended
transfer) a call coming from PSTN to a phone that is behind nat. The
problem is the following:
The phone originating the transfer sends correctly the REFER method to
the Voice gateway through SER server containing the refer-to:
number@publicIPaddress but the Gateway sends the INVITE method "directly
to the publicIPaddress of the NAT", and doesn't pass through the SIP
server (that "manages" the messages for the NATed phones) even if I
configured a dial peer voip matching the voip strings and specifying the
server where I have to send the INVITE requests.
My question is: is there any way to configure SER changing the REFER
message in order to "force" the gateway to send the INVITEs through the
server?
Or, anyone knows if something more than dial-peers has to be configured
on Cisco gateways?
Thanks a lot in advance,
Raffaele.
10 Dec
10 Dec
6:27 p.m.
My question is: is there any way to configure SER
changing the REFER
message in order to "force" the gateway to send the INVITEs through the
server?
Or, anyone knows if something more than dial-peers has to be configured
on Cisco gateways?
The short answer is no. It is not supported by cisco. It is a problem not
limited to cisco. Some other pstn gateways have the same problem.
Here is the official cisco answer,
Cheers,
Richard
When a REFER is received by the SIP SPI, it passes the refer-to header up
to the application. This contains the entire uri of the transfer target.
The app then extracts the user portion of the uri to get the E.164
number. The app expects the user portion of the uri to be an E.164
number. If it's not, transfers won't work today.
It sounds like you are requesting the application to perform some
additional logic to do a dial-peer match on the domain portion of the
refer-to URL rather than doing a dial-peer match based on the extracted
E.164 number. This would require enhancement to the IOS application
code. I'm not sure how involved these changes would need to be - that
would require more investigation if this enhancement is pursued.
In addition to the above IOS changes, it would require the user to
configure a voice class uri and apply this uri to the outgoing dial-peer
using the 'destination uri' dial-peer config.
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configurati
on_guide_chapter09186a00801d2ac5.html>
8:55 p.m.
Hello Richard,
thanks for your answer.
I think my case is a little bit different. Read below,
Richard wrote:
But the uri the phone passes to the gateway is in the format
205@nat_public_ipaddres where 205 is an internal number.
I have a dial peer configured in this way:
dial-peer voice 5 voip
application session
destination-pattern 2[0,1,5].
session protocol sipv2
session target sip-server
and when I debug on the router the dial-peer is correcly matched.
However the gateway doesn't send the INVITE to the sip server but
directy to the "nat_public_ipaddress
My question is:
is there any way to configure SER changing the REFER
message in order to "force" the gateway to send the INVITEs through the
server?
Or, anyone knows if something more than dial-peers has to be configured
on Cisco gateways?
The short answer is no. It is not supported by cisco. It is a problem not
limited to cisco. Some other pstn gateways have the same problem.
Here is the official cisco answer,
Cheers,
Richard
When a REFER is received by the SIP SPI, it passes the refer-to header up
to the application. This contains the entire uri of the transfer target.
The app then extracts the user portion of the uri to get the E.164
number. The app expects the user portion of the uri to be an E.164
number. If it's not, transfers won't work today.
It sounds like you are requesting the application to
perform some
additional logic to do a dial-peer match on the domain portion of the
refer-to URL rather than doing a dial-peer match based on the extracted
E.164 number.
This would require enhancement to the IOS application
code. I'm not sure how involved these changes would need to be - that
would require more investigation if this enhancement is pursued.
In addition to the above IOS changes, it would require the user to
configure a voice class uri and apply this uri to the outgoing dial-peer
using the 'destination uri' dial-peer config.
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configurati
on_guide_chapter09186a00801d2ac5.html>
I will try using voice class.
Thanks again,
Raffaele.
8:58 p.m.
Hello Richard,
thanks for your answer.
I think my case is a little bit different. Read below,
Richard wrote:
But the uri the phone send to the gateway in the refer-to is in the
format 205@nat_public_ipaddres where 205 is an internal number.
I have a dial peer configured in this way:
dial-peer voice 5 voip
application session
destination-pattern 2[0,1,5].
session protocol sipv2
session target sip-server
and when I debug on the router the dial-peer is correcly matched.
However the gateway doesn't send the INVITE to the sip server but
directy to the "nat_public_ipaddress
My question is:
is there any way to configure SER changing the REFER
message in order to "force" the gateway to send the INVITEs through the
server?
Or, anyone knows if something more than dial-peers has to be configured
on Cisco gateways?
The short answer is no. It is not supported by cisco. It is a problem not
limited to cisco. Some other pstn gateways have the same problem.
Here is the official cisco answer,
Cheers,
Richard
When a REFER is received by the SIP SPI, it passes the refer-to header up
to the application. This contains the entire uri of the transfer target.
The app then extracts the user portion of the uri to get the E.164
number. The app expects the user portion of the uri to be an E.164
number. If it's not, transfers won't work today.
It sounds like you are requesting the application to
perform some
additional logic to do a dial-peer match on the domain portion of the
refer-to URL rather than doing a dial-peer match based on the extracted
E.164 number.
This would require enhancement to the IOS application
code. I'm not sure how involved these changes would need to be - that
would require more investigation if this enhancement is pursued.
In addition to the above IOS changes, it would require the user to
configure a voice class uri and apply this uri to the outgoing dial-peer
using the 'destination uri' dial-peer config.
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configurati
on_guide_chapter09186a00801d2ac5.html>
I will try using voice class.
Thanks again,
Raffaele.
9:18 p.m.
I have a dial peer configured in this way:
dial-peer voice 5 voip
application session
destination-pattern 2[0,1,5].
session protocol sipv2
session target sip-server
and when I debug on the router the dial-peer is correcly matched.
However the gateway doesn't send the INVITE to the sip server but
directy to the "nat_public_ipaddress
What's the refer-to look like? If there is a match, then cisco uses the
refer-to field uri. It doesn't replace the domain in seesion target.
Richard
13 Dec
13 Dec
10:01 a.m.
Hello richard,
the refer to contains <sip:205@publicnatipaddress;method?INVITE> and
the router sends directly to public_nat_ip_adress. I want to avoid it
trying to send the SIP packet to my SIP server but the destination of
INVITE should be exactly the same specifiied in the refer to.
From the message sent by Juha it seems at the moment this is not supported
by Cisco..
Bye,
Raffaele.
Richard wrote:
I have a dial
peer configured in this way:
dial-peer voice 5 voip
application session
destination-pattern 2[0,1,5].
session protocol sipv2
session target sip-server
and when I debug on the router the dial-peer is correcly matched.
However the gateway doesn't send the INVITE to the sip server but
directy to the "nat_public_ipaddress
What's the refer-to look like? If there is a match, then cisco uses the
refer-to field uri. It doesn't replace the domain in seesion target.
Richard
7155
days inactive
7158
days old
5 comments
2 participants
participants (2)
-
Raffaele -
Richard