SIP: Session Initiation Protocol. Copyright by Elliot Eichen. All rights reserved.

Transcription

1 SIP: Session Initiation Protocol

2 Signaling Protocol Review H323: ITU peer:peer protocol. ISDN (Q.931) signaling stuffed into packets. Can be TCP or UDP. H225: Q931 for call control, RAS to resolve endpoints (Gateway Gatekeeper signaling) H245: Multimedia Control Protocol (including fast start) Uses RTP for media MGCP (MEGACO): IETF Master:slave,very granular messages, typically used by softswitches to control endpoints, media gateways, etc. Also uses RTP for media. SIP: IETF peer-peer protocol. Plain text, messages look like http. SDP (Session Description Protocol) used to negotiate RTP. DNS (SRV records) used to resolve URIs Typically UDP (except for secure SIP, which is usually SIP running over TLS/TCP

3 SIP: Related Protocols Secure SIP: SIP:TLS (transport layer security): UDP IP-SEC (used typically only between servers) S/MIME (interesting solution for end-end encryption of portions of the SIP message, such as the encryption keys for SRTP). Media: SDP: negotiates codecs, ip_address:port, etc. Carried in the SIP message. RTP: time stamps & sequence # (jitter, lost packets), packet type (what type of codec). SRTP: encrypted RTP, keys not negotiated in the media ZRTP: (encrypted RTP (Zimmerman s verison), keys negotiated in the media channel. RTCP: quality and control channel for RTP (port=rtp+1) H.264 (and 263): Video compression DNS: SRV records, ENUM STUN & ICE: NAT traversal.

4 SIP Network Elements User Agent: endpoints that originate or terminate SIP calls => IP Phones, Softclients, etc. SIP Servers: Proxy/Redirect: routing of SIP messages Location: endpoints register here, binds IP address to URIs & telephone numbers Back:Back User Agents: terminate and re-launch SIP message (often used by IP PBXs, SBCs, feature servers, etc.) Feature Servers: SIP interface, used to provide functionality (calling services, voic , conferencing, credit card, etc.) Media Gateways: PSTN VoIP interworking: Media: RTP to B channel Signaling: SIP or MGCP to Q.931(PRI) to ISUP(SS7),

5 SIP Methods (from voip-info.org) SIP methods defined in the SIP RFC (3261) SIP method invite : Invite another UA to a session SIP method invite re-invite: Change UA within an existing session SIP method register: Register a location with a SIP Registrar server SIP method ack: Used to facilitate reliable message exchange for INVITEs SIP method cancel: Cancel an invite SIP method bye: Hangup a session SIP method options: Query/response of UA capabilities (codecs, etc.) SIP method extensions from other RFCs SIP method info: out of band signaling info, like DTMF RFC 2976 SIP method notify: report events, RFC 2848 PINT SIP method subscribe: subscribe to events, RFC 2848 PINT SIP method unsubscribe: duh RFC 2848 PINT SIP method update: Extension in RFC 3311 SIP method message: Extension in RFC 3428 SIP method refer: 3 rd party call control, transfer, RFC 3515 SIP method prack: provisional ACK, intermediate response to ACK, RFC 3262 SIP method PUBLISH: think this is like a NOTIFY RFC 3903 SIP SIMPLE: Instant Messaging implemented using SIP (competing protocol is xmpp, also proprietary protocols like AOL.)

6 SIP Header Fields INVITE SIP/2.0 Via: SIP/2.0/UDP :22164;rport;branch=z9hG4bK4CD60C From: Hillary Clinton To: Contact: Call-ID: CSeq: INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105x Content-Length: 318 Method = INVITE, uses SIP version 2.0 VIA = How the message is routed (when using record route, you get full list of servers the call is routed through). Contact: SIP URL of the guy sending the message (usually = FROM) Call-ID: each session (call) has a unique call-id. Used to provide state within a session, also for accounting. CSeg: +1 for each request within a session User Agent: user agent name & version Content-Length: number of bytes in the message

7 SDP: Session Description Protocol v=0 o= IN IP s=sip Call c=in IP t=0 0 m=audio RTP/AVP c=in IP a=fmtp: a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 v: version o: origination info, <username> <session id> <version> <network type> <address> s: session name t: <start> <stop> times c: Connection info m: media session <media type> <port to send media> <type of media> <list of fmtp types, e.g., media types, that the client can support a: attrbutes as <name> <value> pairs k: encryption key (can be here, or can be carried in the SIP message)

8 Simple Call Flows Hello World

9 Hello World Ladder Diagram

10 Example: Call goes to voic with MWI Extension 3004 calls extension 3002 through an Asterisk IP-PBX (acting as a B:B UA) Extension 3002 is busy. Asterisk moves the call to itself to the voic server on the box Voic is left (RTP between ext 3004 and the asterisk server). Asterisk sends a SIP NOTIFY with event type = MWI (message waiting indicator) to ext 3002

11 U :5060 -> :5060 INVITE SIP/2.0. Via: SIP/2.0/UDP :5060. From: To: Call-ID: CSeq: 2 INVITE. Contact: <sip:3004@ :5060;user=phone;transport=udp>. User-Agent: Cisco ATA 186 v3.1.0 atasip (040211A). Proxy-Authorization: Digest username="3004",realm="asterisk",nonce="1fdb7e7b",uri="sip:3002@ ",response="a 3bffacca0568". Expires: 300. Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER. Content-Length: 247. Content-Type: application/sdp.. v=0. o= IN IP s=ata186 Call. c=in IP t=0 0. m=audio RTP/AVP a=rtpmap:0 PCMU/8000/1. a=rtpmap:4 G723/8000/1. a=rtpmap:8 PCMA/8000/1. a=rtpmap:101 telephone-event/8000.

12 U :5060 -> :5060 SIP/ Trying. Via: SIP/2.0/UDP :5060. From: To: Call-ID: CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: <sip:3002@ >. Content-Length: 0.

13 U :5060 -> :5060 INVITE SIP/2.0. Via: SIP/2.0/UDP :5060;branch=z9hG4bK06dae12e. From: "3004" To: Contact: Call-ID: CSeq: 102 INVITE. User-Agent: Asterisk PBX. Date: Sun, 14 Nov :19:49 GMT. Alert-info: Bellcore-dr1. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Content-Type: application/sdp. Content-Length: v=0. o=root IN IP s=session. c=in IP t=0 0. m=audio RTP/AVP a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:

14 U :5060 -> :5060 SIP/ Busy here. Via: SIP/2.0/UDP :5060;branch=z9hG4bK06dae12e. From: "3004" To: Call-ID: Date: Sun, 14 Nov :19:49 GMT. CSeq: 102 INVITE. Server: CSCO/4. Contact: Content-Length: 0. U :5060 -> :5060 ACK sip:3005@ :5060 SIP/2.0. Via: SIP/2.0/UDP :5060;branch=z9hG4bK06dae12e. From: "3004" <sip:3004@ >;tag=as39b4da84. To: <sip:3002@ >;tag=000628f0f9f2000d7a71ad55-38f1a626. Contact: <sip:3004@ >. Call-ID: 637e ad07d4e39a7e6ef404@ CSeq: 102 ACK. User-Agent: Asterisk PBX. Content-Length: 0.

15 U :5060 -> :5060 SIP/ OK. Via: SIP/2.0/UDP :5060. From: To: Call-ID: CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: <sip:3002@ >. Content-Type: application/sdp. Content-Length: v=0. o=root IN IP s=session. c=in IP t=0 0. m=audio 5812 RTP/AVP a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:

16 U :5060 -> :5060 ACK SIP/2.0. Via: SIP/2.0/UDP :5060. From: To: Call-ID: CSeq: 2 ACK. User-Agent: Cisco ATA 186 v3.1.0 atasip (040211A). Proxy-Authorization: Digest username="3004",realm="asterisk",nonce="1fdb7e7b",uri=" Content-Length: : :5812

17 U :5060 -> :5060 NOTIFY SIP/2.0. Via: SIP/2.0/UDP :5060;branch=z9hG4bK361f812f. From: "asterisk" To: Contact: Call-ID: CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Event: message-summary. Content-Type: application/simple-message-summary. Content-Length: 37.. Messages-Waiting: yes Voic 2/0 # U : > :5060 SIP/ OK. Via: SIP/2.0/UDP :5060;branch=z9hG4bK361f812f. From: "asterisk" <sip:asterisk@ >;tag=as39e043e0. To: <sip:3002@ >. Call-ID: 3a86cecd339da70710f761f11e0515d4@ Date: Sun, 14 Nov :20:04 GMT. CSeq: 102 NOTIFY. Content-Length: 0.

18 ext Asterisk ext 3002 INVITE TRYING INVITE BUSY OK ACK RTP (although, you can't see this from the SIP debug) BYE ACK So, you can t tell but Asterisk server is sending this call to voic . Media goes to the asterisk server NOTIFY OK And now the asterisk server sends ext 105 a MWI notification. OK

19 SIP: How to Authenticate the sender of a SIP message? Invite 407 Proxy Auth Req, with nonce ACK Invite with response ok Digest Authentication http world Assumption: shared secret (sip password) between endpoints exists (generally passed to the endpoint during the provisioning process). Initial method rejected for example, recipient replies with Proxy Authentication Required WWW-Authenticate: Digest realm="mit.edu", nonce="47a23e53632ff1c28b41f12591b970586d6 da3dc Second try uses the nonce, the passwd, & other fields to form a response which validates the identity of the sender Authorization: Digest username=" ", realm="mit.edu",nonce="47a23e53632ff1c28b41f 12591b970586d6da3dc",response="fbab4f8c828c a550da0956d648d8d09a",uri="sip:mit.edu"

20 Digest Authentication: SIP Decision of which sip messages to challenge is up to the system (beauty in the eye of the system architect). INVITES REGISTERS BYES REFERS ACKS Digest Authentication provides authentication and immunity from replay attacks. It does not provide any privacy or guarantee message integrity. SIP messages still in plain text, can be read. Man in the middle could change some of the fields in a SIP message Other forms of encryption (TLS, IP-SEC, S/MINE, etc.) provide security of the SIP message streams. Typical Deployments Today Often the network proxy server requires authentication of the endpoints for Registration and Invites. Often the endpoints (phones, clients) DO NOT require authentication of the servers. (Very often, an ACL on the endpoints is used to prevent the endpoint from replying to bad guys.

21 Generating the digest response HA1 = MD5{username + : +realm+ : +password} Username = , realm = mid.edu, passwd is the secret not passed in this transaction HA2 = MD5{ sip: + uri from the Request-URI sip header} uri=sip:mit.edu Response = MD5{HA1 + : + nonce + : +noncecount+ : +clientnonce+ : +qop+ : +HA2} Nonce = unique string generated by the challanger Other stuff not so important MD5 = one-way hash, designed to be too hard (for everyone except guys with giant super computers?) to guess the output based upon the input.

22 Replay Attacks Basically, generate a nonce each time you want to challenge the message = or a bad guy could simply respond with the same old stuff. Believe it or not, I ve seen systems that were subject to replay attacks.

23 Summary username=" realm="mit.edu" nonce="47a23e53632ff1c28b41f12591b d6da3dc" uri="sip:mit.edu" sip passwd = response="fbab4f8c828ca550da0956d648 d8d09a Response = hard function (BLUE, RED)

24 Another SIP Example: Shared Call Appearance (Bridged Line Appearance)

25 SUBSCRIBE & NOTIFY: When Mr. Burn s picks up the phone His line key turns red, to show that he s actively on the line Smither s line blinks red, to show him that Mr. Burns is on the line

26 Subscribe/Notify Call Flows