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

["Elwell, John" <john.elwell at siemens.com>]

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: 12345600 at atlanta.example.com". For global
uniqueness, would "Call-ID: 12345600 at client.atlanta.example.com" be better.
This would impact the other flows too.

Section 2.3 F1: "Contact: <sips:music at server.example.com>" 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:bob at biloxi.example.com>;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:alice at atlanta.example.com SIP/2.0". Change to
"NOTIFY sips:alice at atlanta.client.example.com 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: 12345601 at atlanta.example.com". This is a curious
choice of Call-ID, since the call is initiated by Bob at biloxy.com. 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




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP