18 Chapter 2 www.newnespress.com when the extension is not known by the registrar. That would happen when the phone really does not belong to this particular telephone network. The Via, From, and To fields serve the same purpose as before. Note that the To field now has a tag. The From field is still from the original caller, even though this is a response, and the To field is still from the called party. The Via line, and the indented one following it, are all one line in the packet: the description will use ⇒ to mark that the following line continues the current one. The CSeq field has not changed, as this is still the REGISTER request/response pair. The User-Agent is the vendor name of the registrar. In this case, it is “My PBX.” Because you cannot go out and purchase “My PBX,” you may have to settle for someone else’s. The Allow header states what types of actions a caller can request from the registrar. We will look at the more important ones—INVITE and BYE—shortly. The Expires header states that the registrar agreed with the client, and is going to let the registration live for 3600 seconds. The registrar can shorten this amount, if it so chooses and the client will lose its registration if it does not come in before then. You will notice that the Expires information repeats as a separate field in the Contact header. There are, unfortunately, still multiple ways of encoding exactly the same information in SIP, and there will be a lot of redundancy. The problem, of course, with redundancy, is that no one really knows how a complex system will work if the redundant information actually changes. Finally, the date of the response came in. Now, the registrar knows the phone exists, and the phone can make and receive calls. One good thing about registration is that the phone Table 2.2: SIP REGISTER response SIP/2.0 200 OK Via: SIP/2.0/UDP ⇒ 192.68.0.10:5060;branch=z9hG4bK1072017640;received=192.168.0.10 From: “7010”〈sip:7010@corp.com〉;tag=915317945 To: “7010”〈sip:7010@corp.com〉;tag=as7374d984 Call-ID: 1422523958@192.168.0.10 CSeq: 1 REGISTER User-Agent: My PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Expires: 3600 Contact: 〈sip:7010@192.168.0.10〉;expires=3600 Date: Tue, 27 Jan 2008 00:25:14 GMT Content-Length: 0 Voice Mobility Technologies 19 www.newnespress.com number and IP address bindings can be looked up in the PBX by the administrator. SIP- aware intervening networks, such as some Wi-Fi systems, also track this state and show which phones are wireless and where they are. 2.2.1.3 Placing a SIP Call Our user, 7010, wants to place a call to his already registered coworker, 7020. In SIP, this process belongs to a request-response series kicked off by an INVITE. The idea behind the invite is that the caller invites the called party into the call. Phone calls always start off with the user dialing the called party. Once that is done, the call should ring until the called party answers, or until the system forwards the call to voicemail or delivers a busy signal. Because there are phases of the call setup process—ringing, then a forward to voicemail—we will see how SIP deals with multiple responses for the same request. Figure 2.3 shows the messages that are exchanged in setting up the call, in order from 1 to 9. The top and bottom half of the diagram are of the same equipment, but are Phone User Agen t User Agen t Phone User Agent Proxy Phone 1) INVITE 3) INVITE 2) Trying Phone User Agent Proxy 5) Ringing 4) Ringing 6) OK 7) ACK9) ACK 8) OK Figure 2.3: SIP Call Setup 20 Chapter 2 www.newnespress.com separated to make the arrows clearer. Each arrow represents a message being sent from one part to the other. The black lines are for messages that represent the main setup messages, representing the call being placed or answered. The dashed lines are for messages that inform the caller of the progress. The dotted lines represent messages that are necessary for the protocol to work, if a message gets lost, but do not carry meaningful information about the call itself. Table 2.3 shows the outgoing request for a phone call. This is delivered to the proxy, as the calling phone has no idea where the called party is. The proxy will ask the registrar for details, and will then forward the message appropriately. Table 2.3: SIP INVITE Request from Caller to Proxy INVITE sip:7020@corp.com SIP/2.0 Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK922648023 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉 Supported: replaces,100rel,timer Call-ID: 2114455679@192.168.0.10 CSeq: 20 INVITE Session-Expires: 1800 Contact: 〈sip:7010@192.168.0.10〉 Max-Forwards: 70 Expires: 180 Content-Type: application/sdp Content-Length: 217 v=0 o=7010 1352822030 1434897705 IN IP4 192.168.0.10 s=A_conversation c=IN IP4 192.168.0.10 t=0 0 m=audio 9000 RTP/AVP 0 8 18 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:18 G729/8000/1 a=ptime:20 So Table 2.3 shows a substantially more involved message than we saw with registration. Let’s walk through it. The first line states that this is an “INVITE”, asking for URI “sip:7020@corp.com”, or the phone number 7020. So now we know who the call is for. Voice Mobility Technologies 21 www.newnespress.com The To field repeats that the message is really destined for URI “sip:7020@corp.com”. The CSeq field is “20 INVITE”. This INVITE started at 20. There may be multiple INVITEs coming for this call, depending on what happens as the call progresses. So 20 is a starting point. The Session-Expires header means that the entire session to start a phone call, including future changes, shouldn’t live for more than 1800 seconds, or a half-hour. This has no influence on the endpoints, but the proxy may be tracking the call, and this expiration lets the proxy know when the call can be flushed from the system, if, for some reason, one side or another disconnects from the network without informing the proxy. The Expires header, on the other hand, states how long the calling phone is willing to wait until it gets a yes-or-no answer from the other party. After 180 seconds, or three minutes, the caller will give up and cancel the invitation. The Content-Type field states that there is a body to this message, and it is in the Session Description Protocol (SDP) format. As mentioned earlier, SIP has no understanding of voice traffic itself. It is charged only with setting up calls. The SDP, on the other hand, describes how to set up the voice traffic. We’ll talk more about SDP in the section on bearer protocols, but for now, it’s enough to note that the rest of the packet is for the client asking for an Real-time Transport Protocol (RTP) session with voice. Table 2.4: SIP INVITE Trying Responses from Proxy to Caller SIP/2.0 100 Trying Via: SIP/2.0/UDP ⇒ 192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉 Call-ID: 2114455679@192.168.0.10 CSeq: 20 INVITE User-Agent: My PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: 〈sip:7010@192.168.0.10〉 Content-Length: 0 Table 2.4 describes the response from the proxy back to the caller. The code is “100 Trying”, meaning that the proxy has more work to do, and a better result will be provided shortly. In the meantime, the calling phone may show some state reflecting that the call is being attempted, but no ringing should be heard by the caller. The proxy will also proceed to forward the INVITE request to the called party. 22 Chapter 2 www.newnespress.com Table 2.5 shows the INVITE as the proxy has forwarded it. This message, from the proxy to the called party, 7020, looks similar to the original INVITE. There is one major difference, however, besides the Via header. The PBX in use is configured to direct the bearer channel through itself, where it will bridge the two legs of the call, one leg from each phone to the PBX. Therefore, it has substituted its own session description, in SDP, requesting the voice connection to come back to its own IP address. Also note that the CSeq for this invite is 102, not 20. The proxy maintains its own sequence. Finally, note that the URI for the To header has now changed to have the part after the @ sign refer to the phone’s IP. The called party’s phone responds to the proxy with the next message, in Table 2.6. The called party’s phone will also start to ring. This may not happen if the phone is busy or not available. But, in this case, the phone is available, and is ringing. Table 2.5: SIP INVITE Request from Proxy to Called Party INVITE sip:7020@192.168.0.20 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport From: “7010”〈sip:7010@corp.com〉;tag=as13a69dc0 To: 〈sip:7020@192.168.0.20〉 Contact: 〈sip:7010@10.0.0.10〉 Call-ID: 524f6a41059ad64d43dd4cce4b001b69@10.0.0.10 CSeq: 102 INVITE User-Agent: My PBX Max-Forwards: 70 Date: Tue, 27 Jan 2008 00:25:28 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 281 v=0 o=root 10871 10871 IN IP4 10.0.0.10 s=session c=IN IP4 10.0.0.10 t=0 0 m=audio 11690 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 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Voice Mobility Technologies 23 www.newnespress.com Table 2.7 shows the ringing message sent from the proxy, back to the caller. The caller receives this message, and starts playing a ringback tone for the caller to listen to, as the other party decides whether to answer. Some amount of time passes, and then the called party answers. Table 2.8 shows the “200 OK” message, reflecting that the call has been answered. In the OK message, we can see that the called party states where it wants its leg of the call to arrive to, and how it would like to set up the bearer channel. The proxy will receive this message and patch together the second leg of the call from it to the called party. To do so, the proxy, which has inserted itself between the two endpoints of the call, needs to send an acknowledgment (ACK), as shown in Table 2.9. This is needed because UDP is a lossy protocol, and there is a possibility that one of the messages didn’t get through. If the original INVITE did not get through, the sender will continue to send duplicate INVITEs, every second or so, until the other side gets it. Now, with the OK having been sent, the called party needs to know that the caller knows and is in the call. Table 2.6: SIP Ringing Response from Called Party to Proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060 From: “7010”〈sip:7010@corp.com〉;tag=as13a69dc0 To: 〈sip:7020@172.27.0.20〉;tag=807333543 Call-ID: 524f6a41059ad64d43dd4cce4b001b69@10.0.0.10 CSeq: 102 INVITE Contact: 〈sip:7020@192.168.0.20〉 Content-Length: 0 Table 2.7: SIP Ringing Response from Proxy to Caller SIP/2.0 180 Ringing SIP/2.0 Via: SIP/2.0/UDP ⇒ 192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉;tag=as500634a6 Call-ID: 2114455679@192.168.0.10 CSeq: 20 INVITE User-Agent: My PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: 〈sip:7020@10.0.0.10〉 Content-Length: 0 24 Chapter 2 www.newnespress.com The proxy also needs to send the OK through to the caller. Table 2.10 shows the message the caller gets. This lets the caller stop playing the ringback tone, and connecting the phone call from itself to the PBX. Now, both callers can hear each other. There is nothing to be done after the ACK, as it marks the end of the call setup protocol. We can now ask how the proxy participated. The messages you have seen look as if they could have gone directly from party to party. And this is true. However, the SIP proxy and registrar work together to provide a way for clients to find out about other clients, and have Table 2.8: SIP OK Response from Called Party to Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060 From: “7010”〈sip:7010@corp.com〉;tag=as13a69dc0 To: 〈sip:7020@192.168.0.20〉;tag=807333543 Supported: replaces Call-ID: 524f6a41059ad64d43dd4cce4b001b69@10.0.0.10 CSeq: 102 INVITE Contact: 〈sip:7020@192.168.0.20〉 Content-Type: application/sdp Content-Length: 160 v=0 o=9002 1367913267 845466921 IN IP4 192.168.0.20 s=A_conversation c=IN IP4 192.168.0.20 t=0 0 m=audio 9000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 Table 2.9: SIP ACK Request from Proxy to Called Party ACK sip:7020@192.168.0.20 SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK632b9079;rport From: “7010”〈sip:7010@corp.com〉;tag=as13a69dc0 To: 〈sip:7020@192.168.0.20〉;tag=807333543 Contact: 〈sip:7010@10.0.0.10〉 Call-ID: 524f6a41059ad64d43dd4cce4b001b69@10.0.0.10 CSeq: 102 ACK User-Agent: My PBX Max-Forwards: 70 Content-Length: 0 Voice Mobility Technologies 25 www.newnespress.com their calls routed to voicemail, the outside world, or to have any other advanced call feature performed. For this to work, the SIP proxy and registrar must work together to form a PBX. Clients are prevented from communicating directly. You may have noticed that at no point do the messages from the caller to the proxy have the IP addresses of the called party, and vice versa. The Contact and Via headers are always kept consistent, and all of the messages are forced to flow through the proxy. Not all proxies act this way, but most proxies with full PBX functionality do. Table 2.10: SIP OK Response from Proxy to Caller SIP/2.0 200 OK Via: SIP/2.0/UDP ⇒ 192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉;tag=as500634a6 Call-ID: 2114455679@192.168.0.10 CSeq: 20 INVITE User-Agent: My PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: 〈sip:7020@10.0.0.10〉 Content-Type: application/sdp Content-Length: 202 v=0 o=root 10871 10871 IN IP4 10.0.0.10 s=session c=IN IP4 10.0.0.10 t=0 0 m=audio 12482 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Table 2.11: SIP ACK Request from Caller to Proxy ACK sip:7020@corp.com SIP/2.0 Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK1189369993 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉;tag=as500634a6 Call-ID: 2114455679@192.168.0.10 CSeq: 20 ACK Max-Forwards: 70 Content-Length: 0 26 Chapter 2 www.newnespress.com Phone User Agent User Agent Phone User Agent Proxy Phone 1) INVITE 3) INVITE 2) Trying Phone User Agent Proxy 5) Ringing 4) Ringing 6) Busy Here 7) ACK9) ACK 8) Busy Everywhere Figure 2.4: SIP Call Rejection 2.2.1.4 A Rejected SIP Call Sometimes the called party does not want to answer the call. This happens when the phone call comes in and the user is busy. The process looks very similar to a successful SIP call, except that, instead of the called party sending a 200 OK message, it sends a different one. Figure 2.4 shows the call setup flow. The change is that the OK is now replaced with a “486 Busy Here” message, which means that the called party is busy at the endpoint they were called at. The proxy could have used this status to forward the call onto a voicemail system, by either sending a new INVITE to the voicemail system (if it has a separate user agent) and bridging those two legs together, or by sending a “302 Moved Temporarily” response to the client and expecting the client to try the voicemail. Table 2.12 shows the rejection that the called party will send if the user declines to take the call. The proxy will continue with its ACK, as before. Voice Mobility Technologies 27 www.newnespress.com Next, the proxy will send to the caller a busy message (Table 2.13), stating that the called party is busy at every user agent that it is aware of, which, for this example, is the one at 192.168.0.20. Because the proxy knows that the called party has no other alternatives, it changed the message code from “486 Busy Here” to “600 Busy Everywhere”. 2.2.1.5 Hanging Up Once the SIP call is going, there are no response codes that can hang the call up. Rather, the party who hangs up first sends a new request to the proxy, to disconnect the call. This type of message, called a BYE request, tells the receiver that the call is now over. Table 2.14 shows the BYE message, sent when the caller hangs up the phone call. The proxy server will respond to the BYE with a “200 OK” response, which is similar to the ones we have seen before, except without any SDP description of the bearer channel. Then, the proxy server will send a BYE to the called party, and wait for the OK from there. Unlike with the call setup, the OK message is enough to mark the end of the teardown. 2.2.1.6 SIP Response Codes The protocol has a number of response codes, some of which are more esoteric than others. We’ll go through the main ones, one by one, to get a better sense of what can happen. Table 2.12: SIP Busy Here Rejection from Called Party to Proxy SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060 From: “7010”〈sip:7010@corp.com〉;tag=as13a69dc0 To: 〈sip:7020@192.168.0.20〉;tag=807333543 Call-ID: 524f6a41059ad64d43dd4cce4b001b69@10.0.0.10 CSeq: 102 INVITE Content-Length: 0 Table 2.13: SIP Busy Everywhere Rejection from Proxy to Caller SIP/2.0 600 Busy Everywhere Via: SIP/2.0/UDP ⇒ 192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10 From: “7010”〈sip:7010@corp.com〉;tag=1687298419 To: 〈sip:7020@corp.com〉;tag=as500634a6 Call-ID: 2114455679@192.168.0.10 CSeq: 20 INVITE User-Agent: My PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 . directly from party to party. And this is true. However, the SIP proxy and registrar work together to provide a way for clients to find out about other clients, and have Table 2.8: SIP OK Response. caller to the proxy have the IP addresses of the called party, and vice versa. The Contact and Via headers are always kept consistent, and all of the messages are forced to flow through the proxy changes. Finally, the date of the response came in. Now, the registrar knows the phone exists, and the phone can make and receive calls. One good thing about registration is that the phone Table 2.2: SIP