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.
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
Hello Richard,
thanks for your answer.
I think my case is a little bit different. Read below,
Richard wrote:
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.
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
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.
Hello Richard,
thanks for your answer.
I think my case is a little bit different. Read below,
Richard wrote:
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.
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
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.
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
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
-
Raffaele -
Richard