[Sipping] Comments to cc-conferencing-05 (WGLC)

[Miguel Garcia <[e-mail]>]

Alan, Orit (and SIPING):

I have some comments to draft-ietf-sipping-cc-conferencing-05.txt. They 
are mostly nits. I hope you can take them into account.

- Section 3.1 reads in the second paragraph:

    "A focus SHOULD support the conference package [5] and indicate so in
    Allow-Events header fields in requests and responses. "

    I guess that we also need to say that the focus should behave as a 
notifier. Support of the conference package is not enough. I suggest 
something like:

    "A focus SHOULD support the conference event package [5], behave as 
a notifier for that package, and indicate its support in the 
Allow-Events header fields in requests and responses."

- Section 3.1 also reads in the second paragraph:

    "A focus MAY
    include information about the conference in SDP message bodies sent."

It would be good, since this is a normative statement (MAY), to indicate 
what kind of "information about the conference" we are speaking. Just to 
avoid that people have creativity in the SDP with something that wasn't 
the original intention. Presumably we are referring to i=, e=, u= and p= 
lines in SDP.

- Also Section 3.1 reads in the third paragraph:

   "A focus SHOULD support the Replaces [8] header field."

At this stage, since the usage of the Replaces headers have not been 
introduced, it would be good to have some motivation introductory text, 
something like:

    "In order to support advanced features, where a session established 
between two endpoints can migrate to a centralized conference, a focus 
SHOULD support the Replaces [8] header field."

- And more on section 3.1:

I also think we need some text in this section regarding the support of 
the Join header and the GRUU in the focus.

- Question on section 3.4:

Should the conference-aware UA support the replaces, join and GRUU? I 
guess it should be strongly recommended to implement it (perhaps a MUST).

- Section 4, Call flows, General.

I think all the Supported headers should always contain: join, replaces, 
gruu. There are some of them that do not contain 'join',  others not 
even gruu.

- Section 4, Call flows, General.

Most of the escaped URIs that in Refer-To headers are wrong. These URIs 
contain the "method" parameter, which is a URI parameter, not a header. 
Parameters are separated by semicolons ";", whereas headers are 
separated by question marks "?". Therefore, the following URI:

  Refer-To: <sip:[e-mail]?method=REFER
               &Refer-To=sip:3402934234%40example.com>

is wrong, and should have been written as:

  Refer-To: <sip:[e-mail];method=REFER
               ?Refer-To=sip:3402934234%40example.com>

In case of doubt, RFC 3261 section 25.1 contains all the answers.

Suggestion: do a search for "method", and fix those which are not correct.

- Section 4, Call flows, General.

According to RFC 3264 Section 5, it is RECOMMENDED that the "s=" line in 
SDP contains a single space character (0x20) or a dash (-). The 
motivation is that SIP offers the Subject header field to describe the 
subject of a session. Therefore I recommend to follow RFC 3264 and make 
the "s=" line as recommended. It is up to you whether you want to 
include a Subject header field in the examples.

- Section 4, Call flows, General:

The Contact header field returned by the focus has the following structure:

       Contact: <sip:[e-mail]>;isfocus

while it is feasible to make "example.com" a hostname, and resolve to 
the focus, I found that in typical configurations "example.com" will be 
a domain name that does not resolve to any particular host. The contact 
header MUST resolve to the focus hostname.

I would find more typical that the Contact header has a clear indication 
that is host, for instance:

        Contact: <sip:[e-mail]>;isfocus

You can argue that focus.example.com could also be a domain name, not a 
host name, which is correct. But in typical network deployments my 
proposal adheres to the typical example case.

So my suggestion is to replace the Contact header field of the focus to 
something more representative of a hostname.

As a counterpart, the RTP mixer is identified by ms5.conf.example.com 
and Alice's Contact as client.chicago.example.com, which are both 
according to what I am proposing.

- Section 4.2

I think the payloads in NOTIFYes F7 and F9 are exchanged somehow.
Alice is already a participant of the conference, so her NOTIFY F9 can 
be contain a partial information. Carol's NOTIFY F7 is the first NOTIFY 
she receives, so it should contain a full event package.

However, F7 contains a <conference-state> with version="0" and 
state="full", when it should be version="1" (or other number) and 
state="partial".

F9 contains the correct version="0", but the state="partial", when it 
should be "full".

- Section 4.2, Changing User Agents within a Conference

This is an interested case, but certainly there is nothing peculiar to 
the conferencing. In other words, this will be applicable to the 
one-to-one session. So if there is something remarkable when we apply 
this case to the conferencing framework, please explain. Otherwise, I 
don't know what is the value of this use case.

- Section 4.7, flow F1.

What is the 'conf' tag doing in a Supported header?

- Section 4.10, Bringing a Point-to-Point Session into a Conference
The second paragraph reads:

    "Alice then sends a REFER to the focus and
    includes an escaped Replaces header field in the Refer-To header
    field. "

This could be clarified by adding:

    "Alice then sends a REFER request to the focus to send an INVITE
    request ot the other participant. Alice includes an escaped
    Replaces header field in the URI included in the Refer-To header
    field. "

I am not sure if this is clearer, but I guess you get the point.

- Section 4.10

In Figure 10 the 200 OK F2 misses the isfocus parameter, so it does the 
INVITE F8. I think these are important to highlight, otherwise there 
won't be subscriptions.

Also this figure misses a SUBSCRIBE/NOTIFY between Alice and the Focus, 
right after the ACK F3. Without this SUBSCRIBE, the NOTIFY F15 does not 
exist.

- Section 4.11

s/&ltsip:/<sip:

- Section 4.12:

In Figure 12 the arrow of message F4 is reversed.

- Section 4.13, Flow F2:

This is a 200 OK response for an OPTIONS request. So the SDP should be 
in conformance with RFC 3264 section 9. Specifically the port numbers in 
the "m=" lines should be set to 0.

Also in this SDP, I noticed that the "m=audio" line contains a codec of 
type 1, but this type is "reserved" in RFC 3551, so I would suggest to 
delete it.

- Section 4.13.

Add references to the relevant RFCs in:

    "Supported.  The support of extensions such as replaces, join, and
    gruu."

    "Contact.  The presence of the "isfocus" feature parameter in the
    Contact header indicates that the URI is a conference URI and that
    the UA is a focus."

- Section 5.

If this is an appendix, it should be placed towards the end of the 
document, after the Acknowledgments and before the References section.

- Section 14 needs a few updates

Reference [1] is never used, but it should. I guess you need to add 
somewhere the typical terminology explanation "MUST", "SHOULD", etc. and 
refer to RFC 2119.

Reference [5] is now -06

Reference [6] is now RFC 3911

Reference [7] is now RFC 3840

Reference [12] seems to be expired, so you should delete this reference 
and delete the link to it.

Reference [16] is never used, so you can delete it.

Reference [17] is now -03

Reference [18] seems to be expired, but I assume this has been an error.





Best regards,

        Miguel


-- 
Miguel A. Garcia           tel:[phone]
Nokia Research Center      Helsinki, Finland

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