Ask the Cisco VIP: Troubleshooting SIP in Cisco Unified communications

[ciscomoderator]

Troubleshooting SIP in Cisco Unified communications deployments with Cisco VIP Ayodeji Okanlawon

This is a Q&A Ask the Expert Session continuation from the Live Webcast

Ask your questions on Session Initiation Protocol (SIP) and how it is redefining our UC world.The Session Initiation Protocol (SIP) is a signaling communications protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP) networks.

Featured Expert

Ayodeji Okanlawon, a Cisco Designated VIP, is the Lead Consultant Engineer for Global Solutions Design and Engineering at Verizon Business. In his past, he has worked at Intact IS, NCS Global, and Schlumberger Information Solutions. His experience includes development of design and deployment of large scale IP telephony projects on Cisco Call Manager platforms, Cisco Voice gateways, Cisco Jabber cloud and on premise solution. His expertise includes SIP solutions, CUBE design and Deployment, Troubleshooting: Voice gateways, CUCM, Unity connection, CUPS. Deji has been awarded the Cisco Designated VIP in 2013 and 2014. Deji holds a Bachelor of Science (BS), Electrical and Electronics Engineering, Second Class Upper from Obafemi Awolowo University.  

According to Deji, “If you want to advance your career, if you’re serious about your skill sets, you’ve got to be in the forums.”  (Read the Interview >>)

We look forward to your participation. This event is open to all, including partners.

* * Remember to use the rating system to let Deji know if you have received an adequate response. * *

Deji might not be able to answer each question due to the high volume expected during this event. This event runs January 13 through January 23, 2015.  Visit this forum often to view responses to your questions and the questions of other community members.

[Lisa Latour]

(derrick shumake) Q:   are there many security concern using SIP?

[Ayodeji Okanlawon]

Derrick,

RFC 3261defines ways to provide increased security for a SIP session.

The following describes areas in SIP that provides security for the protocol

1. Authenticating users.

We need to authenticate a user to ensure that the sender of the message is who he claims to be.

To achieve this SIP uses digest authentication between a UAC, proxy and a UAS. This provides the most basic level of authentication challenge between a client, proxy and a server.

2. Secure SIP signalling

The next area we can secure is SIP signalling itself. For this we use SSL/TLS. This is similar to using https in web browsers. With TLS before our any signalling is exchange X.509 certificates are used create a secure TLS channel. All our SIP messages are then transported within the secure channel.

NB: The digest authentication mentioned above for authenticating a user agent is just authentication. The messages are not protected from reading or modification hence it is recommended that these messages are carried inside a secure TLS channel for better security.

3. Privacy and Identification

Additional security features in SIP provides means where any user can choose to either reveal or conceal his identity.

4.Secure RTP

SIP also provides the ability to secure the media channel. It is not enough to secure signalling while anyone can listen to the media. RFC3830 discusses how the encryption should be done.

5. S/MIME

S/MIME encapsulation is used to protect sip headers making it impossible for any one in between the sender and receiver to modify the sip headers

Regards

[Lisa Latour]

(HAMID ABBOU) Q: in CUBE setup, sometimes I do not see reason code from remote party but CUBE add reason cause when relaying the reply to other party. is this normal behaviour?

[Ayodeji Okanlawon]

Hamid,

Thank you for taking time to join us for the webcast. I hope you found it useful.

I am assuming that the reason code you are referring to here is seen when a BYE or CANCEL request is sent or received.

The status code seen in the reason header field is not mandatory. It is optional. The reason header field was created to be used to share reasons why a session was terminated.

Here is an excerpt from rfc4411(https://tools.ietf.org/html/rfc4411)

"In the event that a session is terminated for a specific reason that can (or should) be shared with SIP Servers and UAs sharing dialog, the Reason Header [1] was created to be included in the BYE Request"

You can also refer to rfc3326 for more details.

https://www.ietf.org/rfc/rfc3326.txt

This implies that Cisco has implemented CUBE to include status code in the reason header field while some other vendors have not. This is normal as it is optional to include it.

Let me know if this answers your question.

Regards

[Hamid ABBOU]

Deji,

Thanks for the answer.

Hamid

[Lisa Latour]

(manjleen bhasin)
Q: Hi I just have a doubt what is the difference between p-preferred and p-asserted field in a INVITE message

[Ayodeji Okanlawon]

Hi Manjleen,

Thank you for joining us for the webcast.

P-Preferred-Identity:  Is used when a user has multiple Public identities.( e.g. multiple numbers) 

NGN servers use the PPID header to identify the preferred number that the caller wants to use. The PPID is part of INVITE messages sent to the NGN. When the NGN receives the PPID, it authorizes the value, generates a PAID based on the preferred number, and inserts it into the outgoing INVITE message towards the called party.

Your ITSP operates within an NGN network.

[Yannick Vranckx]

Hello Ayodeji,

I have a question regarding the CUCM database:

- In which format is it made?

- Are there some recommended tools to connect a CUCM database between an SQL one

- Is there also a tool to copy configuration from a user to another

Thanks for the information

[Ayodeji Okanlawon]

Yarnick,

This question should be asked in the IPT forum. This is not the correct place for it.

[Mike Assel]

Deji, fantastic webcast!  Thanks for sharing your knowledge.  Could you help me understand how the c line (connection information) in an SDP is used?  I have a SIP endpoint that is NAT'd 1:1 behind a firewall.  When an external endpoint calls in, the call fails because the external endpoint is sending the media stream to the private IP address of the endpoint it is calling.  I'm assuming it is getting that IP address from the c line in the SDP.  However, when the NAT'd endpoint places an outbound call to the same external endpoint, the call is successful and media flows properly, however the SDP from the NAT'd endpoint is still using the private IP address.   I would have thought both calls would fail.  Am I missing something? 

Thanks,  Mike

[Ayodeji Okanlawon]

Mike,

Each UAC/UAS determines where to send its media to based on the address in the connection info or connection data.

You are correct that the C= field is obtained from the SDP exchanged between the client and server.

Traditional firewalls are prone to issues like this,this is because traditional firewalls can only modify the ip headers in a sip packets leaving the Payload/SDP portion unchanged. This implies that when an INVITE is sent to the firewall facing the internet, the source ip i.e. from header will be modified to use the NATed ip address, however the media ip address (c=) which is usually in the SDP will remain unchanged, hence the endpoints on the internet cant connect to this address leaving you with one way audio issues or audio issues.

Yes I expect that if the c= field is pointing to the private ip address, the call should fail. Can you attach a debug ccsip messages here and we can look at whats going on

[Mike Assel]

That's why I'm confused.  When I RECEIVE a call from the NAT'd endpoint, the call is successful.  I can see in the SDP that c= a private IP address, but my endpoint send its media stream to the public IP that the request came in on.  I'm trying to understand why it would use the public IP address for media and not the private IP address in the (c) line.  Can I email you the traces?  They have the customer's IP info in them.  Thanks so much for the assistance.

Mike

[Ayodeji Okanlawon]

Mike,

I can see what you are saying from the traces. The INVITE to the expressway-e has the private ip in its c= parameter. Where is the endpoint registered to? Is the firewall changing the c= filed to the public IP? It may be firewall modifying this.

This call looks to have been successful. I can see rtp media flow between expwe and the public endpoint.

Can you let me know what the issue is at the moment.

Is there a trace for a failed call?

[Mike Assel]

The NAT'd endpoint (belonging to the customer) is registered to nothing.  It is standalone.  My endpoint is registered to CUCM 10.5.  My firewall is not changing anything as well have inspection turned off and we use expressway for firewall traversal.  The call is successful, but the problem is I don't know why.   Shouldn't the expressway send the media to the private IP address in the (c) line?  Now, if I place the call the other way, so I call from my endpoint, through the expressway, to the customer's NAT'd endpoint, then the call fails because Expressway sends media to the private IP contained in the (c) line.  I will send you a capture of this.

So I know why the call fails when I place the call, but why does the call succeed when I receive a call from the same endpoint?

Mike

[Ayodeji Okanlawon]

Looking at the packet capture for the working call, I observed that the public IP address of the external endpoint doesn't appear in any of the SIP headers. The only place it appears is in the wire shark source/destination addresses. So this is very strange. We need to look at the expwe diagnostics logs.Can you set it to debug and do a test call for inbound call. Let me know the calling and called numbers.