In Figure 5-32, Laura calls Bob at his public address, but he isn’t there. A proxy server at company.com routes the call to his current location:
SIP:Bob@131.160.1.112.
This example comprises three different transactions: INVITE, ACK, and BYE.
INVITE from Laura’s UA to SIP Proxy Laura’s UA places Bob’s pub-lic address in the To field and in the Request-URI. It adds a Via header with its address and creates a message body with an SDP session description.
Laura wants to receive RTP packets containing PCM voice on UDP port 20002. The request is sent to the proxy at company.com because the domain part of the Request-URI is company.com.
INVITE sip:Bob.Johnson@company.com SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>
UA Proxy Proxy
(1) BYE
(9) BYE
(2) BYE (3) 100 Trying
(4) BYE
(7) BYE
(12 ) BYE (5) 100 Trying
(13) 200 OK
UDP TCP
(8) 200 OK
(10) 200 OK (11) BYE
(6) 200 OK Figure 5-31
Provisional responses do not stop request retransmissions.
(6) 200 OK (4) 180 Ringing
(1) INVITE
(2) INVITE
(5) 200 OK (3) 180 Ringing
Laura SIP proxy Bob
Conversation
(9) 200 OK (7) ACK
131.160.1.112 131.160.1.110
workstation1000.university.com
(8) BYE Figure 5-32
SIP call through a proxy
Call-ID: 12345678@workstation1000.university.com CSeq: 1 INVITE
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
Content-Type: application/sdp Content-Length: 154
v=0
o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com s=Let us talk for a while
c=IN IP4 138.85.27.10 t=0 0
m=audio 20002 RTP/AVP 0
INVITE from SIP Proxy to Bob The SIP proxy at company.com receives the INVITE request. The host part of the Request-URI reads Bob.Johnson. The proxy knows that Bob.Johnson may be reachable at SIP:Bob@131.160.1.112. Thus, it creates a new INVITE with Bob’s location as the Request-URI, adding its address to the request as a Via header:
131.160.1.110. Notice that the message body remains untouched. SIP servers do not typically modify message bodies.
INVITE sip:Bob@131.160.1.112 SIP/2.0 Via: SIP/2.0/UDP 131.160.1.110
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>
Call-ID: 12345678@workstation1000.university.com CSeq: 1 INVITE
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
Content-Type: application/sdp Content-Length: 154
v=0
o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com s=Let us talk for a while
c=IN IP4 138.85.27.10 t=0 0
m=audio 20002 RTP/AVP 0
Provisional Response from Bob to Proxy Upon receiving the INVITE, Bob’s UA must initiate alerting, so it returns a provisional response announcing that alerting has begun. The Via headers are copied from the INVITE received. They will ensure that the response traverses the proxy first, 131.160.1.110, and then arrives at Laura’s UA, worksta-tion1234.university.com at UDP port number 5060.
Bob’s UA adds a Contact header to the response containing the SIP URL where Bob can be reached directly; from now on, subsequent requests will be sent directly from Laura’s UA to Bob’s UA.
Bob’s UA also adds a tag parameter to the To header, naming the SIP UA that Bob is currently using. The tag info helps to differentiate the responses that Laura might get if a forking proxy in the path tried to reach Bob at sev-eral locations. To avoid confusing Laura’s UA, each of Bob’s UAs will have answered with a different tag.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 131.160.1.110
Via: SIP/2.0/UDP workstation1000.university.com:5060
From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 1 INVITE
Contact: Bob Johnson <sip:Bob@131.160.1.112>
Provisional Response from Proxy to Laura Upon receipt of this response, the proxy removes the Via header with its own address and sends the response to the address contained in the next Via header. This proxy takes no further action.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 1 INVITE
Contact: Bob Johnson <sip:Bob@131.160.1.112>
Final Response from Bob to Proxy When Bob accepts the call, his UA returns its SDP session description. It will receive RTP packets on UDP port 41000.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 131.160.1.110
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 1 INVITE
Contact: Bob Johnson <sip:Bob@131.160.1.112>
Content-Type: application/sdp Content-Length: 154
v=0
o=Bob 2891234321 2891234321 IN IP4 131.160.1.112 s=Let us talk for a while
c=IN IP4 131.160.1.112 t=0 0
m=audio 41000 RTP/AVP 0
Final Response from Proxy to Laura The proxy server routes the final response in the same way it routed the previous provisional response.
In other words, it removes the first Via header and sends the response to the address contained in the next Via.
SIP/2.0 200 OK
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 1 INVITE
Contact: Bob Johnson <sip:Bob@131.160.1.112>
Content-Type: application/sdp Content-Length: 154
v=0
o=Bob 2891234321 2891234321 IN IP4 131.160.1.112 s=Let us talk for a while
c=IN IP4 131.160.1.112 t=0 0
m=audio 41000 RTP/AVP 0
ACK from Laura to Bob When Laura’s UA receives the 200 OK final response, it sends an ACK request. This ACK is sent directly to Bob’s UA, whose address is contained in the Contact header just received.
ACK sip:Bob@131.160.1.112 SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159
Call-ID: 12345678@workstation1000.university.com CSeq: 1 ACK
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
BYE from Laura to Bob Now Laura is ready to finish the call so her UA sends a BYE request. This BYE request is also sent directly to Bob’s UA using the Contact header previously received. Note that the Cseq has been increased. This BYE request belongs to a new transaction.
BYE sip:Bob@131.160.1.112 SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 2 BYE
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
Final Response from Bob to Laura Bob’s UA receives the BYE request, terminates the audio session, and returns a 200 OK response for the BYE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com
CSeq: 2 BYE
Contact: Bob Johnson <sip:Bob@131.160.1.112>
The example above shows how all the headers that were explained previously in this chapter work together to establish a voice session. We can already see that SIP protocol opertion is pretty simple and easy to understand.