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.
Am I doing something wrong? Is the application responsible for the
transmission of the ACK, since it is a new transaction?
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
