Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved. SIP: Session Initiation Protocol.

26
Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved. SIP: Session Initiation Protocol

Transcript of Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved. SIP: Session Initiation Protocol.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

SIP: Session Initiation Protocol

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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, voicemail, conferencing, credit card, etc.)

• Media Gateways:– PSTNVoIP interworking: – Media: RTP to B channel– Signaling: SIP or MGCP to Q.931(PRI) to ISUP(SS7),

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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: 3rd 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.)

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

SIP Header FieldsINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 209.150.62.132:22164;rport;branch=z9hG4bK4CD60C37023D41A08529035ECA54ADADFrom: Hillary Clinton <sip:[email protected]>;tag=1217297847To: <sip:[email protected]>Contact: <sip:[email protected]:22164>Call-ID: [email protected]: 23513 INVITEMax-Forwards: 70Content-Type: application/sdpUser-Agent: X-Lite release 1105xContent-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

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

SDP: Session Description Protocol

• 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)

v=0o=- 3515669133 3515669133 IN IP4 18.8.202.4s=SIP Callc=IN IP4 18.8.202.4t=0 0m=audio 23400 RTP/AVP 0 101c=IN IP4 18.8.202.4a=fmtp:101 0-16a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Simple Call Flows – Hello World

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Hello World – Ladder Diagram

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Example: Call goes to voicemail – 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

voicemail server on the box• Voicemail 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

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.101:5060 -> 192.168.0.110:5060INVITE sip:[email protected];user=phone SIP/2.0.Via: SIP/2.0/UDP 192.168.0.101:5060.From: <sip:[email protected];user=phone>;tag=705048313.To: <sip:[email protected];user=phone>.Call-ID: [email protected]: 2 INVITE.Contact: <sip:[email protected]: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:[email protected]",response="a1bb3a7501b0982650a93bffacca0568".Expires: 300.Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER.Content-Length: 247.Content-Type: application/sdp..v=0.o=3004 1882 1882 IN IP4 192.168.0.101.s=ATA186 Call.c=IN IP4 192.168.0.101.t=0 0.m=audio 10002 RTP/AVP 0 4 8 101.a=rtpmap:0 PCMU/8000/1.a=rtpmap:4 G723/8000/1.a=rtpmap:8 PCMA/8000/1.a=rtpmap:101 telephone-event/8000.a=fmtp:101 0-15.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.110:5060 -> 192.168.0.101:5060SIP/2.0 100 Trying.Via: SIP/2.0/UDP 192.168.0.101:5060.From: <sip:[email protected];user=phone>;tag=705048313.To: <sip:[email protected];user=phone>;tag=as6ce511fd.Call-ID: [email protected]: 2 INVITE.User-Agent: Asterisk PBX.Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.Contact: <sip:[email protected]>.Content-Length: 0.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.110:5060 -> 192.168.0.105:5060INVITE sip:[email protected] SIP/2.0.Via: SIP/2.0/UDP 192.168.0.110:5060;branch=z9hG4bK06dae12e.From: "3004" <sip:[email protected]>;tag=as39b4da84.To: <sip:[email protected]>.Contact: <sip:[email protected]>.Call-ID: [email protected]: 102 INVITE.User-Agent: Asterisk PBX.Date: Sun, 14 Nov 2004 19:19:49 GMT.Alert-info: Bellcore-dr1.Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.Content-Type: application/sdp.Content-Length: 238..v=0.o=root 28925 28925 IN IP4 192.168.0.110.s=session.c=IN IP4 192.168.0.110.t=0 0.m=audio 22062 RTP/AVP 0 3 8 101.a=rtpmap:0 PCMU/8000.a=rtpmap:3 GSM/8000.a=rtpmap:8 PCMA/8000.a=rtpmap:101 telephone-event/8000.a=fmtp:101 0-16.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.105:5060 -> 192.168.0.110:5060SIP/2.0 486 Busy here.Via: SIP/2.0/UDP 192.168.0.110:5060;branch=z9hG4bK06dae12e.From: "3004" <sip:[email protected]>;tag=as39b4da84.To: <sip:[email protected]>;tag=000628f0f9f2000d7a71ad55-38f1a626.Call-ID: [email protected]: Sun, 14 Nov 2004 19:19:49 GMT.CSeq: 102 INVITE.Server: CSCO/4.Contact: <sip:[email protected]:5060>.Content-Length: 0.

U 192.168.0.110:5060 -> 192.168.0.105:5060ACK sip:[email protected]:5060 SIP/2.0.Via: SIP/2.0/UDP 192.168.0.110:5060;branch=z9hG4bK06dae12e.From: "3004" <sip:[email protected]>;tag=as39b4da84.To: <sip:[email protected]>;tag=000628f0f9f2000d7a71ad55-38f1a626.Contact: <sip:[email protected]>.Call-ID: [email protected]: 102 ACK.User-Agent: Asterisk PBX.Content-Length: 0.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.110:5060 -> 192.168.0.101:5060SIP/2.0 200 OK.Via: SIP/2.0/UDP 192.168.0.101:5060.From: <sip:[email protected];user=phone>;tag=705048313.To: <sip:[email protected];user=phone>;tag=as6ce511fd.Call-ID: [email protected]: 2 INVITE.User-Agent: Asterisk PBX.Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.Contact: <sip:[email protected]>.Content-Type: application/sdp.Content-Length: 237..v=0.o=root 28925 28925 IN IP4 192.168.0.110.s=session.c=IN IP4 192.168.0.110.t=0 0.m=audio 5812 RTP/AVP 0 3 8 101.a=rtpmap:0 PCMU/8000.a=rtpmap:3 GSM/8000.a=rtpmap:8 PCMA/8000.a=rtpmap:101 telephone-event/8000.a=fmtp:101 0-16.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.101:5060 -> 192.168.0.110:5060ACK sip:[email protected] SIP/2.0.Via: SIP/2.0/UDP 192.168.0.101:5060.From: <sip:[email protected];user=phone>;tag=705048313.To: <sip:[email protected];user=phone>;tag=as6ce511fd.Call-ID: [email protected]: 2 ACK.User-Agent: Cisco ATA 186 v3.1.0 atasip (040211A).Proxy-Authorization: Digest username="3004",realm="asterisk",nonce="1fdb7e7b",uri="sip:[email protected]",response="a1bb3a7501b0982650a93bffacca0568".Content-Length: 0.

.101:10002.110:5812

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

U 192.168.0.110:5060 -> 192.168.0.105:5060NOTIFY sip:[email protected] SIP/2.0.Via: SIP/2.0/UDP 192.168.0.110:5060;branch=z9hG4bK361f812f.From: "asterisk" <sip:[email protected]>;tag=as39e043e0.To: <sip:[email protected]>.Contact: <sip:[email protected]>.Call-ID: [email protected]: 102 NOTIFY.User-Agent: Asterisk PBX.Event: message-summary.Content-Type: application/simple-message-summary.Content-Length: 37..Messages-Waiting: yesVoicemail: 2/0#U 192.168.0.105:50268 -> 192.168.0.110:5060SIP/2.0 200 OK.Via: SIP/2.0/UDP 192.168.0.110:5060;branch=z9hG4bK361f812f.From: "asterisk" <sip:[email protected]>;tag=as39e043e0.To: <sip:[email protected]>.Call-ID: [email protected]: Sun, 14 Nov 2004 19:20:04 GMT.CSeq: 102 NOTIFY.Content-Length: 0.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

192.168.0.101ext 3004

192.168.0.110Asterisk

192.168.0.105ext 3002

INVITE

TRYING

INVITE

BUSY

ACK

OK

ACK

NOTIFY

OK

BYE

OK

RTP (although, you can't see this from

the SIP debug)

So, you can’t tell but Asterisk server is sending this call to voicemail. Media goes to the asterisk server

And now the asterisk server sends ext 105 a MWI notification.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

SIP: How to Authenticate the sender of a SIP message?

• Digest Authentication – from the 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="47a23e53632ff1c28b41f12591b970586d6da3dc“

• Second try uses a hash of the nonce, the passwd, realm, & other fields to form a response which validates the identity of the sender– Authorization: Digest username="6173249175",

realm="mit.edu",nonce="47a23e53632ff1c28b41f12591b970586d6da3dc",response="fbab4f8c828ca550da0956d648d8d09a",uri="sip:mit.edu"

Invite

407 Proxy Auth Req, with nonce

ACK

Invite with response

ok

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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.”

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Generating the digest response• HA1 = MD5{username +”:”+realm+”:”+password}

– Username = 6173249175, 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 challenger– Other stuff – not so important

• MD5 = “one-way” hash, designed to be too hard (for everyone except the folks with giant super computers?) to guess the output based upon the input.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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.

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Summary

username="6173249175“realm="mit.edu"nonce="47a23e53632ff1c28b41f12591b970586d6da3dc"uri="sip:mit.edu" sip passwd = response="fbab4f8c828ca550da0956d648d8d09a“

Response = hard function (BLUE, RED)

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

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

6172531234

6172531234

6172531234

Important Person’s Phone (e.g., like Mr. Burns.) Has 3 CALL

APPEARANCES of his telephone number.

6172534567

6172534567

6172534567

Not Important Person’s Phone (e.g., like Smithers.)

Has 3 CALL APPEARANCES of his. own telephone number, and two of Mr. Burn’s

number. 6172531234

6172531234

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

SUBSCRIBE & NOTIFY: When Mr. Burn’s picks up the phone

6172531234

6172531234

6172531234

Important Person’s Phone (e.g., like Mr. Burns.) Has 3 CALL

APPEARANCES of his telephone number.

6172534567

6172534567

6172534567

Not Important Person’s Phone (e.g., like Smithers.)

Has 3 CALL APPEARANCES of his. own telephone number, and two of Mr. Burn’s

number. 6172531234

6172531234

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 line6172531234

Copyright 2005 – 2008 © by Elliot Eichen. All rights reserved.

Subscribe/Notify Call Flows