Subject: [SIP] SIP List Thread Summary, 10-16 September

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 7 Dec 2000 20:10:44 -0500

Phew!  One week down, two to go!

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.

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