[SIP] summary for the week of Nov 12-18

Rohan Mahy <rohan@cisco.com> Mon, 11 December 2000 18:55 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21716 for <sip-archive@odin.ietf.org>; Mon, 11 Dec 2000 13:55:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE20F44337; Mon, 11 Dec 2000 12:55:11 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3816944336 for <sip@lists.bell-labs.com>; Mon, 11 Dec 2000 12:54:25 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA20643; Mon, 11 Dec 2000 10:54:13 -0800 (PST)
Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAC82607; Mon, 11 Dec 2000 10:51:00 -0800 (PST)
Message-Id: <4.1.20001210153934.00cce8e0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
To: rohan@cisco.com, dean.willis@softarmor.com
From: Rohan Mahy <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_268694628==_.ALT"
Subject: [SIP] summary for the week of Nov 12-18
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Dec 2000 10:52:37 -0800

        Announcements
-  Jonathan Rosenberg announced the SIMPLE BOF
-  Many IDs where announced: dns-gl, sip-app-components, sip-deaf-req,
sip-peer-3pcc, sip-189, sip-replaces, sip-t38callflows
-  Henning said 'Please do not include numeric citations, such as "SIP [1] ..."
in abstracts'
- Steve Donovan announced dynamicsoft's test message service.
- last call on ISUP MIME type

        Threads
- a short thread on the use of Call-IDs devolved into a discussion on its use
for distributed conferencing, and the deprecation of Also.

- Threads on torture tests: consensus was to fix text for test7, deprecate
test10.  many commented on Neil Deason's proposed new tests.  Consensus was to
be liberal in what you recieve; several of the proposed torture cases can cause
the example error or be handled despite the error. Neil agreed to modify the
example of escaping inside the Request-URI. Anders suggested additional tests
for brackets and parameters in Contact headers. Anders and Hisham Khartabi
commented that according to the bis draft, semicolon-delimited parameters not
included in brackets (< and >) are header-parameters as opposed to URL
parameters. Finally, Ashok Roy suggested adding an IPv6 ;maddr parameter to a
torture test.

- In the thread "What am I doing wrong?", someone was having problems with a
UAC receiving a 180 from a first branch then a 180 and 200 from a second
branch.  Consensus was to add a torture test for properly handling tags from
forked calls.

- Henning proposed also using the Alert-Info header as a response header,
instead of implementing Adam Roach's ringback draft

- Another thread on ringback tone devolved into a discussion on 180 w/ early
media vs. 183.  
Robert Sparks summarized the thread consensus best "if a PSTN gateway knows
that the callee is being alerted then it should send a 180 with (or without)
SDP. Otherwise, if the PSTN gateway only knows that inband call progress tones
are being provided by the PSTN network (but not the callee alerting state) then
... 183 is more appropriate."

- M Ranganthan replied to a query for availability of SIP grammars, that an
antlr (grammar for java) version would be available shortly. 

- 11/15-11/17 "Jain SIP - Issues": Chris Harris asked a) what kind of exception
an implementation of JAIN SIP should throw if it doesn't like one of the header
values, and b) should an implementation automatically respond to un-parsable
messages, or pass them up to the application.  An default class/subclass
approach was suggested with some lazy-parsing.  Chris also asked if overriding
equals() is desireable.

11/13-11/17 "Identification Problem"/"Record-Route" : Jo Hornsby started a
thread proposing adding an "original-uri" parameter to carry the parameters
from the original URI lost when rewriting the Request URI for Record Route
processing. Bertil Engelholm proposed a non-backwards compatible change to
Route (that it should act like Via). Billy Biggs enumerated ways in which a
proxy would build the Record-Route, and proposed that RR reflect the next hop
in Route as opposed to the final destination. Sean Olson proposed using both an
maddr and raddr parameter, and claimed there was no clean way to fix RR and
provide backwards compatibility.

11/13-11/14 "SIP End-2-End Security" Tom Tang asked how to do end to end. 
Michael Thomas clarified some properties of end2end vs. hopwise encryption.
11/13 "Gateway and Redirect Number": Pete Kazimier asked how to translate Q.931
redirected number into SIP.  Brian Gracely provided a pointer to the diversion
draft. Hisham Khartabi provided a pointer to a directory of telephony-related
drafts on the main SIP site.

- 11/13 "Possilbe REFER problem": Robert Sparks and Billy Biggs had a spirited
discussion about using Contact as the Request-URI in the Refer-To URI.  Robert
noted that the Contact may be in a private name space and hence unreachable by
the UA that receives the REFER; Billy noted that the well known name may be
unavailable in some cases; Robert suggested using the Contact, then using
caller preferences (Accept-Contact=<contact>) if the previous REFER failed;
Billy noted that the previous REFER may fail for reasons other than an invalid
Contact address.

- 11/16-11/18 "ID extension of REFER": Rohan Mahy announced an draft extension
to REFER.  Venkatesh commented on some potential uses for the ongoing status of
a REFER.  Sean Olson asked if the draft causes different timing/attempts to
solve the retransmission problem (it does not).  Sean asked why 183 was not
used, Venkatesh asked why the provisionals aren't simply forwarded.

- 11/14 "From header to ISUP"/"Redirect server returning new From": These two
threads disucssed the mertis of Reply-To and Also-From headers.  

        Rehashes
- 11/14 "Session-time with INFO"  Christer Holmberg flogged a dead horse
proposing a new "lite" session timer-like mechanism which uses INFO.

- the "why does INVITE use a 3-way handshake?" question. Billy Biggs, Jonathan
Rosenberg, and Henning mentioned forking, reliability, and speedy message
delivery.  Billy Biggs mentioned that retransmissions are problematic for REFER
(because the REFER can be outstanding for more than 32 seconds). Billy also
stated that forking is problematic for SUBSCRIBE and MESSAGE, with which
Jonathan disagreed.

- 11/14 "SIP-H.323 INVITE w/ no media": Michel Maddux asked about using INVITEs
with no media for SIP to H.323 calls. Vladislav Zubarev provided a pointer to
and quotes from
<http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt>http://
search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt and the bis
draft to
answer the question.

- 11/13-11/14 "Redirect vs Proxy Server": David Schmidlin asked when to use a
redirect vs. proxy role. Billy Biggs and Jonathan Rosenberg replied on ease of
coding, data hiding, and control of the two roles.

11/17 "SDP coder negotiation": Duke Snyder asked about the behavior of codec
negotiation. Billy Biggs and Simon Barber replied with the correct behavior.
Simon asked for a survey of implementations of many of the implied SDP
behaviors.

        Questions without replies, potentially needing disabiguation.
- contiguous CSeq: bis 6.20 says CSeq number must be contiguous.  (insert
"within a transaction")
- what is the "MD5-sess" algorithm in Digest authentication? (clarify
reference)
- can I include both "proxy" and "redirect" in Request-Disposition? (no)
- does CANCEL of a REFER, cancel the referred INVITE? (yes)