2009/1/8 Pekka Pessi <ppe...@gmail.com>
> 2009/1/8 Paulo Pizarro <paulo.piza...@gmail.com>:
> > There is a specification for conformance test of RFC 3261 defined by ETSI
> > (www.etsi.org): ETSI TS 102 027-2 V4.1.1 Conformance Test Specification
> for
> > SIP (IETF RFC 3261)
> >
> > I started a job to validate the sofia in accordance with this
> specification.
> > And while I tested only the mandatory items that refer to the REGISTER of
> > the UA.
>
> Whee. C00l.
>
> ...
> > The SIP_RG_RT_TI_005 item has not passed the test, but the RFC 3261 does
> not
> > define clearly whether the first timer E in the state "proceeding" must
> be
> > T1 as ETSI demands.
> >
> > ETSI:
> >
> > TPId: SIP_RG_RT _TI_005
> > Status: Mandatory
> > Ref: RFC 3261 [1] annex A and section 17.1.3.
> > Purpose: Ensure that the IUT, when a REGISTER client transaction is in
> the
> > Proceeding state, repeats its
> > REGISTER request after timer E set to T1 value expires.
>
> If I understand correctly, the problem is because spec does not
> specify whether the timer E is restarted (with T2) when entering the
> "proceeding" state or if it continues running with T1. NTA takes first
> approach and ETSI spec second? This is pretty irrelevant, a RFC4320
> compliant server will send a preliminary response only after the
> client's timer E value has grown to T2. Looking from the code, it is
> possible just to remove the call to outgoing_set_timer() (around line
> 9038 in nta.c).
The RFC4321 (Problems Identified Associated with the SIP' Non-INVITE
Transaction) explains the problem:
1.2. Provisional responses can delay recovery from lost final responses
The non-INVITE client transaction state machine provides reliability
for NITs over unreliable transports (UDP) through retransmission of
the request message. Timer E is set to T1 when a request is
initially transmitted. As long as the machine remains in the Trying
state, each time Timer E fires, it will be reset to twice its
previous value (capping at T2) and the request is retransmitted.
If the non-INVITE client transaction state machine sees a provisional
response, it transitions to the Proceeding state, where
retransmission continues, but the algorithm for resetting Timer E is
simply to use T2 instead of doubling at each firing. *(Note that
Timer E is not altered during the transition to Proceeding.)*
*Making the transition to the Proceeding state before Timer E is reset
to T2 can cause recovery from a lost final response to take extra
time.* Figure 2 shows recovery from a lost final response with and
without a provisional message during this window. Recovery occurs
within 2*T1 in the case without the provisional. With the
provisional, recovery is delayed until T2, which by default is 8*T1.
The patch attached, not altered the timer E during the transition to
"Proceeding" state,
and when it fires again, the timer E is reset to T2.
Now, the test is ok.
> > The SIP_MG_RT_I_003 item also has no passed the test. The response
> received
> > was rejected by sofia.
> >
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 192.168.166.190;rport;branch=
> > z9hG4bKKZHN0XU3S8Kam
> > From: <sip:2...@192.168.170.101 <sip%3a2...@192.168.170.101>
> >;tag=K778U1FKv37HN?patito=legal
> > To: <sip:2...@192.168.170.101 <sip%3a2...@192.168.170.101>
> >;tag=1?patito=legal
> > Call-ID: b4468663-5820-122c-b39d-f14e001466ff
> > CSeq: 109590090 REGISTER
> > Contact: <sip:192.168.170.101:5060;transport=UDP>
> > Content-Type: application/sdp
> > Content-Length: 0
> >
> > TPId: SIP_MG_RT_I_003
> > Status: Mandatory
> > Ref: RFC 3261 [1] section 19.1.1.
> > Purpose: Ensure that the IUT, having sent a REGISTER request, on receipt
> of
> > a Success (200 OK) response
> > with an URI including a header parameter in the To and From
> headers
> > ignores them and considers
> > to have received a Success (200 OK).
>
> The response fails syntax check. Based on the test description the
> tester should send something like this:
>
> From: <sip:2...@192.168.170.101?patito=legal>;tag=K778U1FKv37HN
> To: <sip:2...@192.168.170.101?patito=legal>;tag=1
>
I confused header parameter of the URI with parameter of the FROM/TO
header... much beer last nigth :(
I fixed the test and now, it's ok.
>
> > As soon as I finish testing the items related to the establishment of the
> > call to send the list.
>
I still testing...
>
>
> Do we get some kind of official stamp of approval for Sofia then? ;)
You know, that's impossible to give an official certification stamp for a
software library.
I can give you one signed by me... Do you think it is worth something? :)
Thankx.
>
> --
> Pekka.Pessi mail at nokia.com
>
Index: /libsofia-sip-ua/nta/nta.c
===================================================================
--- /libsofia-sip-ua/nta/nta.c
+++ /libsofia-sip-ua/nta/nta.c
@@ -9032,7 +9032,10 @@
* retransmissions continue for unreliable transports,
* but at an interval of T2
- */
+ * @RFC4321 1.2:
+ * Note that Timer E is not altered during the transition
+ * to Proceeding
+ */
if (!orq->orq_reliable)
- outgoing_set_timer(orq, sa->sa_t2);
+ orq->orq_interval = sa->sa_t2;
}
else if (!outgoing_complete(orq)) {
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
