2009/1/12 Paulo Pizarro <paulo.piza...@gmail.com>
> I'm testing the items related to the establishment of the call and I find a
> problem with the item SIP_CC_OE_CE_V_019.
>
> "Ensure that the IUT when an INVITE client transaction is in the Calling
> state, on receipt of
> Success (200 OK) responses differing only on the tag in the To header,
> sends an ACK request with
> a To header identical to the received one for each received Success (200
> OK) responses."
>
> The NUTAG_AUTOACK tag is set, but the lower layer of the stack does not
> send an ACK for each received 200 OK response, only for the first.
>
> I'm doing something wrong? The application is responsible for the
> transmission of the ACK, since it is a new transaction?
>
When the transaction layer (NTA) receives the final response (200 OK), the
transaction ends. Then, the responsability for the ACK retransmissions is
the UAC core (NUA). NUA must be passed the ACK directly to the transport
layer and to retransmite for each 200 OK received during 64*T1 seconds. NUA
does it?
13.2.2.4 2xx Responses
...
"Once the ACK has been constructed, the procedures of [4] are used to
determine the destination address, port and transport. However, the
request is passed to the transport layer directly for transmission,
rather than a client transaction. This is because the UAC core
handles retransmissions of the ACK, not the transaction layer. The
ACK MUST be passed to the client transport every time a
retransmission of the 2xx final response that triggered the ACK
arrives.
The UAC core considers the INVITE transaction completed 64*T1 seconds
after the reception of the first 2xx response. At this point all the
early dialogs that have not transitioned to established dialogs are
terminated. Once the INVITE transaction is considered completed by
the UAC core, no more new 2xx responses are expected to arrive.
If, after acknowledging any 2xx response to an INVITE, the UAC does
not want to continue with that dialog, then the UAC MUST terminate
the dialog by sending a BYE request as described in Section 15."
>
> SOFIA ------------- INVITE -------------> SIPP
> SOFIA<------------- 200 OK ------------ SIPP
> SOFIA ---------------- ACK ------------> SIPP
> SOFIA<-------------- 200 OK ----------- SIPP
>
> Thanx, regards.
>
> Trace:
>
> 12/01,18:05:19.324860 nua: nh_create_handle: entering
> 12/01,18:05:19.324967 nua: nua_invite: entering
> 12/01,18:05:19.324982 nua(0x8077840): signal r_invite
> 12/01,18:05:19.325013 nua(0x8077840): signal r_invite
> 12/01,18:05:19.325035 nua: nua_stack_set_params: entering
> 12/01,18:05:19.325216 nta_leg_tcreate(0x80787a0)
> 12/01,18:05:19.325259 nua(0x8077840): adding session usage
> 12/01,18:05:19.325550 nta: selecting scheme sip
> 12/01,18:05:19.325735 send 778 bytes to udp/[192.168.170.83]:5060 at
> 20:05:19.325660:
> 12/01,18:05:19.325781
> ------------------------------------------------------------------------
> INVITE sip:2...@192.168.170.83 <sip%3a2...@192.168.170.83> SIP/2.0
> Via: SIP/2.0/UDP 192.168.166.190;rport;branch=z9hG4bKZ93vD6SvcyZDN
> Max-Forwards: 70
> From: <sip:2...@192.168.166.190 <sip%3a2...@192.168.166.190>
> >;tag=ZX3rv44c8jvZe
> To: <sip:2...@192.168.170.83 <sip%3a2...@192.168.170.83>>
> Call-ID: 2d80c83c-5b87-122c-b3bd-edd197edc28e
> CSeq: 109777023 INVITE
> Contact: <sip:2...@192.168.166.190 <sip%3a2...@192.168.166.190>
> ;transport=udp>
> User-Agent: sipdgt-2.0-sofia sofia-sip/1.12.8
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
> NOTIFY, REFER, UPDATE
> Supported: timer, 100rel
> Min-SE: 120
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 185
>
> v=0
> o=- 2824951011107875964 2072897739779921184 IN IP4 192.168.166.190
> s=-
> c=IN IP4 192.168.166.190
> t=0 0
> m=audio 4038 RTP/AVP 8 18 4 0
> a=fmtp:18 annexb=yes
> a=fmtp:4 annexa=yes
>
> ------------------------------------------------------------------------
> 12/01,18:05:19.325814 nta: sent INVITE (109777023) to */
> 192.168.170.83:5060
> 12/01,18:05:19.325829 nta: timer set to 32000 ms
> 12/01,18:05:19.325842 nta: timer shortened to 500 ms
> 12/01,18:05:19.325857 nua(0x8077840): call state changed: init -> calling,
> sent offer
> 12/01,18:05:19.325874 nua(0x8077840): event i_state INVITE sent
> 12/01,18:05:19.325916 nua: nua_application_event: entering
> 12/01,18:05:19.325925 nua_event_callback:nua_i_state status[0]
> 12/01,18:05:19.325937 app_i_state:status=0 phrase=INVITE sent state=calling
> l_sdp=0x807b434 r_sdp=(nil)
> 12/01,18:05:19.325947 main_event_handler:event=SIP_CALL_STATE (21)
> 12/01,18:05:19.325961 SIPDGT >>> CCVOIP: [CAC ID0 IN32768]
> 12/01,18:05:19.327112 recv 488 bytes from udp/[192.168.170.83]:5060 at
> 20:05:19.326987:
> 12/01,18:05:19.327150
> ------------------------------------------------------------------------
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.166.190;rport;branch=z9hG4bKZ93vD6SvcyZDN
> From: <sip:2...@192.168.166.190 <sip%3a2...@192.168.166.190>
> >;tag=ZX3rv44c8jvZe
> To: <sip:2...@192.168.170.83 <sip%3a2...@192.168.170.83>>;tag=1
> Call-ID: 2d80c83c-5b87-122c-b3bd-edd197edc28e
> CSeq: 109777023 INVITE
> Contact: <sip:192.168.170.83:5060;transport=UDP>
> Content-Type: application/sdp
> Content-Length: 139
>
> v=0
> o=user1 53655765 2353687637 IN IP4 192.168.170.83
> s=-
> c=IN IP4 192.168.170.83
> t=0 0
> m=audio 6000 RTP/AVP 8
>
> ------------------------------------------------------------------------
> 12/01,18:05:19.327164 nta: received 200 OK for INVITE (109777023)
> 12/01,18:05:19.327181 nta: 200 OK is going to a transaction
> 12/01,18:05:19.327200 nta_outgoing: RTT is 1.596 ms
> 12/01,18:05:19.327451 nua(0x8077840): INVITE: processed SDP answer in 200
> OK
> 12/01,18:05:19.327483 nua(0x8077840): event r_invite 200 OK
> 12/01,18:05:19.327550 nta: selecting scheme sip
> 12/01,18:05:19.327636 send 315 bytes to udp/[192.168.170.83]:5060 at
> 20:05:19.327604:
> 12/01,18:05:19.327675
> ------------------------------------------------------------------------
> ACK sip:192.168.170.83:5060;transport=UDP SIP/2.0
> Via: SIP/2.0/UDP 192.168.166.190;rport;branch=z9hG4bK0jXNF1a096N0g
> Max-Forwards: 70
> From: <sip:2...@192.168.166.190 <sip%3a2...@192.168.166.190>
> >;tag=ZX3rv44c8jvZe
> To: <sip:2...@192.168.170.83 <sip%3a2...@192.168.170.83>>;tag=1
> Call-ID: 2d80c83c-5b87-122c-b3bd-edd197edc28e
> CSeq: 109777023 ACK
> Content-Length: 0
>
>
> ------------------------------------------------------------------------
> 12/01,18:05:19.327688 nta: sent ACK (109777023) to UDP/192.168.170.83:5060
> 12/01,18:05:19.327704 nua(0x8077840): call state changed: calling -> ready,
> received answer
> 12/01,18:05:19.327726 nua(0x8077840): event i_state 200 OK
> 12/01,18:05:19.327743 nua(0x8077840): event i_active 200 Call active
> 12/01,18:05:19.327776 nua: nua_application_event: entering
> 12/01,18:05:19.327784 nua_event_callback:nua_r_invite status[200]
> 12/01,18:05:19.327792 app_r_invite: 200 OK
> 12/01,18:05:19.327800 main_event_handler:event=SIP_ANSWER (22)
> 12/01,18:05:19.327815 SIPDGT >>> CCVOIP: [CAT ID0]
> 12/01,18:05:19.327836 nua: nua_application_event: entering
> 12/01,18:05:19.327843 nua_event_callback:nua_i_state status[200]
> 12/01,18:05:19.327853 app_i_state:status=200 phrase=OK state=ready
> l_sdp=(nil) r_sdp=0x807ce54
> 12/01,18:05:19.327866 process_remote_sdp: IP[192.168.170.83] PORT[6000]
> PAYLOAD[8]
> 12/01,18:05:19.327873 main_event_handler:event=SIP_CALL_STATE (21)
> 12/01,18:05:19.327944 TCP(6) ENV: DESTINOS_PARA_AUDIO REQ:0 SESSAO:15
> DESTINOS:192.168.170.83:6000 CODEC:G711_PCMA TIMEOUT_SEM_RTP:60
> 12/01,18:05:19.327955 nua: nua_application_event: entering
> 12/01,18:05:19.327962 nua_event_callback:nua_i_active status[200]
> 12/01,18:05:19.328024 recv 488 bytes from udp/[192.168.170.83]:5060 at
> 20:05:19.327979:
> 12/01,18:05:19.328056
> ------------------------------------------------------------------------
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.166.190;rport;branch=z9hG4bKZ93vD6SvcyZDN
> From: <sip:2...@192.168.166.190 <sip%3a2...@192.168.166.190>
> >;tag=ZX3rv44c8jvZe
> To: <sip:2...@192.168.170.83 <sip%3a2...@192.168.170.83>>;tag=2
> Call-ID: 2d80c83c-5b87-122c-b3bd-edd197edc28e
> CSeq: 109777023 INVITE
> Contact: <sip:192.168.170.83:5060;transport=UDP>
> Content-Type: application/sdp
> Content-Length: 139
>
> v=0
> o=user1 53655765 2353687637 IN IP4 192.168.170.83
> s=-
> c=IN IP4 192.168.170.83
> t=0 0
> m=audio 6000 RTP/AVP 8
> a=rtpmap:8 PCMA/8000
>
> ------------------------------------------------------------------------
> 12/01,18:05:19.328066 nta: received 200 OK for INVITE (109777023)
> 12/01,18:05:19.328078 nta: 200 OK is going to a transaction
> 12/01,18:05:19.328088 nta: 200 OK was discarded
> 12/01,18:05:19.404676 TCP(6) REC: # DESTINOS_PARA_AUDIO sem CNG
> 12/01,18:05:19.404690 TCP(6) REC: # DESTINOS_PARA_AUDIO sem PTIME
> 12/01,18:05:19.844570 nta: timer set next to 31482 ms
>
>
> 2009/1/9 Pekka Pessi <ppe...@gmail.com>
>
> 2009/1/9 Paulo Pizarro <paulo.piza...@gmail.com>:
>> > 2009/1/8 Pekka Pessi <ppe...@gmail.com>
>> >> 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:
>> >
>> ....
>> > 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.
>>
>> Thanks, applied.
>>
>> >> > 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.
>>
>> Fine.
>>
>> >> > 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? :)
>>
>> Definitely. ;)
>>
>> --
>> Pekka.Pessi mail at nokia.com
>>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
