Subject: [Sipping] Comments on netan

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Mar 2003 14:04:21 +0300

Eric,

Here you have some comments on the netann draft:

http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-05.txt

Abstract: I would clarify in the abstract that the media server speaks
SIP as well. Reading it for the first time is not clear... maybe you can
clarify it in the Introduction as well.

Section 2: the draft says:

"For per-service security, the media server MAY use any of the
   security protocols described in RFC3261 [2].

   The media server MAY issue 401 challenges for authentication."

This two statements are a consequence of having the application server
and the media server speak SIP. Therefore, you should not introduce any
normative behaviour in the draft.

You may want to add a note without normative language saying what you
say in those two paragraphs, though.

The draft says:
"Per RFC3261 [2], the service indicator is case insensitive."

The user part of a SIP URI is case-sensitive; quoting RFC 3261, top of
page 154.

"o  Comparison of the userinfo of SIP and SIPS URIs is case-
         sensitive.  This includes userinfo containing passwords or
         formatted as telephone-subscribers.  Comparison of all other
         components of the URI is case-insensitive unless explicitly
         defined otherwise.
"

Why does the draft say that the service indicator is case-insensitive?

Section 3: In the second paragraph, I would say up front that in SIP,
this is called "early media". You refer to early media leter in the
draft, so this is a good place to explain what it is.

Further down in Section 3, the draft says:
"To support the
   appropriate paradigm, the media server issues a 100 TRYING response,
   followed immediately by a 183 SESSION PROGRESS response with SDP."

If you are sending a 183 "immediately", you do not need to send the 100
Trying.

The same comment at the bottom of page 9, where you also send a "100
TRYING followed by a 183 SESSION PROGRESS".

The last sentence of Section 3.2.1 says "the proxy then issues a
BYE...". I would say that the "proxy *proxies* the BYE to... 

Having a proxy "issue" a request makes it look like a B2BUA, right?

Section 3.3.2: 200 OK for the PRACK is missing.

Regarding the 409 vs. 487 reponses issue, I already sent a reply to your
mail saying that, if you follow the paradigm you propose, a 487 response
seems to be more appropriate. However, as I suggested in that note, I do
not like that paradigm. When a UAC send a request, it can fork to reach
the user at several locations (UASs). Any of those UASs will send back
status codes reflecting the status of the user (e.g., busy). However,
now you are sending this request to a media server that will send back a
response that has nothing to do with the status of that user. 

I believe that it would be more appropriate for the applications server
to behave as a B2BUA. That is, the SIP dialog with the UAC is not the
same as the SIP dialog with the media server. To me, this would be a
better way of implementing the a vertical interface you propose between
the application server and the media server.

Regards,

Gonzalo
_______________________________________________
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