[SR-Users] Fwd: [RAI] SIPit 29 Summary

Klaus Darilion klaus.mailinglists at pernau.at
Fri Oct 28 16:47:28 CEST 2011


FYI

-------- Original Message --------
Subject: [RAI] SIPit 29 Summary
Date: Fri, 28 Oct 2011 09:40:51 +0200
From: Robert Sparks <rjsparks at nostrum.com>
To: rai at ietf.org

(also available at https://www.sipit.net/SIPit29_summary)


SIPit 29 was hosted by Etsi Plugtests in Monte Carlo, Monaco
the week of October 24-27, 2011.

There were 34 attendees from 17 companies visiting from 12 countries.
We had 25 distinct implementations.

The roles represented (some implementations act in more than one role)
  20 endpoints
   5 proxy/registrars

The b2buas attending this event were not attempting to appear to be proxies.

Implementations using each transport for SIP messages:
    UDP   92%
    TCP   96%
    TLS   88% (24% server-auth-only)
    SCTP   8%
    DTLS   0%

44% of the implementations present supported IPv6.

There were three RFC4474 Identity implementations present.

For DNS we had support for:
    Full RFC3263		: 76%
    SRV only		: 16%
    A records only	: 08%
    no DNS support	: 0%

Support for various items in the endpoints:
   75% replaces
   50% ice
   40% 5389stun
   35% turn
   25% sip/stun multiplexing
   30% gruu
   25% history-info (there were no implementations of 4244bis)
   20% outbound
   20% path
   20% diversion
   15% 3489stun
   10% join
    5% service-route
    0% sigcomp

Support for various items in the proxy/registrars:
  100% path
   80% sip/stun multiplexing
   60% gruu
   40% outbound
   40% diversion
   20% service-route
    0% history-info

The endpoints and b2buas implemented these methods:
  100% INVITE, CANCEL, ACK, BYE
   95% REFER
   95% NOTIFY
   80% REGISTER
   80% INFO
   75% OPTIONS
   75% UPDATE
   75% PRACK
   60% SUBSCRIBE
   35% MESSAGE
   30% PUBLISH

100% of the implementations sent RTP from the port advertised
      for reception (symmetric-rtp).
30%  of the implementations required the other party to use symmetric-rtp.

90% of the UAs present both sent RTCP and paid attention to RTCP they 
received.

80% of the endpoints present supported SRTP using sdes.
There were no dtls-srtp implementations at this SIPit.

35% of the endpoints supported multipart/MIME.
There were no implementations present with S/MIME support.

36% of the implementations present followed RFC6026 (corrections
     to the INVITE transaction)
36% followed RFC4320 (corrections to the non-INVITE transaction)

Not counting implementations that support events only for REFER:
   There were 3 SIP Event Server implementations
   There were 5 SIP Event Client implementations

These event packages were supported:
   Server   Client
     1        2        presence
     1        1        presence.winfo
     1        4        message-summary
     1        1        dialog
     1        1        reg
     1        1        conference
     1        1        xcap-diff
     0        2        kpml

These packages were supported with the eventlist extension:
   Server   Client
     0        1        presence

Two of the proxies present still rely only on max-forwards and
one that implemented 3261 loop detection.  There were two implementations
of fork-loop-fix, but no implementations of max-breadth.

Multiparty tests (Notes provided by several test participants, including
Eoin McLeod, Trond Andersen, Olle Johansson, and Adrian Georgescu)

** IPv6 Focused Tests

The first multiparty session of the event focused specifically on IPv6. 
We used
a basic forking scenario with endpoints registered with several proxies 
at the
bottom of the tree. We had a mix of single and dual-stack endpoints, many
supporting video.

None of the participant's code would put both v4 and v6 candidates into ICE.
Rather, it made assumptions about which candidates to use based on what was
happening with the SIP signaling. We ran tests using SRV configurations 
stating
that v6 should be tried first and v4 tried if the v6 failed (and a second
configuration that tested v4 first) to ensure that implementations would 
fail
forward and try both address families, with mixed results. We confirmed that
one UA configured to use IPv6 only was able to request and use an IPv4 turn
allocation and succeeded in making a call between an IPv4 UA and IPv6 ua.

Most UAs that supported dual-stack had a configuration to tell the 
application
to ignore any returned AAAAs due to issues encountered in deployments where
endpoints autoconfigured IPV6 that didn't actually work. We successfully 
tested
calls going though a mix of v4 and v6 hops (accruing Via and 
Route/Record-Route
headers with addresses in both families.

There was an instance of UA registering using sip-outbound (RFC5626) 
that used
IPv4 and IPv6 flows simultaneously.

We set up automated tests of using SRV records to indicate preference 
for IPv4
or IPv6. Two ipv4 only clients proved that they connect to a domain 
indicating
preference for IPv6.


** Forking

There are still UAs that do not sensibly handle multiple 200 OKs to
a forked INVITE.

When testing handling multiple 200 OKs on a simple two branch fork, we
encountered an interesting failure. As the proxy handled the 200 OK from 
branch
1, it sent a CANCEL to the other branch. The UA on branch 2 had already
responded with a 200 OK, so it responded to the CANCEL with a 200, but 
rather
than ignoring it, it decided to send a BYE on the dialog. This surprised the
calling UA which had chosen the 200 OK from branch 2 to keep, having already
sent a BYE to the dialog from branch 1. The better thing for the UA to have
done is ignore the CANCEL after replying to it.

** TLS

Most of the implementations at the event supported TLS, and all the 
multiparty
tests exercised it. One session focused on proper certificate 
verification.  We
tested a certificate at a server with several SAN URI fields, none of which
matched the URI used for the server, but a CN that did. Only one UA 
failed to
connect because of this, the rest of the UAs connected happily (or not 
at all,
but because of other issues). Most of the implementations were "before 5922"
code, which meant that there was a lot of checking of the Subject/CN.

** Identity

There were several SIP Identity implementations present. We tested 
creating and
verifying the Identity assertions at proxies. It wasn't immediately 
obvious to some
implementers that the resource pointed to by the  Identity-Info URI had 
to be DER
encoded (a result of the requirement to use application/pkix-cert). 
Unfortunately,
the tar encoded at the end of 4474 has .cer files in it that are PEM 
encoded.

** STUN/TURN/ICE and Outbound

We spent a significant fraction of the multiparty test time (three sessions)
focusing on STUN/TURN/ICE and Outbound.

There are still clients using RFC 3489 STUN.

The participants noted operator pushback against deploying ICE because when
things go wrong, it's very hard to diagnose when, where and why they went
wrong. If the endpoints always sent a reINVITE (or UPDATE) when 
concluding ICE,
even if they used the default candidates, this diagnosis of failures 
would be
much easier.

   Examples noted by the participants:

    * Without a mandatory conclusion, is not possible to know how long
      it took until end-points had successful media path established
    * Without a mandatory conclusion, is not always possible to know if
      different than default candidates have been chosen as lack of INVITE
      does not tell deterministically what happened
    * Without a mandatory conclusion, it is not possible for the callee
      to restart ICE if it does not agree with the conclusion

We successfully exercised endpoints setting up and managing multiple 
outbound
flows through separate edge proxies to a proxy/registrar (with different
implementations taking turns in the proxy registrar role). We forced the
network to break the flow in use in each case, verifying that subsequent
dialog-forming requests would take an alternate flow. We discovered an issue
with the recommendation in 5626 to have edge proxies record-route that 
prevents
subsequent in-dialog requests from using alternate flows.

** SRTP

All implementations supported SDES for SRTP key exchange.

Good interop with many different combinations of endpoints.

Some calls were left up for an extended period so that sequence number 
wrapping and roc increments were tested. Once the roc had changed the 
call was put on hold and resumed with success. In this situation new RTP 
streams with different SSRCs were created and the sequence number/roc 
combination re-generated thus proving that support for multiple SRTP 
contexts exists.

Debate surrounding how to signal 'best-effort crypto' continues. Some 
implementations choose to advertise RTP/AVP with a=crypto attributes and 
then go crypto if answer also has them and non-crypto if they do not. 
RTP/SAVP is used to signal the desire for mandatory crypto. Another 
approach observed was to repeat the same media line twice, once for 
crypto and once for non-crypto and rely on the receiving end to only 
accept one of them and port reject the other. In this case both m-lines 
had the same port number and payload number descriptions so if a 
receiving end accepted both then the originator would have no clue as to 
whether it was receiving crypto or non-crypto traffic.

** Unusual messages

We tried several kinds of valid, but unusual messages.
Very few implementations did the right thing with a request-URI with an 
unknown scheme - some phones would answer an INVITE with that in the 
request-URI.


** Specification questions / comments

RFC 3263 currently says "If no SRV records are found, the client SHOULD 
use TCP
for a SIPS URI" - it should probably say TLS over TCP.

In the spirit of Happy Eyeballs, there should be some guidance on what 
to do when
the RFC 3263 process results in both A and AAAA records and the client 
is capable
of using both.

There were implementations of SIP over DTLS, but the specification of 
that usage
seems not to have completed.

There were questions on whether internationalized domain names could be 
used in SIP URIs.

For use of SDP with ICE, there was an argument about whether a=rtcp was 
mandatory if rtcp
was on the next port up. RFC 5245 says "If the agent is utilizing RTCP, 
it MUST encode
    the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
    [RFC3605].", and 3605 says "when that port is not the next higher 
(odd) port number
    following the RTP port described in the media line" to motivate why 
the attribute was
created to begin with. Any updates to 5245 should clarify that adding 
the a=rtcp attribute
is not optional when RTCP is being sent on the next higher port.




_______________________________________________
RAI mailing list
RAI at ietf.org
https://www.ietf.org/mailman/listinfo/rai



More information about the sr-users mailing list