Subject: [SIP] SIP List Thread Summary, 17-23 September

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 9 Dec 2000 22:46:36 -0500

Some discussion items below.

9/17/2000 Thread: a query..........  Rahul Pande had a query for which he
had received no answer on the confctrl list, on where to find documentation
for the grammar of IANA-registered SDP attributes and on the intent of the
sdplang attribute.  Jonathan answered his questions.  No action.

9/18/2000 Thread: words of 2543.  Farhan mused on the density of the
specification and called for more-easily-understood public-source
implementations and detailed textbooks on SIP implementation.  Action: ...

9/18/2000 Thread: H.323 international conference.  Advertising.  No action.

9/18/2000 Thread: Question concerning SIP/ISUP interworking.  Anna Simpson
asked why, in draft-camarillo-sip-isup-bcp-00.txt, release cause 31, normal
unspecified is mapped to the SIP response 404, Not found.  Gonzalo Camarillo
showed how that had been reached by a process of elimination, but suggested
that 480 Temporarily Unavailable might be better.  The context is a call
outgoing to the PSTN where the gateway has provide a response indicating
that the PSTN responded to the IAM with a Release.  Further discussion
indicated that this would happen under abnormal circumstances, particularly
where an exchange originating a tone or announcement timed out.  Action:
check to see if 404 changed to 480 in latest issue of the draft.

9/18/2000 Thread: Which Proxies should be stateful.  Anoop Tripathi
postulated a situation where a would-be stateless proxy has to communicate
with a proxy that insists on communicating over TCP.  He asked whether the
first proxy could stay stateless under these circumstances.  Hisham
Khartabil resolved the paradox by pointing out that all proxies must support
UDP.  Thus the first proxy could remain stateless, while the second proxy
could be stateful if it wanted, but could not enforce TCP.  Pathangi
Janardhanan muddied the waters by pointing out that proxies also had to
support TCP, so the first proxy could be forced to be transaction stateful
if some other proxy contacted it via TCP.  Jo Hornsby commented that the
cited text was inconsistent with recent discussion and suggested modified
text for 1.5.2 and A.1.  In a slight diversion, Ford Trueman asked when a
proxy should be stateful and when not and Jonathan described some of the
design considerations.  ACTION: establish whether Jo Hornsby's proposals
(message of 9/19/2000 9:33 am GMT) represent consensus and if so, update
2543bis.

9/18/2000 Thread: Do Requests using record-route always go over UDP.  Anoop
Tripathi asked whether requests using Record-Route must always pass over UDP
because there is no way to specify otherwise in the Record-Route.  Pathangi
Janardhanan pointed out that the UA can use whichever transport it wishes,
since the proxy is obligated to support both.  No action.

9/18/2000 Thread: draft-ietf-sip-cc-transfer-01.  Robert Sparks announced an
update of the draft and listed the major changes.
-  Cliff Harris observed that a note on the use of Accept-Contact to steer
the INVITE to the right party had not made it into the draft.
-  Subramania Sivaram asked if transfer could not be achieved more directly,
by the control introducing the other two parties to each other, rather than
via REFER.  Robert Sparks pointed out that this would direct media flows
properly, but leave the controller in the signalling realtionship.
Moreover, one of the exchanges would require delayed media specification (no
SDP in the INVITE, SDP in the ACK).
Action: none.  The note on use of Accept-Contact appears in transfer-02.

I accidentally captured the following thread while following through the
preceding one.  The issues raised may need further discussion.

8/22/2000 Thread: draft-ietf-sip-cc-transfer-00 comments and questions.
-  Brett Tate listed a number of open issues he felt the draft should
address, and proposed a Pending Invite indication to supplement the process.
Jonathan suggested that by leaving the REFER and the session within it is
sent unrelated, many of the interactions Brett was suggesting can be
avoided.
-  Brett responded by asking how the target of the INVITE knows how to
interpret the incoming call request, whether as call transfer, multiparty
call, or unrelated new call.  Jonathan suggested presenting the call to the
user to decide.  Rohan Mahy repeated Brett's question more succinctly.
Jonathan responded that the REPLACES functionality (one of the alternatives)
is complex and needs more work.  Moreover, it is up to the 2543bis draft to
describe what it means to receive a call from a different party but with the
same Call-Id as an existing call.
-  Rohan Mahy expressed disagreement with Jonathan's proposal that reuse of
Call-Id indicates new party to an existing call.  He was also concerned that
common Call-Id means common session description, something that won't
necessarily be true in these cases.  He suggested that there needed to be a
way to link multiple calls with multiple Call-Ids.
-  Tom Taylor reported that he had been designing call flows using REFER and
incorporating the assumption that if the target recognizes a matching
Call-Id, it should anticipate that the new call will replace an old one and
therefore not automatically give it busy treatment.  Rohan Mahy asked if the
assumption then was that the calls were mixed/joined in the interim.  Tom
responded that he put a branch on hold if necessary, to avoid the need for
mixing.
ACTION: resolve meaning of Call-Id reuse.  Agree on whether intent of INVITE
is left to the target user to resolve.

9/18/2000 Thread: A question on forwarding INVITES.  M. Ranganathan asked if
a proxy forwarding a request needed to have a registration from the next-hop
server.  He also asked if there was a perceived need and agreed method for
passing registration information between proxies.  Jonathan replied with
respect to the first question, that routing is a matter of local policy, and
registration was not a necessary condition.  On the second point, he didn't
think propagation of registrations was a good idea, both on grounds of
scalability and because of the implication that proxies might be bypassed
through use of the propagated infformation.  Ranga accepted these answers
and followed up with a question on routing procedure, to the effect that
routing would be more efficient if the originator talked to the location
server rather than leaving it to a proxy.  Jo Hornsby responded with
modifications to the suggested routing procedure based on the thought that
Ranga had unnecessarily separated the registration database from the
location server, but concluded with the thought that there are many ways to
set up routing.  Jonathan noted that routing procedures should take account
of which domain owns the namespace of the Request-URI, and also noted the
processing required if a Route header is present.  No action. 

9/18/2000 Thread: Overlap dialing in SIP.  Aseem Agarwal asked how
additional digits could be provided if an INVITE cannot be issued before the
initial one receives a final response.  He also wondered if a re-INVITE to
change session parameters is an exception to that rule.  Pathangi
Janardhanan referred him to draft-camarillo-sip-isup-bcp-00.txt for call
flows showing the correct handling of overlap dialling.  He confirmed that
in all cases re-INVITE can only be issued after the first INVITE transaction
is completed.
-  Tom Taylor questioned this, pointing out a need for redirection while
ringing is in progress in the blind call transfer case.  
No action on the original query.  Call transfer issue may be resolved
through discussion related to 8/22/2000 thread:
draft-ietf-sip-cc-transfer-00 comments and questions.

9/18/2000 Thread: register method and cseq.  Jean-Francois Mule noted a
discrepancy in the handling of CSeq in draft-ietf-sip-call-flows-01.txt,
where registration followed by keepalive is illustrated.  Jonathan agreed
that the illustrated call flow needed to be corrected.  ACTION: verify that
CSeq is corrected at indicated points in reissue of sip-call-flows.

9/18/2000 Thread: SIP conference.  Nishith Chudasama asked how the members
of a multiparty conference are made aware of each other in SIP.  Junyoung
Heo expressed the view that this is out of scope for SIP.  He described how
his own MCU-based implementation worked, based on dissemination of "o="
information from SDP.  He could see RTP doing the job in multicast
conferences.  No action.

9/19/2000 Thread: syntax clarifications in the bis-draft-02.  Ashok Roy
noted that the grammar allows Alert-Info, Call-Info, and Error-Info to have
no content and questioned this.  He also noted a section heading
duplication.  Henning responded that permitting empty headers promotes
robustness.  He had a fix for the duplicate section heading.  Ashok
questioned whether the permitted empty header policy should be made
consistent over all headers.  ACTION: verify editorial update in 2543bis-03.
Complete discussion on whether empty headers are allowed only for specific
headers or for all headers.

9/19/2000 Thread: Modify media during a call.  Francois-Xavier Guitton asked
whether it was possible to change codecs in mid-call.   Pathangi Janardhanan
Referred him to section B.5 for an example, and suggested that instead of
direct replacement in the single m= line there  should be a deletion in a
first m= line followed by a second m= line giving the new codec.  Jonathan
indicated that Francois-Xavier's original suggestion was acceptable, that in
general it was permissible to change anything but the medium in a given m=
line.  No action.

9/19/2000 Thread: Call-ID in Two-party Call example.  Stefan Runeson noted
an example in chapter 16.3 of 2543bis where the Call-Id changes from the
third response onward, and asked if this was correct behaviour.  Neil Deason
responded that the Call-Id should stay the same throughout the call.
Henning said he had fixed the typo.  ACTION: verify fix in next draft
release.

9/19/2000 Thread: clarification o 302 message content.  Commenting on
2543bis-01, Sunitha Kumar noted that section 7.3.3 talks (in the recursion
case) about the UAC adding a branch to a new request, keeping CSeq the same,
and wondered whether this was correct or an action reserved to proxies in
forking situations.  She also noted that the specification did not mandate
an increase of CSeq for a re-INVITE where all other fields are kept the
same, though this is shown in an example where no branch parameter is added.
The general question was one of consistent treatment.  Jonathan responded
that a proxy and a UA look the same to the outside world, so he saw no
reason to limit the UA's actions.  He agreed that the text should describe
the CSeq case Sunitha had noted.  Further, the procedures around the cited
example should be restricted to simplify things.  ACTION: someone to create
the necessary text.

9/19/2000 Thread: draft-ietf-sip-mib-01: Why no response counters per
method?  Brett Tate asked why this was the case.  Kevin Lingle responded
that this was partly oversight and partly a view that more aggregate
statistics are sufficient.  Brett suggested specific examples of why such
counters might be wanted.  ACTION: further discussion?

9/19/2000 Thread:  Methods in Allow header.  Billy Biggs asked about the
need to include ACK, CANCEL and BYE methods in the ALLOW header in minimal
implementations.  Jonathan responded that it didn't matter much in practice,
but to be consistent, all methods supported by the server should be listed.
No action.

9/20/2000 Thread: IPv6 addresses in SIP.  Pekka Pessi proposed that, looking
forward, IPv6 addresses should be allowed in any parameter, but that this
poses parsing problems.  He presented three possible solutions, including
redefinition of token.  Ashok Roy proposed a less problematic variation of
this last which would have the effect of restricting IPv6 addresses to
parameters, but Pekka felt this might be too restrictive.  ACTION: need to
close off this issue.

9/20/2000 Thread: A Clarification.  Prashant Murthy noted a discrepancy in
the classification of the Www-Authenticate and Authorization sub-headings
between the notes on Henning's SIP page and 2543bis-01.  Jonathan noted that
this raised the issue of challenge-response authentication of responses and
expressed his doubt that that was workable.  Response signing, on the other
hand, is important.  Brian Rosen saw a potential need for responder
challenge, but was willing to back if if it proved too difficult.  Jonathan
noted that the responder is already protected by the standard request
authentication procedure.  The problem is in thinking of a proxy challenging
the UAS for credentials for a response.  He suggested that a UAS signature
on the response is sufficient.  ACTION: assuming Jonathan's view is
consensus, follow through in 2543bis and the SIP page notes.

9/20/2000 Thread: question on receiving multiple invites.  Pathangi
Janardhanan asked if, when a UAS receives multiple INVITEs due to forking,
it should respond 200 OK to the second INVITE and add a branch parameter.
Jo Hornsby referred Jana to a link on Jonathan's SIP page which discusses
request merging, and expressed his preference for one of the alternatives
presented there which does not require the UAS to add a branch parameter.
Further discussion led to the suggestion that a text change is needed in
section 1.4.5.  Henning proposed new text.  ACTION: confirm new text in next
update of 2543bis.

9/20/2000 Thread: About via-receieved:  Bodgey asked whether every proxy is
responsible for checking the address in the top-most Via header field, and
how this could be done.  Kundan Singh indicated use of the appropriate
socket library call and possibly a DNS lookup.  Vijay  Gurbani provide more
details on the library calls and suggested that the procedure is so easy he
would expect pretty well every implementation to do it.

9/20/2000 Thread: Content-Disposition Header questions.  Sudipto Mukherjee
sought clarification on the use of the different possible values of the
disposition-type parameter in Content-Disposition.  Jonathan agreed with his
interpretation of the "alert" value for early media, but expressed some
confusion over the precise intent.  He noted a need for the "manyfolks"
resource draft to define its own value rather than use "session".  Henning
noted that he had had in mind that "alerting" meant that the body contained
the actual content to be played out, and "session" would cover the
alternative where the body contains a session description for the early
media.  He saw no need for a value to specifically indicate "early media",
since the 183 response code does that.  Sudipto wodered in the "manyfolks"
case whether the presence of "a=qos:" attributes in the body would be enough
to qualify "session", so that a new value is unnecessary.  Jonathan invoked
a general that something that affects SIP signalling should be carried in
SIP headers.  ACTION: Henning to clarify text for "alerting".  "Manyfolks"
has already provided a new value for its own use.

9/21/2000 Thread: Post-SRV Request-URI (was - [[SIP] A question about
Request-URI:]).  The earlier thread included a question on whether the
Request-URI should be changed following a SRV record lookup, to reflect the
outcome of the lookup.  Jo Hornsby maintained the original Request-URI
should in general be retained, because rewriting it could result in a fatal
loss of information.  Similarly, the entire Request-URI in a Route header is
copied without modification to reflect the results of a SRV lookup.
Jonathan concurred, stating that conceptually, SRV lookup follows URI
construction.  No action.

9/21/2000 Thread: Record-Route and port.  Jo Hornsby noted that in
constructing a Record-Route, 2543bis fails to mention that the entity's port
should be part of the information copied.  ACTION: update 2543bis.

9/21/2000 Thread: More problems with SRV.  James Undery reported an argument
to the effect that if SRV is not mandatory it is useless, specifically if
servers listen on a port other than 5060.  Henning responded that making SRV
mandatory might be acceptable, but few servers weill use a port different
from 5060 in practice.  James responded that the problem is with proxies,
particularly one adding itself to a route.  One of the potential problems is
when the same device supports multiple SIP servers such as an outbound proxy
and a specialized service proxy.  Hisham Khartabil suggested that the
address placed into a Record-Route includes exact location and port, so a
SRV lookup will be unnecessary.  Routing would use an ordinary A query.  Jo
Hornsby disagreed, maintaining that normal 1.4.2 procedures should be
followed.  He was concerned that only 12 out of 50+ implementations at the
last interop could do SRV, and suggested that for the next bakeoff each
implementation should have its own domain so this could be tested.  Igor
Slepchin addressed James Undery's concern about being able to reach the
right SIP server instance on a device by pointing out that mutiple SIP proxy
instances on a device, Record-Route, and load-sharing will not all happen
together, with the result that the proxies pointed to by SRV can all use
port 5060.  Apparently this closed the topic: no action.

9/22/2000 Thread: RE: [Test Bed Technical Forum:] Determining the length of
the  SIP message body.  Duke Snyder posed questions about how to determine
the length of the SIP message body in various cases, if Content-Length is
absent.  Jo Hornsby responded, beginning with the observation that 2543bis
has now made the Content-Length header mandatory.  Jonathan pointed out
that, contrary to the supposition in Duke's inquiry, RFC 2543 does not
mandate the use of Content-Length with TCP.  Instead, the message body
continues until the connection is closed.  No action.

Tom Taylor
+1 613 736 0961
[email-masked]