Scalable voip mobility intedration and deployment- P3 potx

The top and bottom half of the diagram are of the same equipment, but are Phone User Agent User Agent Phone User Agent Proxy Phone 2 Trying Phone User Agent Proxy 6 OK 7 ACK 9 ACK 8 OK F

Trang 1

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

Trang 2

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 Agent

Phone

User Agent

Proxy

Phone

2) Trying

Phone

User Agent

Proxy

6) OK

7) ACK 9) ACK

8) OK

Figure 2.3: SIP Call Setup

Trang 3

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

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

Trang 4

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

To: 〈sip:7020@corp.com〉

Call-ID: 2114455679@192.168.0.10

CSeq: 20 INVITE

User-Agent: My PBX

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

Trang 5

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

Supported: replaces

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

Trang 6

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

To: 〈sip:7020@172.27.0.20〉;tag=807333543

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

To: 〈sip:7020@corp.com〉;tag=as500634a6

Call-ID: 2114455679@192.168.0.10

CSeq: 20 INVITE

User-Agent: My PBX

Supported: replaces

Contact: 〈sip:7020@10.0.0.10〉

Content-Length: 0

Trang 7

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

To: 〈sip:7020@192.168.0.20〉;tag=807333543

Supported: replaces

CSeq: 102 INVITE

Contact: 〈sip:7020@192.168.0.20〉

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=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

To: 〈sip:7020@192.168.0.20〉;tag=807333543

Contact: 〈sip:7010@10.0.0.10〉

CSeq: 102 ACK

User-Agent: My PBX

Max-Forwards: 70

Content-Length: 0

Trang 8

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

Call-ID: 2114455679@192.168.0.10

CSeq: 20 INVITE

User-Agent: My PBX

Supported: replaces

Contact: 〈sip:7020@10.0.0.10〉

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: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

Call-ID: 2114455679@192.168.0.10

CSeq: 20 ACK

Max-Forwards: 70

Content-Length: 0

Trang 9

User Agent

Phone

User Agent

Proxy

Phone

2) Trying

Phone

User Agent

Proxy

6) Busy Here

7) ACK 9) 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

Trang 10

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

To: 〈sip:7020@192.168.0.20〉;tag=807333543

CSeq: 102 INVITE

Content-Length: 0

Table 2.13: SIP Busy Everywhere Rejection from Proxy to Caller

SIP/2.0 600 Busy Everywhere

Call-ID: 2114455679@192.168.0.10

CSeq: 20 INVITE

User-Agent: My PBX

Supported: replaces

Content-Length: 0

Định dạng
Số trang	10
Dung lượng	280,87 KB