Subject: RE: [Sipping] WGLC of draft-ietf-sipping-service-examples-10.txt

From: Joël Repiquet <[email-masked]>
Date: Sat, 17 Jun 2006 20:38:17 +0200

Here are my remarks regarding sections 2.4, 2.5 and 2.6 related to Transfer:

2.4.  Transfer - Unattended
------------------------------

1) The "Supported: replaces" message-header line in F1, F3, F4, F11 and F13
is superfluous and I suggest to remove it

2) The session identifier (2890844527) is the same for Bob's SDP offer in F1,
and for (unrelated) Carol's SDP answer in F13.
idem for the audio transport port (3456)

3) IP addresses appear to be:
- 192.0.2.105 for Alice
- 192.0.2.113 for Bob

As a result, in F6: (response to Alice)
;received=192.0.2.113
is to be replaced by:
;received=192.0.2.105

4) In F5, the initial value of the sequence number for this first request on the UAS
side within this dialog is very unlikely to be 2.
Although it is not incorrect in the strict sense, I suggest the value 101 for
avoiding any confusion.

Therefore, the line:
CSeq: 2 REFER
is to be replaced by:
CSeq: 101 REFER

and as a result:

in F6, the line:
CSeq: 2 REFER
is to be replaced by:
CSeq: 101 REFER

in F9, the line:
CSeq: 3 BYE
is to be replaced by:
CSeq: 102 BYE

in F10, the line:
CSeq: 3 BYE
is to be replaced by:
CSeq: 102 BYE

2.5.  Transfer - Attended
-------------------------

1) In the comments before the message details, the line:
prepared, if the triggered INVITE had fails, to retry the REFER with
is to be replaced by:
prepared, if the triggered INVITE had failed, to retry the REFER with

2) IP addresses appear to be:
- 192.0.2.103 for Alice
- 192.0.2.113 for Bob
- 192.0.2.123 for Carol
As a result:

in F20: (response to Alice)
;received=192.0.2.123
is to be replaced by:
;received=192.0.2.103

in F23: (response to Carol)
;received=192.0.2.103
is to be replaced by:
;received=192.0.2.123

in F24: (F20 response to Alice in the message/sipfrag body)
;received=192.0.2.123
is to be replaced by:
;received=192.0.2.103

3) F19 has 2 extra whitespace lines

2.6.  Transfer - Instant Messaging
----------------------------------

1) In the text/html body of F5, the to-tag should be: 3145678
as a result, the line:
[email-masked]%3Bto-tag%3D314159
is to be replaced by:
[email-masked]%3Bto-tag%3D3145678

2) In F7, F8 and F9:
Call-ID: [email-masked]
is to be replaced by:
Call-ID: [email-masked]

Regards

Joël

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Fri, 23 Jun 2006 11:29:57 +0100

My comments resulting from review of assigned sections (2.3, 2.18, 2.19):

Section 1: "and will help further the goal of a standard implementation of
RFC 3261 [2]". Add "... and some of its extensions".

Section 1: "Other RFCs also comprise the SIP standard and are used and
references in these call flows.". Change to "Other RFCs also form part of
the SIP standard and are used and referenced in these call flows."

Section 1: "Some examples make use the GRUU". Change to "Some examples make
use of the GRUU".

Section 1: "The use of Secure SIP URIs (sips) is shown throughout this
document with assumed certificate validation for security.  However, other
security approaches such as Digest challenges can be used." I have a problem
with this statement, since it seems to assume that SIPS and Digest
challenges are mutually interchangeable. They are not, and the use of TLS
transport in conjunction with Digest authentication is a likely scenario,
particularly between a UA and its outbound proxy, where only TLS server
authentication is likely to be available. I would propose "The use of Secure
SIP URIs (sips) is shown throughout this document, implying TLS transport on
each hop with assumed certificate validation. However, other security
approaches can be used. Also the used of Digest authentication is shown in
some examples."

Section 2.3: "off of hold". Change to "off hold".

Section 2.3: "Note that if Alice responds to the INVITE with hold SDP in the
200 OK, this call flow will not work properly.". I don't understand what
this means. Greater explanation is required. In particular which INVITE
(presumably F7), and what is meant by "hold SDP" here - a=inactive?

Section 2.3 F1: "Call-ID: [email-masked]". For global
uniqueness, would "Call-ID: [email-masked]" be better.
This would impact the other flows too.

Section 2.3 F1: "Contact: <sips:[email-masked]>" and "c=IN IP4
music.server.example.com". I would normally expect the host part of the
contact URI to be the same as the host in the SDP c= line, although of
course it doesn't need to be.

Section 2.3 F8: ";received=192.0.2.103". This is the same IP address as used
by Bob in F2, for example. Likewise F14.

Section 2.18 "A is alerted". Change to "Alice is alerted".

Section 2.18 F2 "To: Bob <sips:[email-masked]>;tag=982039i4". A 486
response is not dialog-forming, so I am not sure why it contains a To tag.
However, I can't find anything in RFC 3261 that clarifies this. If the To
tag is removed, this will also impact F3.

Section 2.18 F5: This is missing an Expires header.

Section 2.18 F6 "NOTIFY sips:[email-masked] SIP/2.0". Change to
"NOTIFY sips:[email-masked] SIP/2.0"

Section 2.18 F6: This is missing a Contact header.

Section 2.18 F8: "Subscription-State: active;expires=3600". The value of
3600 for the expires parameter is not very realistic - it has not decreased
since the initial NOTIFY request.

Section 2.18. It does not show Alice cancelling the subscription - not
essential but likely.

Section 2.18 F10: "o=alice 2890844526 2890844526 IN IP4
client.atlanta.example.com". The session ID and version are the same as in
F1, but this is a new session request.

Section 2.19 "Note that Bob's SIP phone immediately terminates the dialog by
indicating in the NOTIFY (F3) that the subscription is terminated.".
Although legitimate, this is not typical behaviour.

Section 2.19 F1: "Call-ID: [email-masked]". This is a curious
choice of Call-ID, since the call is initiated by [email-masked]. This will
impact subsequent flows too. Similar comment on F5.

Section 2.19 F1: "Contact: <sips:pc.client.atlanta.example.com>". Similarly
this seems wrong. Presumably it should be the value in the Request-URI of
F3.

Section 2.19 F3: "Content-Type: message/sipfrag" - no body is shown, and I
don't think there should be a body.

Section 2.19 F4: ";received=192.0.2.113". This is the same as in F2 - should
be different. Similar comment on F6/F7.

John