9/11/2000 Thread: Keep-Alive mechanism : REGISTER. Jacqueline Blanchard asked how a UA can indicate to its proxy that it is still alive. Jonathan agreed with her that Sending a periodic REGISTER is the appropriate mechanism. No action.
9/11/2000 Thread: How to compare hosts for equality? M. Raganathan noted that in some headers either a host name or a host address can be presented. Where the name is used, DNS lookup can give multiple addresses, making it hard for a server to determine a match. He wondered if it was up to the client to be consistent in its use of name or address to make it easier for the server. Gethin Liddell pointed him to section 2.1 on SIP URL comparison. No action.
9/11/2000 Thread: A doubt on registeration ? Pathangi Janardhanan noted that the bis draft says that if registration information changes during the course of processing of an invitation, the new information should be used. He wondered how a proxy receives the new information. Jo Hornsby confirmed that it would be through an implementation-dependent interface, and noted that the interface to the Location Server is not well defined in any event. No action.
9/11/2000 Thread: Content Length Question. Bobby Sardana wanted to know the reference for the grammar of Content-Length, and particularly what the three dots imply (i.e. "Content-Length: ..."). Peter Kjellerstedt surmised Bobby's syntax was taken from an example in 2543bis, and the dots stand for normal content (i.e. the correct character count for the body) which would be placed here in practice. Gethin Liddell confirmed this view. No action.
9/12/2000 Thread: SIP syntax in 2543-bis-01. Gérard GONNET noted that new ABNF for <userinfo> in 2543bis allows a production like <sip::a_password@hostport url-parameters [headers]>, which ddin't seem right. He proposed adjustments to the ABNF to ensure that if password is present, it is preceded by <user> or <telephone-subscriber>. Jonathan concurred that the existing grammar seemed wrong, and Henning announced a fix by moving the optionality bracket to make it like similar URLs in RFC 1738. The fix does NOT appear in 2543bis-02. ACTION: Henning.
9/12/2000 Thread: DNS SRV records in stateless mode.
- Igor Slepchin suggested that the use of DNS SRV records
in stateless mode has some potential problems. The standard algorithm in
section 1.4.2 and RFC 2782 could cause retransmissions to go to different places
-- an awkward but not fatal possibility. He suggested a
"first-success" algorithm, where hosts are slected in decreasing order
of priority until one succeeds. He noted that a UDP record will always
terminate the search, since ICMP errors cannot be detected in stateless mode.
Another possibility is to use only A records in stateless mode, but this also
has problems.
- James Undery suggested that the real issue is not transport, but choosing amongst hosts of equal priority. Doing this randomly causes misrouting at the SIP level, while doing it deterministically breaks the intent of SRV. He feels the RFC should be less positive in general about how the proxy does routing, since the proxy may have better information to act upon.
- Gethin Liddell pointed out that a stateless proxy can only use UDP, and that sending retransmissions to different hosts could have nasty effects like double-billing of the subscriber. He proposed a procedure where the proxy begins with SRV, moves on to an A record, then does nothing, noting that there was recent discussion on returning final responses in stateless mode.
- Igor Slepchin noted in response to James Undery that the proxy is free to choose its own routing methods, but if it chooses SRV it is reasonable to say that it SHOULD use the recommended algorithm. He also suggested a compromise whereby the selection between equal-priority servers be deterministic for a given proxy, but random across different proxies, so as to preserve some of the load-balancing effects of the SRV record.
- Henning reaffirmed that random selection amongst the highest-priority servers should be used, and this was particularly important to provide failover handling. It is possible in some implementations to detect UDP failures and/or to ensure that retransmissions go to the same host as the original message. Additionally, the receiving domain has to accept the consequences of listing multiple hosts at the same priority. He felt that Igor's suggested compromise was unworkable.
- Jonathan stated that strict randomization makes load balancing through use of multiple SRV records too expensive. The implication is forced back-end state sharing even in normal operation, not just for failover. He thought it reasonable to define the SRV contract as applicable to an entire transaction, and proposed that the random selector be based on a hash of those elements making up the transaction identifier.
- Henning wasn't sure the consequences of pure randomization were as rigorous as Jonathan implied. He suggested if the compromise approach is taken, a random selector based on a hash of the Call-Id would be suitable. However, he was concerned that downstream proxies relying on proper upstream behaviour might be vulnerable in the event of misbehaviour.
- Jonathan said his concern wasn't billing, but the extra messaging and confusion that would result from retransmissions taking different routes. He suggested that his transaction identifer hash would come closer than a Call-Id hash to achieving the load balancing intended by SRV, achieves the desired effect of preventing unintended forks, and is therefore preferable.
- Henning announced new text on SRV usage added to section 1.4.2. This text allows route selection at either at the call or the transaction level. Jonathan agreed with it, with a minor adjustment. This text now appears in 2543bis-02.
- Brian Stucker expressed concerns that the hash used by some implementations could provide inadequate randomization. Moreover, if the proxy detects failure and rechooses the downstream server, but the originator also reoriginates the message, the stateless proxy may blindly apply the selection algorithm and thus offer the reoriginated message to the failed server again. He suggested implementation notes to alleviate these two concerns.
- Howard Hart worried that Brian's second procedural fix would mess up load balancing. Brian couldn't see that, and suggested that his fix was consistent with the procedure given in RFC 2782.
No further action.
9/12/2000 Thread: Handle'n of NOT A KNOWN SIP Header Messages. Krishan Veer wanted confirmation of how a proxy should handle messages containing unknown header types but otherwise valid grammar. He understood that they should be forwarded, but wondered whether there were any restrictions to that rule. Kevin Summers clarified the question, then cited the relevant text in section 6 of 2534bis.
9/13/2000 Thread: SIP meetings. Joshua Fox wanted to know where to find out about upcoming meetings on SIP. Neal Deason gave a few home pages he could check out for meeting announcements. No action.
9/13/2000 Thread: Sip Call Control Transfer. Amit Choksi had some questions on the grammar of the URL in the Refer-To and Referred-By headers. No response was posted to the list. The cc-transfer-02 draft says that Referred-By must contain a SIP URL, but says nothing about the Refer-To header. ACTION: Robert Sparks.
9/14/2000 Thread: A warning to implementors. Jonathan Rosenberg expressed his concern that implementors not impose arbitrary limits on the length of specific SIP fields, saying that those who do so are non-compliant to RFC 2543. Eric Burger suggested this was inconsistent with the need to respect MTU size limits, and proposed a limit of 1000 characters in any one header. He noted that the Response-Key: or Authorization: fields are potential problem areas. Jonathan said some messages are already exceeding MTU size, and implementations should not reject them just because of that. He understood the value of fixed memory allocations for embedded applications, but the problem remains how to specify a large enough header length. Length problems actually come in fields like Via and Record-Route because data gets stacked there. Henning backed up Jonathan and noted that allocating large fixed-length areas leads to wasted space in normal operation and vulnerability to attacks. Arjun Roychowdhury agreed that storage allocation should be dynamic, although it would be reasonable to pose limits on total output message length. Cliff Harris noted a content-length example of 3495 in 2543bis. Arjun clarified that the 4000 byte figure in his note was just an example, and the actual limit is very implementation specific. No action.
9/14/2000 Thread: creation of the SIP WG. Tin DAO TRUNG asked when the SIP WG was created. Jonathan gave a full answer. No action.
9/14/2000 Thread: Outbound call routing.
- Simon Barber triggered a lengthy thread by asking whether
a registration server could respond to a registration request by forcing all
future outbound requests to be routed through a specific proxy. He cited a
call logging application.
- Jonathan said his proposal was not possible, and that similar requirements for mobile services had come up with the proposal to add a Route header to the request. This is a hack, not necessarily interoperable, since the Route header in this case is not derived from a previous Record-Route.
- Simon pointed out that his problem was user mobility, not client mobility, and the routing needed to be tied to the registration rather than the call leg. Jonathan agreed with the requirement and stated it as the need to be able to work through one's normal registrar/proxy while moving about. This collides with the insistence of some domains that messaging pass through their dedicated proxy server.
- Subsequent discussion covered a lot of ground, but resolved itself into two themes. The first had to do with the mechanism which might be used to force requests through the home outbound proxy, no matter which domain the user was visiting. The proposed solution was to include a Route header in an initial request. Jonathan eventually viewed this as a consensus proposal. The header should appear on its own, not as a parameter appended to the Request-URI -- otherwise it would be ignored by existing proxies. The UAC inserts the home outbound server in the route just before the final destination. Jo Hornsby noted a problem where signalling had to end up at a UA on a specific port, but Jonathan suggested a solution taking account of the fact that a new procedure was being defined in any event.
- The other theme was how the client in the visited domain acquires the user's preferences and the address of the home outbound proxy that it is to insert into the Route header. Simon and Arnoud van Wijk appeared to agree on a double registration procedure to retrieve the user preferences on top of the local domain settings. At one point in the thread there was talk of a new "sipoutbound" SRV record if the home outbound proxy would be the same for all users in a domain.
- Summing up, it appears that the basic question of mechanism has been resolved. ACTION: someone to formulate suitable text and Henning to add it to 2543bis. There may be practical issues of client implementation to allow roaming users to use the mechanism.
9/14/2000 Thread: SIP-related VON (and IPTS) presentations.
Henning asked people to send him URLs to such presentations so he could add them
to his web page.
9/14/2000 Thread: Via header and case sensitivity. Itamar Gilad questioned the validity of one of the torture test cases. He also asked what default behaviour for header comparison is, now that text on the subject has been removed from 2543bis. Henning replied that Itamar's point was correct and he had fixed the example. He cited new text on case sensitivity in section 6.5 of 2543bis-02. Itamar observed that he had misunderstood the new text because it used the word "parameter". No further action?
9/14/2000 Thread: INVITE with new SDP /higher CSeq. Eshwara Prasad wanted to know how the UAC learns that a request it sent with higher CSeq and new SDP was successful. Jonathan indicated that the new INVITE would follow the normal request/response/ACK sequence, so the UAC would know from the nature of the response. No action.
9/15/2000 Thread: Question on IMPP. Anuraj Ennai asked what would happen to the proposed SIP extensions for IMPP, now that they may not be adopted by the IMPP group. He saw a benefit to retaining the framework and extensions in SIP. Christian Huitema noted that SIP is one of three proposals now before the IMPP WG, but that WG is currently preparing a common reference document rather than selecting a specific protocol. A good way to further the chances of SIP would be to embed SUBSCRIBE/NOTIFY in products and demonstrate interoperability. Bobby Sardana expressed strong support for SIP, and mentioned that they had implemented a SIP-based stack for this function in just 6000 bytes. No action.
9/15/2000 Thread: SIP message transport on TCP. Aseem Agarwal asked whether there was any application-level framing mechanism (cf RFC 1006) for SIP messages in a TCP stream. Henning said the framing is as given 2543 and is almost the same as that used by HTTP servers.
9/16/2000 Thread: a question on 183. Pathangi N Janardhanan asked why SDP is needed in the 183 Early Media response, given that the early media will be one-way toward the caller and the caller's SDP has been passed in the INVITE. Jonathan responded that the SDP in the 183 confirms what the caller sent, provides an RTCP port for feedback, and indicates whether the early media will be one-way. No action.