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.