Tech-invite. RFC 3261's SIP Examples. biloxi.com Registrar. Bob's SIP phone

Transcription

1 Tech-invite RFC 3261's SIP Examples V2.2 November 22, 2005 Registrar Bob's SIP INVITE 100 Trying Proxy INVITE 100 Trying Proxy 200 OK INVITE REGISTER This is a representation, as a slide show, of the SIP examples outlined in chapter 4 (overview of operation) and detailed in chapter 24 of RFC 3261 SIP: Session Initiation Protocol. SIP messages are reported in strict conformance with this RFC. 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK Media Session BYE 200 OK Copyright 2005 Joël Repiquet. All Rights Reserved. 17 pages

2 RFC 3261's Example Registration (a) Location Server The Request-URI names the domain of the location service for which the registration is meant The To header field contains the address of record whose registration is to be created registrar The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third-party registration. All registrations from a UA should use the same Call-ID header field value for registrations sent to a particular registrar. The CSeq value guarantees proper ordering of REGISTER requests. A UA must increment the CSeq value by one for each REGISTER request with the same Call-ID. F1 REGISTER sip:registrar. SIP/2.0 Via: SIP/2.0/UDP bobspc.:5060 ;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob <sip:bob@> From: Bob <sip:bob@> ;tag= Call-ID: @998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@ > Expires: 7200 The Contact header field with zero or more values containing address bindings. The Expires header field indicates how long the UA would like the binding to be valid. The value is a number indicating seconds.

3 RFC 3261's Example Registration (b) Location Server Store registrar F2 SIP/ OK Via: SIP/2.0/UDP bobspc.:5060 ;branch=z9hg4bknashds7 ;received= To: Bob ;tag=2493k59kd From: Bob ;tag= Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200

4 RFC 3261's Example Session Setup (1) The initial Request-URI of the message is set to the value of the URI in the To field. The Via header field indicates the transport (UDP) used for the transaction and identifies the location -- sent-by (pc33.) -- where the response is to be sent. The "branch" parameter is used to identify the transaction created by that request. It is mandatory and must always begin with the characters "z9hg4bk". The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It is decremented by one at each hop. F1 INVITE sip:bob@ SIP/2.0 Via: SIP/2.0/UDP pc33. Max-Forwards: 70 To: Bob <sip:bob@> From: Alice <sip:alice@> Contact: <sip:alice@pc33.> Content-Type: application/sdp Content-Length: 142 ( SDP not shown) The To header field specifies the desired "logical" recipient of the request, or the address-of-record (AOR) of the user or resource that is the target of this request. There is no "tag" parameter since the dialog is not established yet. The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. "Alice" is the (optional) display name. The "tag" parameter identifies this UA as a peer of the dialog. The Call-ID header field acts as a unique identifier and must be the same for all requests and responses sent by either UA in a dialog. The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method, matching that of the request. The Contact header field provides a SIP or SIPS URI that can be used by Bob's UA to contact UA for subsequent requests. The Content-Type header field indicates the media type of the message-body sent to the recipient. SDP (session description protocol ) is defined in RFC2327. user agent (UA) does not know the location of Bob's UA or his server in the domain. Therefore, the INVITE request is sent to the SIP server that serves domain (). The address of the SIP server could have been configured in, or it could have been discovered by DHCP, for example.

5 The "" server finds the SIP server that serves the "" domain by performing a particular type of DNS lookup. This procedure (selecting a transport protocol, determining port and IP address) is described in RFC3263 (SIP: Locating SIP Servers). RFC 3261's Example Session Setup (2) Before forwarding the INVITE request, the "" server adds an additional Via header field value that contains its own address -- sent-by (bigbox3.site3.) -- and the "branch" transaction value F2 SIP/ Trying Via: SIP/2.0/UDP pc33. To: Bob <sip:bob@> From: Alice <sip:alice@> F3 INVITE sip:bob@ SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c Via: SIP/2.0/UDP pc33. Max-Forwards: 69 To: Bob <sip:bob@> From: Alice <sip:alice@> Contact: <sip:alice@pc33.> Content-Type: application/sdp Content-Length: 142 ( SDP not shown) The "received" parameter is added to the Via header field built by UA (as for "100 Trying" message). Max-Forwards is decremented by one The remainder of the INVITE request received from UA is unchanged. The 100 (Trying) response contains the same To, From, Call-ID, CSeq header field values as the INVITE request. The "received" parameter is added to the Via header field by the "server transport" of, after examining the value of the sent-by parameter (pc33.). This sent-by parameter was inserted by the UA's "client transport" in the Via header field value, just before sending the INVITE request. The sent-by field contained an IP address or host name, and port. The "received" parameter contains the IP source address from which the packet was received.

6 RFC 3261's Example Session Setup (3) F4 Location Server SIP/ Trying Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. To: Bob From: Alice Before forwarding the INVITE request, the "" server adds an additional Via header field value that contains its own address The "received" parameter is added to the Via header field built by "" server Max-Forwards is decremented by one Response Query F5 The server consults the location server database, that contains the current IP address of Bob. INVITE SIP/2.0 Via: SIP/2.0/UDP server10. ;branch=z9hg4bk4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. Max-Forwards: 68 To: Bob From: Alice Contact: Content-Type: application/sdp Content-Length: 142 ( SDP not shown) The remainder of the INVITE request received from "" server is unchanged.

7 RFC 3261's Example Session Setup (4) The "received" parameter is added to the Via header field built by "" server The "tag" parameter, identifying this UA as a peer of the dialog, is added to the To header field. Although the dialog is not established yet, the 3 values that identify a dialog (Call-ID, local Tag, remote Tag) are already defined. The Contact header field provides a SIP or SIPS URI that can be used by UA to contact Bob's UA for subsequent requests. The other header field values (From, Call-ID, CSeq, and bottom Via's) are copied from the INVITE request. F6 SIP/ Ringing Via: SIP/2.0/UDP server10. ;branch=z9hg4bk4b43c2ff8.1 ;received= Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. To: Bob <sip:bob@> From: Alice <sip:alice@> Contact: <sip:bob@ > rings and indicates this in a 180 (Ringing) response, which is routed back in the reverse direction to (IP address and transport found in the top Via header field)

8 RFC 3261's Example Session Setup (5) F7 SIP/ Ringing Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. To: Bob From: Alice Contact: The top Via header field in the 180 (Ringing) message received from Bob's UA, is used by server for retrieving the relevant transaction, using the "branch" parameter. It is then removed and the information in the new top Via header field is used for forwarding the message towards the next hop in the reverse path:.

9 RFC 3261's Example Session Setup (6) F8 SIP/ Ringing Via: SIP/2.0/UDP pc33. To: Bob From: Alice Contact: The top Via header field in the 180 (Ringing) message received from, is used by server for retrieving the relevant transaction, using the "branch" parameter. It is then removed and the information in the new top Via header field is used for forwarding the message towards the next hop in the reverse path: UA. " passes the Ringing information to Alice, using an audio ringback tone or by displaying a message on screen.

10 RFC 3261's Example Session Setup (7) "" / "branch=z9hg4bk4b43c2ff8.1" transaction, between and Bob's UA, terminates with this 200 (OK) response F9 SIP/ OK Via: SIP/2.0/UDP server10. ;branch=z9hg4bk4b43c2ff8.1 ;received= Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. To: Bob <sip:bob@> From: Alice <sip:alice@> Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) " When Bob answers the call, his SIP sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice.

11 RFC 3261's Example Session Setup (8) "" / "branch=z9hg4bk77ef4c " transaction, between and, terminates with this 200 (OK) response F10 SIP/ OK Via: SIP/2.0/UDP bigbox3.site3. ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33. To: Bob <sip:bob@> From: Alice <sip:alice@> Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) "

12 RFC 3261's Example Session Setup (9) F11 SIP/ OK Via: SIP/2.0/UDP pc33. To: Bob From: Alice Contact: Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) "" / "branch=z9hg4bknashds8" transaction, between and UA, terminates with this 200 (OK) response stops the ringback tone and indicates that the call has been answered

13 RFC 3261's Example Session Setup (10) sends an ACK (message request) to to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from to Bob's SIP, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. F12 ACK SIP/2.0 Via: SIP/2.0/UDP pc33. ;branch=z9hg4bknashds9 Max-Forwards: 70 To: Bob From: Alice CSeq: ACK

14 RFC 3261's Example Session Setup (11) Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-toend media packets take a different path from the SIP signaling messages. One or a combination of the following media types can be used with SDP: "audio", "video", "application", "data", "control"... Media Session

15 RFC 3261's Example Session Setup (12) F13 BYE SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hg4bknashds10 Max-Forwards: 70 From: Bob To: Alice CSeq: 231 BYE At the end of the call, Bob disconnects (hangs up) first and his SIP generates a BYE (request) message. This BYE is routed directly to, again bypassing the proxies.

16 RFC 3261's Example Session Setup (13) Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. F14 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hg4bknashds10 From: Bob <sip:bob@> To: Alice <sip:alice@> CSeq: 231 BYE

17 RFC 3261's Example Session Setup (end)