Saturday, 26 November 2011
Wednesday, 23 November 2011
Tuesday, 22 November 2011
1.3. SIP Protocol Assumptions
This document does not prescribe the flows precisely as they are
shown, but rather the flows illustrate the principles for best
practice. They are best practices usages (orderings, syntax,
selection of features for the purpose, handling of error) of SIP
methods, headers and parameters. IMPORTANT: The exact flows here
must not be copied as is by an implementer due to specific incorrect
characteristics that were introduced into the document for
convenience and are listed below. To sum up, the SIP/PSTN call flows
represent well-reviewed examples of SIP usage, which are best common
practice according to IETF consensus.
For simplicity in reading and editing the document, there are a
number of differences between some of the examples and actual SIP
messages. For example, the SIP Digest responses are not actual MD5
encodings. Call-IDs are often repeated, and CSeq counts often begin
at 1. Header fields are usually shown in the same order. Usually
only the minimum required header field set is shown, others that
would normally be present, such as Accept, Supported, Allow, etc. are
not shown.
Actors:
Element Display Name URI IP Address
------- ------------ --- ----------
User Agent Alice sip:alice@a.example.com 192.0.2.101
User Agent Bob sip:bob@b.example.com 192.0.2.200
Proxy Server sip:ss1.a.example.com 192.0.2.111
User Agent (Gateway) sip:gw1.a.example.com 192.0.2.201
User Agent (Gateway) sip:gw2.a.example.com 192.0.2.202
User Agent (Gateway) sip:gw3.a.example.com 192.0.2.203
User Agent (Gateway) sip:ngw1.a.example.com 192.0.2.103
User Agent (Gateway) sip:ngw2.a.example.com 192.0.2.102
Note that NGW 1 and NGW 2 also have device URIs (Contacts) of
sip:ngw1@a.example.com and sip:ngw2@a.example.com which resolve to
the Proxy Server sip:ss1.wcom.com using DNS SRV records.
Johnston, et al. Best Current Practice [Page 5]
RFC 3666 SIP PSTN Call Flows December 2003
2. SIP to PSTN Dialing
In the following scenarios, Alice (sip:alice@a.example.com) is a SIP
phone or other SIP-enabled device. Bob is reachable via the PSTN at
global telephone number +19725552222. Alice places a call to Bob
through a Proxy Server, Proxy 1, and a Network Gateway. In other
scenarios, Alice places calls to Carol, who is served via a PBX
(Private Branch Exchange) and is identified by a private extension
444-3333, or global number +1-918-555-3333. Note that Alice uses
his/her global telephone number +1-314-555-1111 in the From header in
the INVITE messages. This then gives the Gateway the option of using
this header to populate the calling party identification field in
subsequent signaling. Left open is the issue of how the Gateway can
determine the accuracy of the telephone number which is necessary
before passing it as a valid calling party number in the PSTN.
In these scenarios, Alice is a SIP phone or other SIP-enabled device.
Alice places a call to Bob in the PSTN or Carol on a PBX through a
Proxy Server and a Gateway.
In the failure scenarios, the call does not complete. In some cases
however, a media stream is still setup. This is due to the fact that
some failures in dialing to the PSTN result in in-band tones (busy,
reorder tones or announcements - "The number you have dialed has
changed. The new number is..."). The 183 Session Progress response
containing SDP media information is used to setup this early media
path so that the caller Alice knows the final disposition of the
call.
The media stream is either terminated by the caller after the tone or
announcement has been heard and understood, or by the Gateway after a
timer expires.
In other failure scenarios, a SS7 Release with Cause Code is mapped
to a SIP response. In these scenarios, the early media path is not
used, but the actual failure code is conveyed to the caller by the
SIP User Agent Client.
Johnston, et al. Best Current Practice [Page 6]
RFC 3666 SIP PSTN Call Flows December 2003
2.1. Successful SIP to ISUP PSTN call
Alice Proxy 1 NGW 1 Switch B
| | | |
| INVITE F1 | | |
|--------------->| | |
| 100 F2 | | |
|<---------------| INVITE F3 | |
| |--------------->| |
| | 100 F4 | |
| |<---------------| IAM F5 |
| | |--------------->|
| | | ACM F6 |
| | 183 F7 |<---------------|
| 183 F8 |<---------------| |
|<---------------| | |
| Both Way RTP Media | One Way Voice |
|<===============================>|<===============|
| | | ANM F9 |
| | 200 F10 |<---------------|
| 200 F11 |<---------------| |
|<---------------| | |
| ACK F12 | | |
|--------------->| ACK F13 | |
| |--------------->| |
| Both Way RTP Media | Both Way Voice |
|<===============================>|<==============>|
| BYE F14 | | |
|--------------->| BYE F15 | |
| |--------------->| |
| | 200 F16 | |
| 200 F17 |<---------------| REL F18 |
|<---------------| |--------------->|
| | | RLC F19 |
| | |<---------------|
| | | |
Alice dials the globalized E.164 number +19725552222 to reach Bob.
Note that A might have only dialed the last 7 digits, or some other
dialing plan. It is assumed that the SIP User Agent Client converts
the digits into a global number and puts them into a SIP URI. Note
that tel URIs could be used instead of SIP URIs.
Alice could use either their SIP address (sip:alice@a.example.com) or
SIP telephone number (sip:+13145551111@ss1.a.example.com;user=phone)
in the From header. In this example, the telephone number is
included, and it is shown as being passed as calling party
identification through the Network Gateway (NGW 1) to Bob (F5). Note
that for this number to be passed into the SS7 network, it would have
to be somehow verified for accuracy.
In this scenario, Bob answers the call, then Alice disconnects the
call. Signaling between NGW 1 and Bob's telephone switch is ANSI
ISUP. For the details of SIP to ISUP mapping, refer to [4].
In this flow, notice that the Contact returned by NGW 1 in messages
F7-11 is sip:ngw1@a.example.com. This is because NGW 1 only accepts
SIP messages that come through Proxy 1 - any direct signaling will be
ignored. Since this Contact URI may be used outside of this dialog
and must be routable (Section 8.1.1.8 in RFC 3261 [2]) the Contact
URI for NGW 1 must resolve to Proxy 1. This Contact URI resolves via
DNS to Proxy 1 (sip:ss1.a.example.com) which then resolves it to
sip:ngw1.a.example.com which is the address of NGW 1.
This flow shows TCP transport.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:+19725552222@ss1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com;transport=tcp>
Proxy-Authorization: Digest username="alice", realm="a.example.com",
nonce="dc3a5ab25302aa931904ba7d88fa1cf5", opaque="",
uri="sip:+19725552222@ss1.a.example.com;user=phone",
response="ccdca50cb091d587421457305d097458c"
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 100 Trying Proxy 1 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Content-Length: 0
/* Proxy 1 uses a Location Service function to determine the gateway
for terminating this call. The call is forwarded to NGW 1. Client
for A prepares to receive data on port 49172 from the
network.*/
F3 INVITE Proxy 1 -> NGW 1
INVITE sip:+19725552222@ngw1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 100 Trying NGW 1 -> Proxy 1
SIP/2.0 100 Trying
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Johnston, et al. Best Current Practice [Page 9]
RFC 3666 SIP PSTN Call Flows December 2003
;received=192.0.2.111
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Content-Length: 0
F5 IAM NGW 1 -> Bob
IAM
CdPN=972-555-2222,NPI=E.164,NOA=National
CgPN=314-555-1111,NPI=E.164,NOA=National
F6 ACM Bob -> NGW 1
ACM
F7 183 Session Progress NGW 1 -> Proxy 1
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 ngw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* NGW 1 sends PSTN audio (ringing) in the RTP path to A */
F8 183 Session Progress Proxy 1 -> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 ngw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F9 ANM Bob -> NGW 1
ANM
F10 200 OK NGW 1 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 gw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F11 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 ngw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F12 ACK Alice -> Proxy 1
ACK sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 ACK
Content-Length: 0
F13 ACK Proxy 1 -> NGW 1
ACK sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 ACK
Content-Length: 0
/* Alice Hangs Up with Bob. */
F14 BYE Alice -> Proxy 1
BYE sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F15 BYE Proxy 1 -> NGW 1
BYE sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F16 200 OK NGW 1 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F17 200 OK Proxy 1 -> A
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F18 REL NGW 1 -> B
REL
CauseCode=16 Normal
F19 RLC B -> NGW 1
RLC
2.2. Successful SIP to ISDN PBX call
Alice Proxy 1 GW 1 PBX C
| | | |
| INVITE F1 | | |
|--------------->| | |
| 100 F2 | | |
|<---------------| INVITE F3 | |
| |--------------->| |
| | 100 F4 | |
| |<---------------| SETUP F5 |
| | |--------------->|
| | | CALL PROC F6 |
| | |<---------------|
| | | PROGress F7 |
| | 180 F8 |<---------------|
| 180 F9 |<---------------| |
|<---------------| | |
| | | One Way Voice |
| | |<===============|
| | | CONNect F10 |
| | |<---------------|
| | | CONNect ACK F11|
| | 200 F12 |--------------->|
| 200 F13 |<---------------| |
|<---------------| | |
| ACK F14 | | |
|--------------->| ACK F15 | |
| |--------------->| |
| Both Way RTP Media | Both Way Voice |
|<===============================>|<==============>|
| BYE F16 | | |
|--------------->| BYE F17 | |
| |--------------->| |
| | 200 F18 | |
| 200 F19 |<---------------| DISConnect F20 |
|<---------------| |--------------->|
| | | RELease F21 |
| | |<---------------|
| | | RELease COM F22|
| | |--------------->|
| | | |
Alice is a SIP device while Carol is connected via a Gateway (GW 1)
to a PBX. The PBX connection is via a ISDN trunk group. Alice dials
Carol's telephone number (918-555-3333) which is globalized and put
into a SIP URI.
The host portion of the Request-URI in the INVITE F3 is used to
identify the context (customer, trunk group, or line) in which the
private number 444-3333 is valid. Otherwise, this INVITE message
could get forwarded by GW 1 and the context of the digits could
become lost and the call unroutable.
Proxy 1 looks up the telephone number and locates the gateway that
serves Carol. Carol is identified by its extension (444-3333) in the
Request-URI sent to GW 1.
Note that the Contact URI for GW 1, as used in messages F8, F9, F12,
and F13, is sips:4443333@gw1.a.example.com, which resolves directly
to the gateway.
This flow shows the use of Secure SIP (sips) URIs.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sips:+19185553333@ss1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:alice@client.a.example.com>
Proxy-Authorization: Digest username="alice",
realm="a.example.com", nonce="qo0dc3a5ab22aa931904badfa1cf5j9h",
opaque="", uri="sips:+19185553333@ss1.a.example.com;user=phone",
response="6c792f5c9fa360358b93c7fb826bf550"
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 100 Trying Proxy 1 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Content-Length: 0
F3 INVITE Proxy 1 -> GW 1
INVITE sips:4443333@gw1.a.example.com SIP/2.0
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:alice@client.a.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 100 Trying GW -> Proxy 1
SIP/2.0 100 Trying
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
;received=192.0.2.111
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Content-Length: 0
F5 SETUP GW 1 -> Carol
Protocol discriminator=Q.931
Message type=SETUP
Bearer capability: Information transfer capability=0 (Speech) or 16
(3.1 kHz audio)
Channel identification=Preferred or exclusive B-channel
Progress indicator=1 (Call is not end-to-end ISDN;further call
progress information may be available inband)
Called party number:
Type of number unknown
Digits=444-3333
F6 CALL PROCeeding Carol-> GW 1
Protocol discriminator=Q.931
Message type=CALL PROC
Channel identification=Exclusive B-channel
F7 PROGress Carol-> GW 1
Protocol discriminator=Q.931
Message type=PROG
Progress indicator=1 (Call is not end-to-end ISDN;further call
progress information may be available inband)
F8 180 Ringing GW 1 -> Proxy 1
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:4443333@gw1.a.example.com>
Content-Length: 0
Johnston, et al. Best Current Practice [Page 18]
RFC 3666 SIP PSTN Call Flows December 2003
F9 180 Ringing Proxy 1 -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:4443333@gw1.a.example.com>
Content-Length: 0
F10 CONNect Carol-> GW 1
Protocol discriminator=Q.931
Message type=CONN
F11 CONNect ACK GW 1 -> Carol
Protocol discriminator=Q.931
Message type=CONN ACK
F12 200 OK GW 1 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:4443333@gw1.a.example.com>
Content-Type: application/sdp
Content-Length: 144
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.example.com
s=-
c=IN IP4 gw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F13 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sips:4443333@gw1.a.example.com>
Content-Type: application/sdp
Content-Length: 144
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.example.com
s=-
c=IN IP4 gw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F14 ACK Alice -> Proxy 1
ACK sips:4443333@gw1.a.example.com SIP/2.0
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 ACK
Content-Length: 0
F15 ACK Proxy 1 -> GW 1
ACK sips:4443333@gw1.a.example.com SIP/2.0
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 ACK
Content-Length: 0
/* Alice Hangs Up with Bob. */
F16 BYE Alice -> Proxy 1
BYE sips:4443333@gw1.a.example.com SIP/2.0
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sips:ss1.a.example.com;lr>
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 3 BYE
Content-Length: 0
F17 BYE Proxy 1 -> GW 1
BYE sips:4443333@gw1.a.example.com SIP/2.0
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 3 BYE
Content-Length: 0
F18 200 OK GW 1 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 3 BYE
Content-Length: 0
F19 200 OK Proxy 1 -> A
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sips:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Carol <sips:+19185553333@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 3 BYE
Content-Length: 0
F20 DISConnect GW 1 -> Carol
Protocol discriminator=Q.931
Message type=DISC
Cause=16 (Normal clearing)
F21 RELease Carol-> GW 1
Protocol discriminator=Q.931
Message type=REL
F22 RELease COMplete GW 1 -> Carol
Protocol discriminator=Q.931
Message type=REL COM
Successful SIP to ISUP PSTN call with overflow
Alice Proxy 1 NGW 1 NGW 2 Switch B
| | | | |
| INVITE F1 | | | |
|------------->| | | |
| | INVITE F2 | | |
| 100 F3 |------------->| | |
|<-------------| 503 F4 | | |
| |<-------------| | |
| | ACK F5 | | |
| |------------->| | |
| | INVITE F6 | |
| |---------------------------->| IAM F7 |
| | |------------->|
| | | ACM F8 |
| | 183 F9 |<-------------|
| 183 F10 |<----------------------------| |
|<-------------| | |
| Two Way RTP Media | One Way Voice|
|<==========================================>|<=============|
| | | ANM F11 |
| | 200 F12 |<-------------|
| 200 F13 |<----------------------------| |
|<-------------| | |
| ACK F14 | | |
|------------->| ACK F15 | |
| |---------------------------->| |
| Both Way RTP Media |Both Way Voice|
|<==========================================>|<============>|
| BYE F16 | | |
|------------->| BYE F17 | |
| |---------------------------->| |
| | 200 F18 | |
| 200 F19 |<----------------------------| REL F20 |
|<-------------| |------------->|
| | | RLC F21 |
| | |<-------------|
| | | |
Alice calls Bob through Proxy 1. Proxy 1 tries to route to a Network
Gateway NGW 1. NGW 1 is not available and responds with a 503
Service Unavailable (F4). The call is then routed to Network Gateway
NGW 2. Bob answers the call. The call is terminated when Alice
disconnects the call. NGW 2 and Bob's telephone switch use ANSI ISUP
signaling.
NGW 2 also only accepts SIP messages that come through Proxy 1, so
the Contact URI sip:ngw2@a.example.com is used in this flow.
This flow shows UDP transport.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:+19725552222@ss1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com>
Proxy-Authorization: Digest username="alice",
realm="a.example.com", nonce="b59311c3ba05b401cf80b2a2c5ac51b0",
opaque="", uri="sip:+19725552222@ss1.a.example.com;user=phone",
response="ba6ab44923fa2614b28e3e3957789ab0"
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Proxy 1 uses a Location Service function to determine where B is
located. Proxy 1 receives a primary route NGW 1 and a secondary
route NGW 2. NGW 1 is tried first */
F2 INVITE Proxy 1 -> NGW 1
INVITE sip:+19725552222@ngw1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F3 100 Trying Proxy 1 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Content-Length: 0
F4 503 Service Unavailable NGW 1 -> Proxy 1
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=123456789
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Content-Length: 0
F5 ACK Proxy 1 -> NGW 1
ACK sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com>;user=phone>
;tag=123456789
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 ACK
Content-Length: 0
/* Proxy 1 now tries secondary route to NGW 2 */
F6 INVITE Proxy 1 -> NGW 2
INVITE sip:+19725552222@ngw2.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F7 IAM NGW 2 -> Bob
IAM
CdPN=972-555-2222,NPI=E.164,NOA=National
CgPN=314-555-1111,NPI=E.164,NOA=National
F8 ACM Bob -> NGW 2
ACM
F9 183 Session Progress NGW 2 -> Proxy 1
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
;received=192.0.2.111
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw2@a.example.com>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw2.a.example.com
s=-
c=IN IP4 ngw2.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* RTP packets are sent by GW to A for audio (e.g. ring tone) */
F10 183 Session Progress Proxy 1 -> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw2@a.example.com>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw2.a.example.com
s=-
c=IN IP4 ngw2.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F11 ANM Bob -> NGW 2
ANM
F12 200 OK NGW 2 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
;received=192.0.2.111
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw2@a.example.com>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw2.a.example.com
s=-
c=IN IP4 ngw2.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F13 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:ngw2@a.example.com>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw2.a.example.com
s=-
c=IN IP4 ngw2.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F14 ACK Alice -> Proxy 1
ACK sip:ngw2@a.example.com SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 ACK
Content-Length: 0
F15 ACK Proxy 1 -> NGW 2
ACK sip:ngw2@a.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 ACK
/* RTP streams are established between A and B(via the GW) */
/* Alice Hangs Up with Bob. */
F16 BYE Alice -> Proxy 1
BYE sip:ngw2@a.example.com SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <ss1.a.example.com;lr>
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F17 BYE Proxy 1 -> NGW 2
BYE sip:ngw2@a.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F18 200 OK NGW 2 -> Proxy 1
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2
;received=192.0.2.111
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F19 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone>
;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 BYE
Content-Length: 0
F20 REL NGW 2 -> B
REL
CauseCode=16 Normal
F21 RLC B -> NGW 2
RLC
2.4. Successful SIP to SIP using ENUM Query
Alice DNS Server Proxy 3 Bob
| | | |
| ENUM Query F1 | | |
|--------------->| | |
| Response F2 | | |
|<---------------| | |
| INVITE F3 | |
|-------------------------------->| INVITE F4 |
| 100 F5 |--------------->|
|<--------------------------------| 180 F6 |
| 180 F7 |<---------------|
|<--------------------------------| |
| | 200 F8 |
| 200 F9 |<---------------|
|<--------------------------------| |
| ACK F10 | |
|-------------------------------->| ACK F11 |
| |--------------->|
| Both Way RTP Media |
|<================================================>|
| | BYE F12 |
| BYE F13 |<---------------|
|<--------------------------------| |
| 200 F14 | |
|-------------------------------->| 200 F15 |
| |--------------->|
| | |
In this scenario, Alice places a call to Bob by dialing Bob's
telephone number (9725552222). Alice's UA converts the phone number
to an E.164 number (+19725552222), and performs an ENUM query [9] on
the E.164 number (2.2.2.2.5.5.5.2.7.9.1.e164.arpa), which returns a
NAPTR record containing a SIP AOR URI for Bob
(sip:+19725552222@b.example.com). As a result, Alice's UA sends an
INVITE and the call completes over IP bypassing the PSTN.
The call is terminated when Bob sends a BYE message.
Message Details
F1 ENUM Query Alice -> DNS Server
2.2.2.2.5.5.5.2.7.9.1.e164.arpa
F2 ENUM NAPTR Set DNS Server -> Alice
$ORIGIN 2.2.2.2.5.5.5.2.7.9.1.e164.arpa.
IN NAPTR 100 10 "u" "sip+E2U"
"!^.*$!sip:+19725552222@b.example.com!".
F3 INVITE Alice -> Proxy 3
INVITE sip:+19725552222@b.example.com SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+13145551111@client.a.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 INVITE Proxy 3 -> Bob
INVITE sip:+19725552222@client.b.example.com SIP/2.0
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+13145551111@client.a.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F5 100 Trying Proxy 3 -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Content-Length: 0
F6 180 Ringing B -> Proxy 3
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
;received=192.0.2.233
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+19725552222@client.b.example.com>
Content-Length: 0
F7 180 Ringing Proxy 3 -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+19725552222@client.b.example.com>
Content-Length: 0
F8 200 OK Bob -> Proxy 3
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
;received=192.0.2.233
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+19725552222@client.b.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=bob 2890844527 2890844527 IN IP4 client.b.example.com
s=-
c=IN IP4 client.b.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F9 200 OK Proxy -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 INVITE
Contact: <sip:+19725552222@client.b.example.com>
Content-Type: application/sdp
Content-Length: 151
v=0
o=bob 2890844527 2890844527 IN IP4 client.b.example.com
s=-
c=IN IP4 192.0.2.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F10 ACK Alice -> Proxy 3
ACK sip:+19725552222@client.b.example.com SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bq9
Max-Forwards: 70
Route: <sip:ss3.b.example.com;lr>
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 ACK
Content-Length: 0
F11 ACK Proxy 3 -> Bob
ACK sip:+19725552222@client.b.example.com SIP/2.0
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bq9
;received=192.0.2.101
Max-Forwards: 69
From: <sip:+13145551111@a.example.com>;tag=9fxced76sl
To: <tel:+19725552222>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 2 ACK
Content-Type: application/sdp
Content-Length: 0
/* RTP streams are established between A and B*/
/* User B Hangs Up with User A. */
F12 BYE Bob -> Proxy 3
BYE sip:+13145551111@client.a.example.com SIP/2.0
Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2
Max-Forwards: 70
Route: <sip:ss3.b.example.com;lr>
From: <tel:+19725552222>;tag=314159
To: <sip:+13145551111@a.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 BYE
Content-Length: 0
F13 BYE Proxy 3 -> Alice
BYE sip:+13145551111@client.a.example.com SIP/2.0
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
;received=192.0.2.100
Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2
Max-Forwards: 69
From: <tel:+19725552222>;tag=314159
To: <sip:+13145551111@a.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 BYE
Content-Length: 0
F14 200 OK Alice -> Proxy 3
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1
;received=192.0.2.233
Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2
;received=192.0.2.100
From: <tel:+19725552222>;tag=314159
To: <sip:+13145551111@a.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 BYE
Content-Length: 0
F15 200 OK Proxy 3 -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2
;received=192.0.2.100
From: <tel:+19725552222>;tag=314159
To: <sip:+13145551111@a.example.com>;tag=9fxced76sl
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 BYE
Content-Length: 0
Sunday, 20 November 2011
Data that makes it possible to paint a digital picture of the world and the people in it, every second. Data collected from everywhere that connects to everywhere.
Infinite data points that only make sense, when they're transformed into intelligence. Built on smart data principles, and the digital footprints of hundreds of millions of consumers worldwide. The Nokia Platform understands: Who, what, where, when, why, and how. To help answer, what next?
Smart data gets smarter over time. Smart data makes it possible to personalize services that speak to who we are, and help us make the most of the moment. The world lives, breathes and changes constantly. Smart data, to make sense of that change, changes everything.
<<<<<<<<<<<<<<<TELECOM STUFF>>>>>>>>>>>>>>
GSM-UMTS evolution(This Doc shows the technology changes from GSM to UMTS with good Architure ).
PERL-COOK BOOK(This is the book of perl script creator).
LTE(Harri Holam & Toskala) for reference only.
SIP performance testing tool.
Sample test case for SIP testing.
SIP conformation test suit.
SIP IOT test suit
NOTE:Docs are password protected,password provided only for members .
GSM-UMTS evolution(This Doc shows the technology changes from GSM to UMTS with good Architure ).
PERL-COOK BOOK(This is the book of perl script creator).
LTE(Harri Holam & Toskala) for reference only.
SIP performance testing tool.
Sample test case for SIP testing.
SIP conformation test suit.
SIP IOT test suit
NOTE:Docs are password protected,password provided only for members .
Thursday, 17 November 2011
Friday, 11 November 2011
MIMO and Smart Antennas for 3G and 4G Wireless Systems
Americas has published an educational white paper
titled, MIMO and Smart Antennas for 3G and 4G Wireless Systems:
Practical Aspects and Deployment Considerations. The report is a
complete tutorial reference document that outlines the considerable
importance of various smart antenna schemes for improving the capacity
and coverage of the emerging generations of wireless networks.
With the rapid growth of wireless data traffic,
now greatly exceeding voice traffic in many developed markets,
operators are anxious to quickly expand the capacity and coverage of
their wireless networks. To address these demands for increased
capacity in a cost effective way, 3GPP standards have incorporated
powerful techniques for using “smart antennas.”
“The gains in spectral efficiency being advanced
by new wireless air interface technologies, such as LTE and
LTE-Advanced, will be enabled by the application of MIMO and other
smart antenna technologies,” stated Kevin Linehan, Vice President and
Chief Technology Officer – Base Station Antenna Systems, Andrew
Solutions. Linehan, one of the project leaders for the creation of the
3G Americas report continued, “It is critical that operators and others
in the industry appreciate these advanced technologies and their
practical application.”
The term smart antennas refers to adaptive array
antennas – those with electrical tilt, beam width and azimuth control
that can follow relatively slow-varying traffic patterns; intelligent
antennas, which can form beams aimed at particular users or steer nulls
to reduce interference; and MIMO antenna schemes, predominately
featured in LTE and LTE-Advanced.
The white paper was created by a 3G Americas
technical work group and concentrates on the practical aspects of
antennas and their deployment for 3G and 4G wireless systems,
specifically downlink antenna techniques available in 3GPP LTE Release
8. The comprehensive report highlights a substantial and growing body
of theoretical and field experience that provides reliable guidance on
the tradeoffs of various antenna configurations. Some of the areas
addressed in the paper include:
- Smart antennas provide the next substantial increase in throughput for wireless networks. The peak data rates tend to be proportional to the number of send and receive antennas, so 4X4 MIMO is theoretically capable of twice the peak data rates as 2X2 MIMO systems. For another example, in upgrading from HSPA (1X2) to LTE (2X2) a gain of 1.6x is seen (Rysavy Research, 2009).
- The practical tradeoffs of performance with the realistic constraints on the types of antennas that can be realistically installed, cognizant of zoning, wind loading, size, weight and cabling challenges and constraints from legacy terminals and other equipment. Constraints are, of course, present in both the base station and the terminal side of the air interface, where MIMO technology promises useful gains if multiple antennas, amplifiers, receivers and baseband processing resources can be made available in terminals.
- Beyond the single antenna or beamforming array cases, 3GPP Release 8 of the LTE standard supports MIMO antenna configurations. This includes Single-User (SU-MIMO) protocols using either Open Loop or Closed-Loop modes as well as Transmit Diversity and MU-MIMO. Closed-Loop MIMO mode, which supports the highest peak data rates, is likely to be the most commonly used scheme in early deployments. However, this Closed-Loop MIMO scheme provides the best performance only when the channel information is accurate, when there is a rich multipath environment and is appropriate in low mobility environments such as with fixed terminals or those used at pedestrian speeds.
Sunday, 6 November 2011
SIP and SIP-I: Session Initiation Protocol
 |
Session Initiation Protocol (SIP) is the core networking protocol used within the IP Multimedia Subsystem (IMS)
and is one of the more widely known examples of a session control
protocol. Session control refers to the process used to create, modify
and terminate IP-based communication sessions, and a session can include
two-way voice communication, multimedia (text, audio or video)
conference collaboration, instant messaging, application sharing and
other contemplated but not yet fully specified services. Session control
is accomplished through signaling between various network elements and
endpoints using a session control protocol.
Although SIP is the most widely known session control protocol, SIP has a major limitation that is of great importance to any GSM-UMTS
operator. It does not provide any method of directly inter-working with
the Public Switched Telephone Network (PSTN) because it was not created
with the intention of it being fully backwards-compatible with legacy
PSTN signaling mechanisms.
In addition to SIP, other examples of session control protocols include BICC, SIP-I and SIP-T.
BICC, or Bearer Independent Call Control, is the protocol standardized
in the 3GPP Release 4 architecture and deployed in some networks today.
BICC, however, is not an optimal choice for ongoing evolution because it
has been limited to, and is predicted to remain limited to, operation
within a GSM-UMTS context. BICC does not address domains beyond GSM-UMTS
such as LTE;
as a result, it does not automatically offer the future level of
flexibility of continued development and evolution that would accompany
the SIP with ISUP encapsulation variants (i.e. either SIP-T, SIP for
Telephones or SIP-I, SIP with ISUP encapsulation).
With a technical analysis of capabilities existing within the two SIP
technologies with ISUP encapsulation variants, 4G Americas recommends
SIP-I as the direction for evolution. There are four areas where SIP-I
is better suited for a GSM-UMTS environment than SIP-T:
|
Thursday, 3 November 2011
Learn how Cisco is Transforming the 4G Mobile Internet Transformation: Cisco is leading this mobile transformation, by delivering mobility solutions that are based on purpose-built IP platforms. These solutions provide industry-leading performance, scalability, and intelligence, and allow consumers to be continuously connected wherever they are, using any device or technology
After much evolution of telecommunication technologies we are now in a generation where mobile communication is the biggest medium of communication. Apart from biggest now Mobile communication is one of the most complex systems ever used so vastly around the globe.
In mobile communication system User Equipment (Mobile Stations) are one of the most important node.
To make sure that the mobile stations should work properly testing is a must during the whole development cycle and also after the complete product is developed.
We have documented 5 important reasons why testing is very important in mobile station development.
When 3G was drafted during beginning of 1990s many more services were introduced. It was also decided that mobile stations will support different verities of QoS (Quality of Service), which includes Voice, PS (there are many QoS specified for PS like Background class, interactive class, streaming, etc), video telephony, SMS, MMS.
By adding so many services the system became more complex. During the evolution of 3GPP standardization many more new concepts were introduced. Some of these are IMS, MIMO, HSDPA, HSUPA, etc. These added extra overhead in the design of the mobile stations.
With introduction of LTE added a new type of air interface and new type of QoS criteria.
To make sure the mobile stations are working as per the standards with these technologies testing of each and every service type is very important. This includes signaling and data testing of each kind of services.
Testing also should be done when user equipments do handover inside the systems and also between different systems.
With so many different NW vendors it is the goal of the mobile station producers to test their mobile stations against most of them. This is because each NW vendors have their own set of implemented configuration from 3GPP standards.
This is the reason that most of the NW vendors have their own labs where UE manufactures can test the mobile stations. This type of testing is called interoperability testing. In this type of interoperability testing, UEs are tested against NW configurations in controlled environments.
So it is the responsibility of the component suppliers to check the quality of the components before delivering to UE manufacturers.
The UE manufacturers should check the quality of the end product.
This process finds out if there are some bugs or issue with the mobile station or component in the operator’s NW configuration. Some of the most common issues which can be fixed during this phase are Throughput, configuration issue, handover problems, call drop issues, etc.
These tests are most of the time tested against system simulators.
There are many companies they provide system simulators. These include Anristu, Anite, Rohde & Schwarz, etc.
In mobile communication system User Equipment (Mobile Stations) are one of the most important node.
To make sure that the mobile stations should work properly testing is a must during the whole development cycle and also after the complete product is developed.
We have documented 5 important reasons why testing is very important in mobile station development.
Reason:1 So Many Technologies
Mobile communication has a long history. Starting from 1st generation till 4th generation the technology becomes complex. For example GSM which was a second generation popular technology was developed for Voice and CS related traffic. But when the demand for data (PS) services grew different other technologies were added with GSM. These include GPRS, EDGE, etc.By adding so many services the system became more complex. During the evolution of 3GPP standardization many more new concepts were introduced. Some of these are IMS, MIMO, HSDPA, HSUPA, etc. These added extra overhead in the design of the mobile stations.
With introduction of LTE added a new type of air interface and new type of QoS criteria.
To make sure the mobile stations are working as per the standards with these technologies testing of each and every service type is very important. This includes signaling and data testing of each kind of services.
Testing also should be done when user equipments do handover inside the systems and also between different systems.
Reason:2 Different Network Vendors Different Configuration
The number of Network Equipment (Base stations, Core Network, RNC, etc) providers are many. Some of them are Ericsson, Alcatel Lucent, Nokia Siemens Network, Huawei, Nortel, ZTE, DoCoMo, Motorola, etc.This is the reason that most of the NW vendors have their own labs where UE manufactures can test the mobile stations. This type of testing is called interoperability testing. In this type of interoperability testing, UEs are tested against NW configurations in controlled environments.
Reason:3 UE Manufacturers Are Not Component Suppliers
In today’s competitive industry, it is hard for one company to focus on all aspect of mobile handset development. That is the reason why many handset manufacturers buy components from other companies. These components include protocol stacks, chipsets, cameras, etc.The UE manufacturers should check the quality of the end product.
Reason:4 Operators Are The New Bosses
These days it is a regular practice to buy mobiles directly from operators. Operators decide which mobile station they will sell. This is the reason why the component suppliers and the mobile manufacturers need to test their UEs in Operators labs & live environment.Reason:5 Without Certification Mobiles Can Not Be Sold
Certifications are introduced by standardization bodies to make sure that all mobile stations should follow a minimum set of criteria before those can be released. For this reason standardization bodies like GCF created test suites and those suites are tested against the UEs. This type of testing brings out many common functionality problems in the mobile stations. This is called conformance testing.There are many companies they provide system simulators. These include Anristu, Anite, Rohde & Schwarz, etc.
HD Voice - Next step in the evolution of voice communication
Nearly 2 years back I blogged about Orange launching HD Voice via the use of AMR-WB (wideband) codecs. HD voice is already fully developed and standardized technology and has so far been deployed on 32 networks in almost as many countries. People who have experienced HD voice say it feels like they are talking to a person in the same room. Operators derive 70 percent of their revenue from voice and voice-related services, and studies show that subscribers appreciate the personal nature of voice communication, saying it offers a familiar and emotional connection to another person.
HD voice is also a reaction to the competition faced by the operators from OTT players like Skype.
Donor eNB (DeNB) and Relay Node (RN)
Extracted from 3GPP 36.300:
The eNB hosts the following functions:
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
- IP header compression and encryption of user data stream;
- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;
- Routing of User Plane data towards Serving Gateway;
- Scheduling and transmission of paging messages (originated from the MME);
- Scheduling and transmission of broadcast information (originated from the MME or O&M);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);
- CSG handling;
- Transport level packet marking in the uplink.
The DeNB hosts the following functions in addition to the eNB functions:
- S1/X2 proxy functionality for supporting RNs;
- S11 termination and S-GW/P-GW functionality for supporting RNs.
E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface. The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF. In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.
The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN.
The eNB hosts the following functions:
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
- IP header compression and encryption of user data stream;
- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;
- Routing of User Plane data towards Serving Gateway;
- Scheduling and transmission of paging messages (originated from the MME);
- Scheduling and transmission of broadcast information (originated from the MME or O&M);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);
- CSG handling;
- Transport level packet marking in the uplink.
The DeNB hosts the following functions in addition to the eNB functions:- S1/X2 proxy functionality for supporting RNs;
- S11 termination and S-GW/P-GW functionality for supporting RNs.
E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface. The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF. In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.
The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN.
Subscribe to:
Posts (Atom)