09-06-2012 03:47 AM - edited 03-11-2019 04:50 PM
Platform: ASA 8.3(2)
Hello,
I have SIP devices along with SipTrunk and media endpoints. I am having issues with the ASA not dynamically opening (sip inspect enabled) UDP ports for RTP after a SIP re-invite causes the media endpoints to change within SDP.
The problem as below.
Initial SIP invite setups properly with ports dynamically opened between the media endpoints in the ASA
Re-inivite from the SIP device causes the media endpoints to change within the SDP
ASA blocks ports associated to the new media endpoints
I can resolve this by allowing the ports in the ACL, but suprised this is not working as re-invites to change media endpoints is to be expected in SIP conversation.
Regards,
AJ
Solved! Go to Solution.
11-13-2012 11:55 AM
Hello Ahmed,
Great, thanks for the resolution,
Do mark the question as answered so future users can learn from your solution.
Kudos to you
09-06-2012 09:33 AM
Hello Ahmed,
Looks like the ASA is doing it's job regarding the SIP inspection..
That being said is also failing as there are re-invites that will come from a diferent media endpoints, correct?
I mean that would be expected as the ASA already open and mantain on it's stateful table a particular SIP connection between 2 endpoints, if the endpoints change then of course they will be blocked.
Let me know if I understood this properly?
Julio
09-06-2012 01:07 PM
Hi Julio,
Thanks for the update. The initial invite in the SIP call is correctly setup by a SIP proxy and SIP trunk using a media device and a SIP Trunk. The SIP end points (sip proxy and sip trunk) stay the same for the entire duration of the call, a reinvite occurs to change the media end points in the SDP in order to establish T38 between a new media end point and the SIP trunk (Same SIP call). Since the ASA already had ports opened for this SIP call, isn't it just a case of updating ip addresses/ports for the new end points as this is to be expected in a SIP call.
Ahmed,
Sent from Cisco Technical Support iPad App
09-06-2012 01:41 PM
Hello Ahmed,
It is definetly expected for the ports but I am not sure about the IP addresses, I mean the ASA will notice that there is no Connection between those 2 hosts.
What does the logs say?
Regards,
Julio
09-06-2012 02:14 PM
Logs show the ASA denying the packets, endpoints/ports correspond to SIP SDP for the reinvite.
Sent from Cisco Technical Support iPad App
09-06-2012 02:25 PM
Hello Ahmed,
Where is the connection being innitiated (Inside or outside)????
What the ASA is going to do with the SIP protocol is follow the signaling exchange of information so the data chanel can be open dynamically with no problem ( Open the required ports for the endpoints over the communication) that is why the endpoints do not need to change,
Regards,
Julio
09-06-2012 02:33 PM
Outside. I have allowed SIP from the SipTrunk to my SIP device.
Per the SIP RFC this should work as this normal SIP behaviour.
"During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
party does not accept the change, he sends an error response such as
488 (Not Acceptable Here), which also receives an ACK. However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics"
http://www.ietf.org/rfc/rfc3261.txt
Sent from Cisco Technical Support iPad App
09-06-2012 03:01 PM
Hello Ahmed,
Good, we are getting closer,
May I see the NAT and the ACL configuration to make this work.
09-09-2012 04:26 AM
Below is the script you can use to reproduce this. Points worth mentioning.
!
ASA 8.3 (2)
!
conf t
!
interface Ethernet0/0
nameif Inside_Voice
security-level 100
ip address 10.1.2.11 255.255.255.0 standby 10.1.2.12
exit
!
interface Ethernet0/1
nameif Outside_SIP_Trunk
security-level 0
ip address 10.1.60.254 255.255.255.0 standby 10.1.60.253
exit
!
object-group network SIP_trunks
network-object 1.2.3.0 255.255.255.0
exit
!
object-group service SIP_service
service-object tcp destination eq sip
service-object udp destination eq sip
exit
!
object-group network SIP_inside_servers
network-object host 10.1.2.100
exit
!
access-list Outside_SIP_in extended permit object-group SIP_service object-group SIP_trunks object-group SIP_inside_servers
!
access-group Outside_SIP_in in interface Outside_SIP_Trunk
!
route Outside_SIP_Trunk 0.0.0.0 0.0.0.0 10.1.60.1
!
class-map inspection_default
match default-inspection-traffic
exit
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect icmp error
lass class-default
set connection decrement-ttl
exit
!
service-policy global_policy global
!
end
11-13-2012 05:58 AM
Just FYI, I opened a TAC case and this was failing because of the T38 payload in the SDP of the re-invite. As of now T38 is not supported in ASA codes. Our work around was to allow the relevant ports in ACL so that media traffic was not dropped.
11-13-2012 11:55 AM
Hello Ahmed,
Great, thanks for the resolution,
Do mark the question as answered so future users can learn from your solution.
Kudos to you
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide