Subject: [Sip] slides for bis open issues discussion

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 6 Aug 2001 22:17:44 -0400

Folks,

The slides I will be using tomorrow for the sip rfc2543bis open issues
discussion can be found at:

http://www.jdrosen.net/papers/sip_bis_open.ppt

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 08 Aug 2001 09:31:47 +0300

Hi,

Hopefully, when you read this mail all issues are solved, and the slides
aren't needed anymore... :)

Anyway, I do have a few comments, and I appologise that I weren't able
to post them before.

First, I didn't see any issue about the Record-Route, Outbound proxy,
and non-DNS UA issue. Did we solve that?

Second, I would like to know what people like about the idea of putting
the whole media handling, which I proposed earlier, in a separate draft.

Then, some comments on a few of the issues:

#11: Record-Routing non-INVITE mid-call

For this case I think it should also be clarified not only if we are
talking about non-routed mid-call requests, or if the proxy actually
REPLACES an existing route with another.

#71: RTT Estimation with Timestamp

My only question: Do we really need this on the application level? And,
if a UA wants to calculate the RTT, doesn't the time between sending the
request and receiving the response give a pretty good answer? Or, does
anyone really need, on the SIP level, to separate the time it took for
the request to reach the UAS and the time it took for the response to
reach the UAC?

#73: Responding to held SDP with held SDP

This is related to the issue how to put media on hold in the first place
(#133). Also, it depends on the "direction" of the call hold. For
example, if a UAC indicates a call hold with "a:inactive" I guess the
UAS can return a held SDP too (assuming it is able to put the call on
hold. But, if the UAC indicates it is only going to LISTEN to media, the
UAS can return the original SDP. And, if the UAC indicates it is only
going to SEND media, I guess the UAS can return the original SDP too.

Another approach would be to only send only the c= line and the
a:inactive (or whatever we will use) attribute, if we assume that the
call hold will not affect the codecs, ports etc used, and also assuming
that the whole session (ie all streams) will be put on hold.

#121: BYE/CANCEL Reason Phrases

A proposal is that this stuff could also be put in a separate draft
(compare to MEGACO). I am sure we going to come up with new codes in
future, and I don't think it's a good idea to write a separate extension
draft every time that happens (especially if there is no extension
feature attached). The only thing the bis then would have to specify is
the response code GROUPING, ie 1xx, 2xx, 3xx, 4xx, 5xx and 6xx.

#122: CANCEL on 200/600 stength

I would like to apply this also for BYE, because a proxy may receive
200, but it doesn't want to accept THAT branch. For example, it may have
received 18x responses from other branches, or for whatever
security/authentication reason the proxy does not allow the leg for
which it received 200 to be established.

#130: BYE v. CANCEL

This proposal I like very much :) However, even if we allow BYE w/tags
we should not remove the BYE without tags - no matter if the call is
established or not.

Regards,

Christer Holmberg
Ericsson Finland