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

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Nov 2006 16:23:23 +0000

Comments I submitted during WGLC on version 10 have been fixed in version 11
with the exception of those points highlighted below.

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 23 June 2006 11:30
> To: 'Gonzalo Camarillo'; 'sipping'
> Cc: 'Samuli Pöykkö'; [email-masked]'; 'Alan 
> Johnston'; 'Robert Sparks'; [email-masked]'
> Subject: RE: WGLC of draft-ietf-sipping-service-examples-10.txt
> 
> 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."
[JRE] Still need to change "used and references" to "used and referenced".

> 
> 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.
[JRE] This has not been addressed. Any particular reason?

> 
> 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.
[JRE] My mistake, the comment referred to F6, not F1. So the comment has not
been addressed.

> 
> 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.
[JRE] This comment has not been addressed. Note that it now applies to F2
and F3 in section 2.17.

> 
> 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.
[JRE] Still not quite correct. Change "biloxi.com" to "biloxi.example.com".
This now applies to F6 in section 2.17.

> 
> 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.
[JRE] This has been fixed in a different way, which I don't understand. Why
would Bob's UA terminate the subscription to the dialog event package when
it sends the NOTIFY request F8? Bob's UA does not know for what purposes
Alice's UA has subscribed to this package. Note that if it is decided that
this is correct, we at least need to change "terminiated" to "terminated".

> 
> Section 2.18. It does not show Alice cancelling the 
> subscription - not essential but likely.
[JRE] As per my comment above, I don't believe Bob's UA is in a position to
know that the subscription has to be terminated when it sends a NOTIFY
request. Therefore I still believe Alice's UA needs to send a SUBSCRIBE to
cancel the subscription.

> 
> 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.
[JRE] This has not been addressed. Since the former F3 has now gone, we
can't copy the URI from there. Even though a dialog will not be formed for
the suscription, we still need the Contact header field in the request,
since support for no-refer-sub at Bob is not know at this stage. I would
propose <sips:[email-masked]>.

> 
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 3 Nov 2006 18:53:57 -0600

A general comment (version 11 also), when SIPS itself is debatable, why to put SIPS uri in the call flows.

Thx
Samir

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 8:23 AM
> To: sipping; Alan Johnston
> Cc: Gonzalo Camarillo; Barnes, Mary (RICH2:AR00)
> Subject: [Sipping] RE: RE: WGLC of draft-ietf-sipping-service-examples-
> 10.txt
>