Differences

This shows you the differences between two versions of the page.

Link to this comparison view

en:ressources:dossiers:voip:sip_rtp [2011/03/16 00:30] (current)
Line 1: Line 1:
 +====== SIP and RTP : overview of a VoIP communication ======
  
 +{{tag>​voip sip rtp rfc}}
 +
 +
 +This page describes in detail the protocols used in a typical SIP/RTP communication with or without the use of TLS. First, I'm going to describe how a simple VoIP communication works with OpenSER acting as a Proxy/​Registrar and two X-Lite clients. ​
 +
 +We are working on a very simple network:
 +  - An OpenSER PBX -> 192.168.0.30
 +  - Two X-Lite clients -> 10.42.16.48 and 10.42.16.88
 +
 +The reason why all hosts are not in the same IP range is that we are using a VPN between our two networks to avoid NAT problems… We will discuss this later.
 +
 +===== Registering =====
 +
 +
 +<​note>​From RFC3261: SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls.</​note> ​
 +
 +The first thing that a user of a SIP Network does is registering himself with the SIP Registrar. In our example, we use an OpenSER server that acts as the SIP Registrar (and also the SIP Proxy, but for now it doesn'​t matter). So, Julien, the user who has the IP 10.42.16.48,​ launches his softphone and tries to register himself only by sending a REGISTER datagram such as this one:
 +
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​  Info
 +74      15.788470 ​  ​10.42.16.48 ​          ​192.168.0.30 ​          ​SIP ​       Request: REGISTER sip:​192.168.0.30
 +
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 5061 (5061), Dst Port: 5060 (5060)
 +    Source port: 5061 (5061)
 +    Destination port: 5060 (5060)
 +    Length: 434
 +    Checksum: 0xc0db [correct]
 +Session Initiation Protocol
 +    Request-Line:​ REGISTER sip:​192.168.0.30 SIP/2.0
 +        Method: REGISTER
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 10.42.16.48:​5061;​rport;​branch=z9hG4bK240C2422F5DFEF700B859D9BAD8F9063
 +        From: julien <​sip:​julien@intra-calcman.org>;​tag=1847976374
 +            SIP Display info: julien ​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: 1847976374
 +        To: julien <​sip:​julien@intra-calcman.org>​
 +            SIP Display info: julien ​
 +            SIP to address: sip:​julien@intra-calcman.org
 +        Contact: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +            Contact Binding: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +                URI: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +                    SIP Display info: "​julien"​
 +                    SIP contact address: sip:​julien@10.42.16.48:​5061
 +        Call-ID: 16E70BC816CCE9FF71C7F405E6C4B56F@192.168.0.30
 +        CSeq: 8933 REGISTER
 +        Expires: 1800
 +        Max-Forwards:​ 70
 +        User-Agent: X-Lite release 1105d
 +        Content-Length:​ 0
 +</​file>​
 +
 +
 +The message is very simple. The SIP data structure is sent in plain text and contains human readable information such as the local IP address, the Registrar IP address, several information and a CALL-ID. This last one is very important because UDP protocols do not maintain a network session. So, the Call-ID is used to refer to a session and will change when a new session is launched (a new registrar message, an invite message and so on...).
 +
 +The Registrar return a "100 Trying"​ message while processing the request. This message contains the same Call-ID. ​
 +
 +But here is the interesting thing: after a very short time, the Registrar returns the following message to julien: ​
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +79      15.865100 ​  ​192.168.0.30 ​          ​10.42.16.48 ​          ​SIP ​        ​Status:​ 401 Unauthorized ​   (1 bindings)
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5061 (5061)
 +    Source port: 5060 (5060)
 +    Destination port: 5061 (5061)
 +    Length: 536
 +    Checksum: 0xcbdf [correct]
 +Session Initiation Protocol
 +    Status-Line:​ SIP/2.0 401 Unauthorized
 +        Status-Code:​ 401
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 10.42.16.48:​5061;​rport;​branch=z9hG4bK240C2422F5DFEF700B859D9BAD8F9063;​received=10.42.16.48
 +        From: julien <​sip:​julien@intra-calcman.org>;​tag=1847976374
 +            SIP Display info: julien ​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: 1847976374
 +        To: julien <​sip:​julien@intra-calcman.org>;​tag=as4c996f20
 +            SIP Display info: julien ​
 +            SIP to address: sip:​julien@intra-calcman.org
 +            SIP tag: as4c996f20
 +        Call-ID: 16E70BC816CCE9FF71C7F405E6C4B56F@192.168.0.30
 +        CSeq: 8933 REGISTER
 +        User-Agent: OpenSER PBX
 +        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
 +        Contact: <​sip:​julien@intra-calcman.org>​
 +            Contact Binding: <​sip:​julien@intra-calcman.org>​
 +                URI: <​sip:​julien@intra-calcman.org>​
 +                    SIP contact address: sip:​julien@intra-calcman.org
 +        WWW-Authenticate:​ Digest realm="​intra-calcman.org",​ nonce="​3f314b07"​
 +            Authentication Scheme: Digest
 +            Realm: "​intra-calcman.org"​
 +            Nonce Value: "​3f314b07"​
 +        Content-Length:​ 0
 +</​file>​
 +
 +Why is the registrar sending an Unauthorized message ? This could be quite disconcerting… but, in fact, this is the regular way to register!!! ​
 +As defined in the RFC :
 +
 +<​note>​When a |Registrar| receives a request from a |Client|, the |Registrar| MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the |Registrar| can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code.
 +
 +The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm.</​note> ​
 +
 +So, the client has to re-send a Register request but, this time, it has to include an authorization method. Let's see the next message:
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +81      15.869887 ​  ​10.42.16.48 ​          ​192.168.0.30 ​          ​SIP ​        ​Request:​ REGISTER sip:​192.168.0.30
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 5061 (5061), Dst Port: 5060 (5060)
 +    Source port: 5061 (5061)
 +    Destination port: 5060 (5060)
 +    Length: 575
 +    Checksum: 0xab44 [correct]
 +Session Initiation Protocol
 +    Request-Line:​ REGISTER sip:​192.168.0.30 SIP/2.0
 +        Method: REGISTER
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 10.42.16.48:​5061;​rport;​branch=z9hG4bK4FD30F8A1D5F0DE817436029ACE18888
 +        From: julien <​sip:​julien@intra-calcman.org>;​tag=1847976374
 +            SIP Display info: julien ​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: 1847976374
 +        To: julien <​sip:​julien@intra-calcman.org>​
 +            SIP Display info: julien ​
 +            SIP to address: sip:​julien@intra-calcman.org
 +        Contact: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +            Contact Binding: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +                URI: "​julien"​ <​sip:​julien@10.42.16.48:​5061>​
 +                    SIP Display info: "​julien"​
 +                    SIP contact address: sip:​julien@10.42.16.48:​5061
 +        Call-ID: 16E70BC816CCE9FF71C7F405E6C4B56F@192.168.0.30
 +        CSeq: 8934 REGISTER
 +        Expires: 1800
 +        Authorization:​ Digest username="​julien",​realm="​intra-calcman.org",​nonce="​3f314b07",​response="​3ef916fd68651deaf5dd74b4473aa641",​uri="​sip:​192.168.0.30"​
 +            Authentication Scheme: Digest
 +            Username: "​julien"​
 +            Realm: "​intra-calcman.org"​
 +            Nonce Value: "​3f314b07"​
 +            Digest Authentication Response: "​3ef916fd68651deaf5dd74b4473aa641"​
 +            Authentication URI: "​sip:​192.168.0.30"​
 +        Max-Forwards:​ 70
 +        User-Agent: X-Lite release 1105d
 +        Content-Length:​ 0
 +</​file>​
 +
 +As expected, this Register request contains an authorization field. Because this is not a new Registrar session, the Call-ID is still the same and as defined in the RFC, this authorization response includes the realm and the nonce provided by the Registrar.
 +
 +The nonce is a temporary random number used to avoid replay attacks.
 +
 +The generation of the "​Digest Authentication Response"​ field is defined in RFC 3617. It uses the realm, the nonce, the URI, the username and the password to generate a md5 sum.
 +
 +The Registrar sends a "100 Trying"​ message while processing the request and after some milliseconds,​ it sends an Options request:
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +84      15.960925 ​  ​192.168.0.30 ​          ​10.42.16.48 ​          ​SIP ​        ​Request:​ OPTIONS sip:​julien@10.42.16.48:​5061
 +</​file>​
 +
 +The Registrer has not yet accepted the registration. This allows the Registrar to query the client about what functionalities it supports. What is interesting is that this message uses a new Call-ID: ​
 +
 +**Call-ID: 0b51f8be3c5396be74caa22c52f26340@192.168.0.30**
 +
 +Almost at the same time, the Registrar sends the "200 OK" message which validates the registration. ​
 +
 +So, the client is logged in now. In response to the Options request, it sends the "200 OK" message which lists the SIP methods it supports. (The code could be 486 if the client was here but not ready to accept a call).
 +
 +
 +===== Calling =====
 +
 +
 +OK, Now our client is registered and he can call his friends. To explain this part, let me welcome david@intra-calcman.org.
 +Julien is going to call david. To do this, he sends an INVITE request to the proxy (which is also the registrar in our case, but can be a different one). The following datagram is the INVITE request: ​
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +95      30.398482 ​  ​10.42.16.48 ​          ​192.168.0.30 ​          ​SIP/​SDP ​    ​Request:​ INVITE sip:​david@intra-calcman.org,​ with session description
 +
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 38276 (38276)
 +    Source port: 5060 (5060)
 +    Destination port: 38276 (38276)
 +    Length: 831
 +    Checksum: 0x25eb [correct]
 +Session Initiation Protocol
 +    Request-Line:​ INVITE sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3 SIP/2.0
 +        Method: INVITE
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 192.168.0.30:​5060;​branch=z9hG4bK01a93c8b;​rport
 +        From: "​julien"​ <​sip:​julien@intra-calcman.org>;​tag=as1ea41f9e
 +            SIP Display info: "​julien" ​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: as1ea41f9e
 +        To: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +            SIP to address: sip:​david@intra-calcman.org:​38276
 +        Contact: <​sip:​julien@intra-calcman.org>​
 +            Contact Binding: <​sip:​julien@intra-calcman.org>​
 +                URI: <​sip:​julien@intra-calcman.org>​
 +                    SIP contact address: sip:​julien@intra-calcman.org
 +        Call-ID: 48f934056782cf6f581c024128f6c29c@192.168.0.30
 +        CSeq: 102 INVITE
 +        User-Agent: OpenSER PBX
 +        Max-Forwards:​ 70
 +        Date: Mon, 02 Oct 2006 14:26:13 GMT
 +        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
 +        Content-Type:​ application/​sdp
 +        Content-Length:​ 259
 +    Message body
 +        Session Description Protocol
 +            Session Description Protocol Version (v): 0
 +            Owner/​Creator,​ Session Id (o): root 3725 3725 IN IP4 192.168.0.30
 +                Owner Username: root
 +                Session ID: 3725
 +                Session Version: 3725
 +                Owner Network Type: IN
 +                Owner Address Type: IP4
 +                Owner Address: 192.168.0.30
 +            Session Name (s): session
 +            Connection Information (c): IN IP4 10.42.16.88
 +                Connection Network Type: IN
 +                Connection Address Type: IP4
 +                Connection Address: 10.42.16.88
 +            Time Description,​ active time (t): 0 0
 +                Session Start Time: 0
 +                Session Stop Time: 0
 +            Media Description,​ name and address (m): audio 14318 RTP/AVP 0 3 8 101
 +                Media Type: audio
 +                Media Port: 14318
 +                Media Proto: RTP/AVP
 +                Media Format: ITU-T G.711 PCMU
 +                Media Format: GSM 06.10
 +                Media Format: ITU-T G.711 PCMA
 +                Media Format: 101
 +            Media Attribute (a): rtpmap:0 PCMU/8000
 +                Media Attribute Fieldname: rtpmap
 +                Media Format: 0
 +                MIME Type: PCMU
 +                MIME type: PCMU
 +            Media Attribute (a): rtpmap:3 GSM/8000
 +                Media Attribute Fieldname: rtpmap
 +                Media Format: 3
 +                MIME Type: GSM
 +                MIME type: GSM
 +            Media Attribute (a): rtpmap:8 PCMA/8000
 +                Media Attribute Fieldname: rtpmap
 +                Media Format: 8
 +                MIME Type: PCMA
 +                MIME type: PCMA
 +            Media Attribute (a): rtpmap:101 telephone-event/​8000
 +                Media Attribute Fieldname: rtpmap
 +                Media Format: 101
 +                MIME Type: telephone-event
 +                MIME type: telephone-event
 +            Media Attribute (a): fmtp:101 0-16
 +                Media Attribute Fieldname: fmtp
 +                Media Format: 101 [telephone-event]
 +                Media format specific parameters: 0-16
 +            Media Attribute (a): silenceSupp:​off - - - -
 +                Media Attribute Fieldname: silenceSupp
 +                Media Attribute Value: off - - - -
 +
 +</​file>​
 +
 +
 +Once again, reading a SIP message is very simple (this is one of the aims of the protocol). We can see david'​s address and port: 
 +
 +**INVITE sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3 SIP/2.0**
 +
 +and many others useful information such as the Via parameter, including the "​branch"​ transaction identifier. The via parameter is needed to identify where the response is to be sent. 
 +
 +**Via: SIP/2.0/UDP 192.168.0.30:​5060;​branch=z9hG4bK01a93c8b;​rport**
 +
 +We haven'​t already talked about the SDP protocol. Session Description Protocol is the purpose of the RFC 4566 (july 2006).
 +
 +From the RFC:
 +<​note>​When initiating multimedia teleconferences,​ voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information,​ irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport protocol, and it is intended to use different transport protocols as appropriate,​ including the Session Announcement Protocol, Session Initiation Protocol, Real Time Streaming Protocol, electronic mail using the MIME extensions, and the Hypertext Transport Protocol.
 +
 +SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negociation of session content or media encodings: this is viewed as outside the scope of session description.</​note>​
 +
 +For our purpose, we only need to know that SDP syntax is used to define call parameters. In the previous datagram, we see that RTP will be used between david and julien. While OpenSER delivers the datagram to david, a "100 Trying"​ message is sent to julien.
 +
 +So, what happens on david'​s side after he has received this datagram? ​
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +33      172.296544 ​ 10.42.16.88 ​          ​192.168.0.30 ​          ​SIP ​        ​Status:​ 180 Ringing
 +His softphone (we are using x-lite) sent a "180 Ringing"​ message, which is exactly what it means… The Ringing response contains all the SIP informations to identify the call: 
 +User Datagram Protocol, Src Port: 38276 (38276), Dst Port: 5060 (5060)
 +    Source port: 38276 (38276)
 +    Destination port: 5060 (5060)
 +    Length: 435
 +    Checksum: 0xb210 [correct]
 +Session Initiation Protocol
 +    Status-Line:​ SIP/2.0 180 Ringing
 +        Status-Code:​ 180
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 192.168.0.30:​5060;​branch=z9hG4bK01a93c8b;​rport=5060
 +        Contact: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +            Contact Binding: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +                URI: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +                    SIP contact address: sip:​david@intra-calcman.org:​38276
 +        To: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>;​tag=79182b50
 +            SIP to address: sip:​david@intra-calcman.org:​38276
 +            SIP tag: 79182b50
 +        From: "​julien"<​sip:​julien@intra-calcman.org>;​tag=as1ea41f9e
 +            SIP Display info: "​julien"​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: as1ea41f9e
 +        Call-ID: 48f934056782cf6f581c024128f6c29c@192.168.0.30
 +        CSeq: 102 INVITE
 +        User-Agent: X-Lite release 1003l stamp 30942
 +        Content-Length:​ 0
 +
 +</​file>​
 +
 +
 +OpenSER, the proxy, receives this response and sends a "180 Ringing"​ message to julien.
 +
 +To establish the call, david sends a "200 OK" datagram: ​
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +37      175.961865 ​ 10.42.16.88 ​          ​192.168.0.30 ​          ​SIP/​SDP ​    ​Status:​ 200 OK, with session description
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 38276 (38276), Dst Port: 5060 (5060)
 +    Source port: 38276 (38276)
 +    Destination port: 5060 (5060)
 +    Length: 785
 +    Checksum: 0xb573 [correct]
 +Session Initiation Protocol
 +    Status-Line:​ SIP/2.0 200 OK
 +        Status-Code:​ 200
 +        [Resent Packet: False]
 +    Message Header
 +        Via: SIP/2.0/UDP 192.168.0.30:​5060;​branch=z9hG4bK01a93c8b;​rport=5060
 +        Contact: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +            Contact Binding: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +                URI: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>​
 +                    SIP contact address: sip:​david@intra-calcman.org:​38276
 +        To: <​sip:​david@intra-calcman.org:​38276;​rinstance=90eafe1f95fbbfa3>;​tag=79182b50
 +            SIP to address: sip:​david@intra-calcman.org:​38276
 +            SIP tag: 79182b50
 +        From: "​julien"<​sip:​julien@intra-calcman.org>;​tag=as1ea41f9e
 +            SIP Display info: "​julien"​
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: as1ea41f9e
 +        Call-ID: 48f934056782cf6f581c024128f6c29c@192.168.0.30
 +        CSeq: 102 INVITE
 +        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
 +        Content-Type:​ application/​sdp
 +        User-Agent: X-Lite release 1003l stamp 30942
 +        Content-Length:​ 239
 +    Message body
 +        Session Description Protocol
 +            Session Description Protocol Version (v): 0
 +            Owner/​Creator,​ Session Id (o): - 4 2 IN IP4 10.42.16.88
 +                Owner Username: -
 +                Session ID: 4
 +                Session Version: 2
 +                Owner Network Type: IN
 +                Owner Address Type: IP4
 +                Owner Address: 10.42.16.88
 +            Session Name (s): CounterPath eyeBeam 1.5
 +            Connection Information (c): IN IP4 10.42.16.88
 +                Connection Network Type: IN
 +                Connection Address Type: IP4
 +                Connection Address: 10.42.16.88
 +            Time Description,​ active time (t): 0 0
 +                Session Start Time: 0
 +                Session Stop Time: 0
 +            Media Description,​ name and address (m): audio 21008 RTP/AVP 0 3 8 101
 +                Media Type: audio
 +                Media Port: 21008
 +                Media Proto: RTP/AVP
 +                Media Format: ITU-T G.711 PCMU
 +                Media Format: GSM 06.10
 +                Media Format: ITU-T G.711 PCMA
 +                Media Format: 101
 +            Media Attribute (a): fmtp:101 0-15
 +                Media Attribute Fieldname: fmtp
 +                Media Format: 101
 +                Media format specific parameters: 0-15
 +            Media Attribute (a): rtpmap:101 telephone-event/​8000
 +                Media Attribute Fieldname: rtpmap
 +                Media Format: 101
 +                MIME Type: telephone-event
 +                MIME type: telephone-event
 +            Media Attribute (a): sendrecv
 +            Media Attribute (a): x-rtp-session-id:​9A236EF6D78A42C39FFB8460582A5DE0
 +                Media Attribute Fieldname: x-rtp-session-id
 +                Media Attribute Value: 9A236EF6D78A42C39FFB8460582A5DE0
 +</​file>​
 +
 +As you can see, david also sends some information for Session Description. In fact, david chooses several parameters among those sent by julien and returns them. Those parameters will define the session.
 +We can also note that the branch value is still the same.
 +
 +
 +===== Voice transport =====
 +
 +
 +David gets the call and sends a RTCP message. RTCP (Real Time Control Protocol) is a protocol used to manage RTP (Real Time Protocol) communication. Both protocols are defined in the RFC 3550. I couldn'​t present it better than the way the RFC does it:
 +
 +<​note>​RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.</​note>​
 +
 +I will deal with RTP after, but for now we have to study the RTCP packet sent by david just before he has accepted the call. Why did he send a RTCP packet before he sent a "200 OK" packet for accepting the call? 
 +
 +There'​s no official reason so we have to assume that's a X-lite developers'​ choice...
 +
 +RTCP has been designed to manage the RTP protocol. It performs four functions:
 +  - Provide feedback on the quality of the data distribution; ​
 +  - Carry a persistent identifier for an RTP source: the canonical name or CNAME; ​
 +  - Use the first two functions to know the exact number of participants,​ and then calculates the rate at which packets are sent; 
 +  - Provide minimal information about the participants. This last function is optional. ​
 +
 +There is several packets types for RTCP: 
 +  * SR : sender report (transmission/​reception statistics from active senders); ​
 +  * RR : ACK for SR when there are more than 31 sources; ​
 +  * SDES : Source Description,​ including CNAME; ​
 +  * BYE : a participant has left the session; ​
 +  * APP : application specific function; ​
 +
 +So, now, let's see the RTCP packet sent by david:
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +36      175.934060 ​ 10.42.16.88 ​          ​10.42.16.48 ​          ​RTCP ​       Receiver Report
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 21009 (21009), Dst Port: 14319 (14319)
 +    Source port: 21009 (21009)
 +    Destination port: 14319 (14319)
 +    Length: 140
 +    Checksum: 0x3bf0 [correct]
 +Real-time Transport Control Protocol (Receiver Report)
 +    [Stream setup by SDP (frame 34)]
 +        [Setup frame: 34]
 +        [Setup Method: SDP]
 +    10.. .... = Version: RFC 1889 Version (2)
 +    ..0. .... = Padding: False
 +    ...0 0000 = Reception report count: 0
 +    Packet type: Receiver Report (201)
 +    Length: 1
 +    Sender SSRC: 739353178
 +Real-time Transport Control Protocol (Source description)
 +    [Stream setup by SDP (frame 34)]
 +        [Setup frame: 34]
 +        [Setup Method: SDP]
 +    10.. .... = Version: RFC 1889 Version (2)
 +    ..0. .... = Padding: False
 +    ...0 0001 = Source count: 1
 +    Packet type: Source description (202)
 +    Length: 30
 +    Chunk 1, SSRC/CSRC 739353178
 +        Identifier: 739353178
 +        SDES items
 +            Type: CNAME (user and domain) (1)
 +            Length: 61
 +            Text: 7260F2D3A8994DF8B7C89FD1A725211A@unique.z4140B17CA7EF45E8.org
 +            Type: PRIV (private extensions) (8)
 +            Length: 49
 +            Prefix length: 16
 +            Prefix string: x-rtp-session-id
 +            Text: 9A236EF6D78A42C39FFB8460582A5DE0
 +            Type: END (0)
 +
 +</​file>​
 +
 +It's a SDES packet, so it provides the CNAME of david. This last is generated randomly using the user name and the host name. In fact, the CNAME is not the primary identifier of an RTP communication. This functionnality is supplied by the SSRC number (which will be described later). But because the SSRC number could change during a session, the CNAME is used to identify a participant in any case.
 +For david, CNAME is: **7260F2D3A8994DF8B7C89FD1A725211A@unique.z4140B17CA7EF45E8.org** ​
 +
 +David, who is very talkative, also sent the first RTP packet: ​
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol ​   Info
 +38      175.989523 ​ 10.42.16.88 ​          ​192.168.0.30 ​          ​RTP ​        ​Payload type=ITU-T G.711 PCMU, SSRC=739353178,​ Seq=1424, Time=2097700,​ Mark
 +{......truncated...datagram......}
 +User Datagram Protocol, Src Port: 21008 (21008), Dst Port: 14318 (14318)
 +    Source port: 21008 (21008)
 +    Destination port: 14318 (14318)
 +    Length: 180
 +    Checksum: 0x78d0 [correct]
 +Real-Time Transport Protocol
 +    10.. .... = Version: RFC 1889 Version (2)
 +    ..0. .... = Padding: False
 +    ...0 .... = Extension: False
 +    .... 0000 = Contributing source identifiers count: 0
 +    1… .... = Marker: True
 +    Payload type: ITU-T G.711 PCMU (0)
 +    Sequence number: 1424
 +    Timestamp: 2097700
 +    Synchronization Source identifier: 739353178
 +    Payload: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF...
 +</​file>​
 +
 +RTP packets are very simple. Their main goal is to deliver payloads (data samples). So, the packet contains only the codec used (Payload Type), the sequence number (for reassembly),​ the Timestamp (packet are dropped after a too long time) and the SSRC we have already talked about.
 +The SSRC is a 32bits number chosen randomly that identifies one specific participant,​ or more precisely a participant'​s session. This number will change in many cases and that's why the CNAME number do exists.
 +But if the line is clear, the SSRC will be the same until the end of the discussion.
 +
 +The Payload is the voice, the video or anything you want, encoded with the codec. ​
 +Closing the call
 +
 +When david wants to leave the communication,​ he sends a BYE SIP datagram such as this one to the proxy:
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol Info
 +   3090 79.192225 ​  ​10.42.16.88 ​          ​192.168.0.30 ​          ​SIP ​     Request: BYE sip:​julien@10.42.16.48:​5060;​transport=UDP
 +{.....truncated...datagram.......}
 +
 +Session Initiation Protocol
 +    Request-Line:​ BYE sip:​julien@10.42.16.48:​5060;​transport=UDP SIP/2.0
 +        Method: BYE
 +        Resent Packet: False
 +    Message Header
 +        Max-Forwards:​ 70
 +        From: <​sip:​david@intra-calcman.org>;​tag=13701
 +            SIP from address: sip:​david@intra-calcman.org
 +            SIP tag: 13701
 +        To: <​sip:​julien@intra-calcman.org>;​tag=6868
 +            SIP to address: sip:​julien@intra-calcman.org
 +            SIP tag: 6868
 +        CSeq: 602 BYE
 +        Call-ID: 11665@10.42.16.88
 +        Route: <​sip:​192.168.0.30;​lr=on;​ftag=13701>​
 +        Via: SIP/2.0/UDP 10.42.16.88:​5060;​rport;​branch=z9hG4bK17673
 +        Content-Length:​ 0
 +</​file>​
 +
 +This is a classic SIP message, david send a BYE Request to julien via the OpenSER Proxy. The proxy forwards the BYE Request to julien and this last one answers the proxy with a 200 OK datagram. Finally, the proxy forwards the 200 OK datagram to david, so the call is closed.
 +
 +<​file>​
 +No.     ​Time ​       Source ​               Destination ​          ​Protocol Info
 +   3095 79.356865 ​  ​10.42.16.24 ​          ​10.6.0.108 ​           SIP      Status: 200 OK
 +{.....truncated...datagram.....}
 +User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
 +    Source port: sip (5060)
 +    Destination port: sip (5060)
 +    Length: 306
 +    Checksum: 0x0432 [correct]
 +Session Initiation Protocol
 +    Status-Line:​ SIP/2.0 200 OK
 +        Status-Code:​ 200
 +        Resent Packet: False
 +    Message Header
 +        Max-Forwards:​ 70
 +        Record-Route:​ <​sip:​192.168.0.30;​lr=on;​ftag=13701>​
 +        From: <​sip:​julien@intra-calcman.org>;​tag=13701
 +            SIP from address: sip:​julien@intra-calcman.org
 +            SIP tag: 13701
 +        To: <​sip:​david@intra-calcman.org>;​tag=6868
 +            SIP to address: sip:​david@intra-calcman.org
 +            SIP tag: 6868
 +        CSeq: 602 BYE
 +        Call-ID: 11665@10.42.16.88
 +        Via: SIP/2.0/UDP 10.42.16.88:​5060;​rport=5060;​branch=z9hG4bK17673
 +        Content-Length:​ 0
 +</​file>​
 +
 +===== Conclusion =====
 +
 +
 +This paper is an unexhaustive overview of SIP and RTP protocols. If you want to find more precise information,​ I recommend to you to read the RFCs. Moreover, if you find mismatching values in this page, this is because I haven'​t wrote it in once. So, several packets come from differents communications.
 +
 +
 +
 +<note tip>​note:​ this article is taken from a university project realized by david bigot and myself during our last year of master at [[http://​iriaf.univ-poitiers.fr/​|University of Poitiers]], in 2007.</​note>​
en/ressources/dossiers/voip/sip_rtp.txt · Last modified: 2011/03/16 00:30 (external edit)
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0