http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/white_paper_c11-620461.html
A lot of people seemed to like my Definitive Jumbo Frames blog entry so I was inspired to do another blog post on SIP and try and be as exhaustive on the topic as I can. SIP trunks are becoming more and more important. So here is my attempt to be thorough and document it.
SIP and NAT
We have already spoken earlier about the importance of SDP and why it plays such a crucial role in SIP, but an SDP datagram contains a particular IP address that is very important:
The connection address controls what address other end will attempt to connect to, as you can see in this output the IP address is a private address. This is often caused by the use of NAT obviously and can lead to many problems, the most common is one way audio.
There are several ways that we can overcome this.
Client-Server Methods
ICE
STUN
STUN, which stands for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators was one of the earlier methods to resolve some of these issues, it is useful in some scenarios.
The client will attempt to discover a STUN server that will help it determine it's outside IP address so that the client is then smart enough to change the SDP packet that it sends out to reflect the true IP address. Simple and elegant.
The great thing about STUN too is that the server or VOIP provider your using for VOIP doesn't necesseraily have to be your STUN server. A STUN server is an optional part of SIP and does not have to be implemented, CUCM does not implement it for example.
There are several STUN servers available out on the internet, stun.counterpath.com for example, which we will configure to show how STUN works below:
TURN
Router Methods (Interception Methods)
http://www.cisco.com/c/en/us/solutions/enterprise/interoperability-portal/networking_solutions_products_genericcontent0900aecd805bd13d.html
So, what are we going to try and cover in this post.. Pretty much everything.
We will start by talking about SIP theory and going through SIP theory in great detail, This will involve quite a few wireshark and packet capture outputs, we will dissect common SIP call flows as well as SIP registrations.
We will clear up SIP terminology to make our lives easier.
Next, we will look at DTMF digits, Redirects and other things
Then, we will start getting into more Cisco-Specific things like:
- What is CUBE?
- Why do I need it?
- When can I get away without CUBE and just have a SIP trunk straight from CUCM? Why would I want/Not Want to do that?
- When do I need an MTP
- SIP Normalization
- SIP Profiles/SIP Trunks
- Explore Voice gateway SIP config options and see what they can do for us.
I am going to assume you already have wireshark or your favorite packet capture utility, so that's all good, next you will want a SIP soft phone that registers directly to a SIP provider and/or SIP trunk itself for the purpose of our testing.
A good one that exists for both Mac and Windows is X-lite, it's an absolute pain to find the correct download link as there is two versions, one is a free version and one is a paid product. I am sure the paid product has lots of great features that might be useful but in this example I only use the free one.
http://www.counterpath.com/xlite-comparison.html
Next, we need to get a SIP trunk to test with. I am convinced that if your going to implement SIP for the first time, your better off trying it out in a test environment first to make sure your comfortable with the configuration. I looked for a SIP provider who was sort of like "pre-paid" were I didn't have to sign up and pay a monthly fee.
I found net2phone and I am quite happy with them (disclaimer: I was given absolutely NO incentive from net2phone to say this, I'm just a happy customer) but please replace net2phone with whoever you would prefer to use.
http://www.net2phone.com/
SIP Theory
(Please note, much of this content is paraphrased and collected from other great great sites with great information, a List of reference sites will be included)
( Site Links:
http://www.iptel.org/sip/
http://www.siptutorial.net/SIP/
)
SIP Failover/Redundancy
http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/white_paper_c11-620461.html
DTMF
How to show DTMF:
show call active voice | inc tx_DtmfRelay
Troubleshooting command to check out:
#show sip-ua calls
PeterCCIE18371#show sip-ua statistics
SIP Response Statistics (Inbound/Outbound)
Informational:
Trying 121/283, Ringing 116/109,
Forwarded 0/0, Queued 0/0,
SessionProgress 3/3
Success:
OkInvite 100/255, OkBye 88/61,
OkCancel 31/42, OkOptions 0/0,
OkPrack 2/2, OkRegister 0/408
OkSubscribe 82/157, OkNotify 2059/180, OkPublish 0/0
OkInfo 0/0, OkUpdate 6/14,
202Accepted 0/0, OkOptions 0/0
Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :
MultipleChoice 2, MovedPermanently 0,
MovedTemporarily 20/11, UseProxy 0,
AlternateService 0
Client Error:
BadRequest 0/0, Unauthorized 0/39366,
PaymentRequired 0/0, Forbidden 0/0,
NotFound 4/1331, MethodNotAllowed 0/0,
NotAcceptable 0/0, ProxyAuthReqd 0/0,
ReqTimeout 0/0, Conflict 0/0, Gone 0/0,
ConditionalRequestFailed 0/0,
ReqEntityTooLarge 0/0, ReqURITooLarge 0/0,
UnsupportedMediaType 0/0, UnsupportedURIScheme 0/0,
BadExtension 0/0, IntervalTooBrief 0/0,
TempNotAvailable 0/0, CallLegNonExistent 3389/77,
LoopDetected 0/0, TooManyHops 0/0,
AddrIncomplete 0/0, Ambiguous 0/0,
BusyHere 0/2, RequestCancel 32/42,
NotAcceptableMedia 0/0, BadEvent 0/5,
SETooSmall 0/0, , RequestPending 0/0
UnsupportedResourcePriority 0/0
Server Error:
InternalError 0/3, NotImplemented 0/0,
BadGateway 0/0, ServiceUnavail 5/2,
GatewayTimeout 0/0, BadSipVer 0/0,
PreCondFailure 0/0
Global Failure:
BusyEverywhere 0/0, Decline 0/0,
NotExistAnywhere 0/0, NotAcceptable 0/0
Miscellaneous counters:
RedirectRspMappedToClientErr 0
SIP Total Traffic Statistics (Inbound/Outbound)
Invite 283/160, Ack 290/159, Bye 62/89,
Cancel 45/32, Options 0/0,
Prack 2/2, Update 14/6,
Subscribe 1738/3684, Notify 257/27750, Publish 0/0
Refer 0/0, Info 0/0,
Register 41203/0
Retry Statistics
Invite 8, Bye 1, Cancel 1, Response 45,
Prack 0, Reliable1xx 0, Notify 24177, Info 0
Register 0 Subscribe 202 Update 0 Options 0
Publish 0
Right now i am studying SIP, and it is talking about DTMF-Relay.
To cut a long story short: DTMF-Relay for SIP dial-peers is RTPE-NTE, RTP-NTE is in-band signalling, meaning it is part of the RTP stream, the problem is that SCCP Phones don't understand RTP-NTE! So they cannot send or receive the DTMF tones correctly.
The way to resolve this is to either:
1. Run an MTP and enable this for the trunk for CUCM (this is your only option in CUCM 4)
2. Change the dtmf-relay method on the dial-peer using
#dial-peer voice 999 voip
#dtmf-relay
Now, the thing is, when i tried thsi with my SIP provider it failed miserably, that is because the SIP provider is expecting the digits as SIP-NOTIFY, the cisco routers have a solution to this too..
for gateways running CCME with SIP trunks, you need to configure RTP-NTE. This will convert the signalling received from the SCCP phones to Named Telephony Event (Which is an RFC supported by most SIP providers.)
Here is some more info i found:
The last blog entry covered DTMF relay. This blog entry will focus on Cisco IP Phone and Cisco SIP Trunk DTMF relay support. Cisco’s first generation of IP phones do not support RFC2833 DTMF-Relay. All digits are sent out of band in either SCCP or SIP signaling packets depending on the phone load. Cisco first generation phones are referred to as Type A phones in the Cisco Unified Communications Manager 6.x SRND (Solution Reference Network Design) guide available at www.cisco.com/go/srnd. Type A phones include the following phones:
• 7902
• 7905
• 7910
• 7912
• 7940
• 7960
Cisco’s second generation phones support RFC2833 DTMF Relay when registered with Cisco Unified Call Manager versions 5.0 and later. These phones include the following:
• 7906
• 7911
• 7941
• 7942
• 7945
• 7961
• 7962
• 7965
• 7970
• 7971
• 7975
Source; http://www.networkworld.com/community/node/30207
# ---- Opinion Section ----#
SIP is yet another topic that does my head in, a "standard" that no one seems to implement in the same way, meant to be our engine for voice, video and IM until XMPP came on the scene, ridiculous restrictions from Telcos with SIP such as this idea of "Concurrent call" pricing, as if it's an ISDN line where each physical line actually costs them money. They could very easily give you as many channels as you had bandwidth but they LOVE the concurrent call business model even if they can't justify it technically (a lot like SMS: costs them literally nothing to send but they still charge for it.)
But, there is no getting around it that SIP is here to stay. Almost all new PSTN connections in the united states now are SIP based.
SIP also offers some exciting concepts such as URI dialing, I am absolutely positive that eventually we will do away with the antiquated notion of telephone numbers and instead will start to rely on URI dialling heavily, It wouldn't be terribly difficult for someone like apple to say "Guess what! You don't have to remember peoples telephone numbers, if you know they have an IPhone you can ring them at their App Store registered email address."
Maybe it will be some other system, but I am convinced telephone numbers are going to go away at some point.
# ---- Opinion Section ----#
PETE IMPORTANT LINK:
ALSO GOOD IDEA IS TO MAKE A PUBLIC ACCESSIBLE SERVICE THAT PERFORMS SIP TRUNK HEALTH CHECKS (CHECKS CORRECTLY FOLLOWING RFC'S AND PRODUCES INFO ABOUT SUPPORTED CODECS, DTMF METHODS ETC)
No comments:
Post a Comment