Subject: [Sipping] New Versions of Call Flows I-Ds

From: Alan Johnston <[email-masked]>
Date: Sun, 06 Apr 2003 21:22:53 -0500

All,

I've just submitted new versions of the basic and PSTN call flows 
documents.  The updates are mainly minor wording changes based on IESG 
feedback.

However, I have added a new flow in the PSTN Call Flows showing ENUM in 
Section 2.4.  I would greatly appreciate if the working group could look 
over that flow (which I have reproduced below for your convenience...)

Until they are available in the archives, the documents are available at:

      http://ee.wustl.edu/~alan/draft-ietf-sipping-basic-call-flows-02.txt
      http://ee.wustl.edu/~alan/draft-ietf-sipping-pstn-call-flows-02.txt

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]
  - - - - -
(View with a fixed width font such as Courier)

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) performs an ENUM query [10] 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:[email-masked]).  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:[email-masked]!".

F3 INVITE Alice -> Proxy 3

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: <sip:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked]>
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:[email-masked] 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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked]>
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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>
Call-ID: [email-masked]
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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked]>
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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked]>
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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked];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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
CSeq: 2 INVITE
Contact: <sip:[email-masked]>
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:[email-masked] 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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
CSeq: 2 ACK
Content-Length: 0

F11 ACK Proxy 3 -> Bob

ACK sip:[email-masked] 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:[email-masked]>;tag=9fxced76sl
To: <sip:[email-masked]>;tag=314159
Call-ID: [email-masked]
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:[email-masked] 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: <sip:[email-masked]>;tag=314159
To: <sip:[email-masked]>;tag=9fxced76sl
Call-ID: [email-masked]
CSeq: 1 BYE
Content-Length: 0

F13 BYE Proxy 3 -> Alice

BYE sip:[email-masked] 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: <sip:[email-masked]>;tag=314159
To: <sip:[email-masked]>;tag=9fxced76sl
Call-ID: [email-masked]
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: <sip:[email-masked]>;tag=314159
To: <sip:[email-masked]>;tag=9fxced76sl
Call-ID: [email-masked]
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: <sip:[email-masked]>;tag=314159
To: <sip:[email-masked]>;tag=9fxced76sl
Call-ID: [email-masked]
CSeq: 1 BYE
Content-Length: 0

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Apr 2003 17:25:06 -0400

> over that flow (which I have reproduced below for your convenience...)

Alan,

I have one question about this flow. You have the INVITE containing

which is the chosen result from the ENUM lookup. My feeling is that this 
address should be used as the request uri, but that the To uri would be 
better as <tel:+19725552222>.

The reason is that what the user requested was just the telephone 
number, not that specific routing of the number through b.example.com. 
While the mechanics of ENUM are different, this transformation is 
logically similar to a redirection. Normally a redirection changes the 
request uri, but leaves To: unchanged. So in this case, I think using a 
tel: in the To header would more accurately reflect what is going on.

An example of when this might matter is if bob didn't answer the call 
and it was then forwarded to charlie. Charlie's phone could be smart 
enough to identify calls that aren't addressed To charlie, and pop up a 
display indicating the intended destination. If the To: is a tel: uri, 
then it can be formatted nicely as a phone number. If the number is a 
sip uri, then the phone will likely have to present it that way, which 
isn't very user friendly.

	Paul

---

From: Alan Johnston <[email-masked]>
Date: Mon, 07 Apr 2003 20:31:28 -0500

Paul,

Thanks very much for your review of the flow.  I agree with you that making 
the To URI a tel shows the "redirection" that is taking place using ENUM 
more clearly.  This change could be made elsewhere in the document but 
unlike this case, it doesn't add much value or clarity.

I'll go ahead and make the change to this flow unless someone thinks this 
is a bad idea.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

At 05:25 PM 4/7/2003 -0400, Paul Kyzivat wrote:

>The reason is that what the user requested was just the telephone number, 
>not that specific routing of the number through b.example.com. While the 
>mechanics of ENUM are different, this transformation is logically similar 
>to a redirection. Normally a redirection changes the request uri, but 
>leaves To: unchanged. So in this case, I think using a tel: in the To 
>header would more accurately reflect what is going on.
>
>An example of when this might matter is if bob didn't answer the call and 
>it was then forwarded to charlie. Charlie's phone could be smart enough to 
>identify calls that aren't addressed To charlie, and pop up a display 
>indicating the intended destination. If the To: is a tel: uri, then it can 
>be formatted nicely as a phone number. If the number is a sip uri, then 
>the phone will likely have to present it that way, which isn't very user 
>friendly.
>
>         Paul