Hi,
If we want our SIP entity be protocol complaint, it should work as that
way. As I said, you can give solution. That would be your proprieted way
which will be nice. My point was, since we have documented standard, why
we don't follow it? That's true that there will be lots of SIP
end-point that will mis-behave. If every SIP implementer follows
specified standard, we won't face any such situation. The scenario one
you have mentioned seems error condition. Moreover, it opens security
hole. Here your UAS is certainly expecting PRACK. Say, meanwhile your
UAS is expecting PRACK, a third entity has duplicated the initial INVITE
and send 200 OK to UAC and it accepted 200 OK. Now third party and your
UAC will be communicating (I mean established a session at least). Your
actual intend was to communicate with UAS, not third one.
If anything is not complaint or behaving as specified in rfc, those
are their own way of doing that task to suite their needs. Its a right.
Isn't it?
Resending of PRACK is not ruled out in rfc3262 for same reliable
response. It says that if you receive multiple reliable response for
single INVITE, you should not send PRACK for each of those reliable
responses. Right? As PRACK should follow transaction rule, it doesn't
rule out re-sending either.
If, somehow, PRACK was dropped on network, it should succeed in
next attempts. If those attempts also didn't succeed there is a problem
with your network in wich case your UAC won't reach UAS as well. If UAC
was able to reach UAS during INVITE and UAC was able to receive 200 OK
from UAS, PRACK must also be delivered to UAS provided your UAC has
constructed the PRACK request corectly and addressed it to UAS properly.
In your case, you know that UAC is behaving incorrectly or not rfc
complaint. I guess you can correct it instead of correcting another way
around.
Please don't take me wrong. Its there in standard so my thought was.
Best regards
Nabam Serbang
________________________________
From: Arunachala [mailto:[email protected]]
Sent: Wednesday, December 17, 2008 5:26 PM
To: Serbang, Nabam (Nabam)
Cc: Rockson Li (zhengyli); [email protected]
Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK
isnotrespondedwith 2xx
Who said anything about changing the protocol?
In both the scenarios if UAC is sending PRACK means UAS sent a 'reliable
1xx response'. And hence UAS should be expecting PRACK and should send a
'200' for the PRACK. Since it is NOT responding to the PRACK, but
responding to UAS, it is clearly NOT behaving as per RFC3262, Section 3.
Or if UAC is incorrectly formating the PRACK request which UAS which
drops. In this case, UAC is NOT behaving as per RFC and is misbehaving.
So, if we assume both UAC and UAS are RFC (3261 and 3262) compliant,
then these scenarios won't occur at all, if we assume network is NOT
dropping ONLY PRACK requests.
Note that many a times you can't correct the mis-behaving UA. It can be
a remote SIP peer from some other vendor, with which your SIP entity has
to interact.
-Arun
On Wed, Dec 17, 2008 at 2:44 AM, Serbang, Nabam (Nabam)
<[email protected]> wrote:
Wow.......thats intersting. I guess you need to correct the
mis-behaving UA. It would be mistake to change protocol just for one/few
mis-behaving UA. What if that UA starts working rfc complaint. You will
be in double trouble, i feel. Anyway, the solution lies how much you
love that mis-behaving UA :-)
Thanks and regards
Nabam Serbang
________________________________
From: Arunachala [mailto:[email protected]]
Sent: Wednesday, December 17, 2008 4:07 PM
To: Serbang, Nabam (Nabam)
Cc: Rockson Li (zhengyli);
[email protected]
Subject: Re: [Sip-implementors] INVITE Behaviour When PRACK
isnotrespondedwith 2xx
Hi,
In the scenario described, one of the UA is mis-behaving. If
both UA's act according to RFC3262, and we assume PRACK packet is NOT
getting lost in the network, these scenario will never occur.
If UAS was RFC compliant, it would have NEVER sent the 200 OK
for the INVITE, if there was a OFFER in the reliable 1xx response that
UAS sent.
So, what we are trying to do here is to find a workable
solution for misbehaving UAs.
Also, for scenario 2, if UAC is RFC3262 compliant, it SHOULD
logically send individual CANCELs to cancel INVITE and PRACK
transactions.
-Arun
On Wed, Dec 17, 2008 at 2:19 AM, Serbang, Nabam (Nabam)
<[email protected]> wrote:
Sorry guys. There was mistake.
"...........Since UAC didn't recive 200 PRACK as yet and
UAC didn't
receive PRACK..." should as "......Since UAC didn't
recive 200 PRACK as
yet and UAS didn't receive PRACK...."
Apologies for inconvenience.
Thanks and regards
Nabam Serbang
-----Original Message-----
From: [email protected]
[mailto:[email protected]]
On Behalf Of
Serbang, Nabam (Nabam)
Sent: Wednesday, December 17, 2008 3:45 PM
To: Arunachala; Rockson Li (zhengyli)
Cc: [email protected]
Subject: Re: [Sip-implementors] INVITE Behaviour When
PRACK
isnotrespondedwith 2xx
>From rfc3262:
"The UAS MAY send a final response to the initial
request before
having received PRACKs for all unacknowledged reliable
provisional
responses, unless the final response is 2xx and any of
the
unacknowledged reliable provisional responses
contained a session
description. In that case, it MUST NOT send a final
response until
those provisional responses are acknowledged. If the
UAS does send a
final response when reliable responses are still
unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged
reliable
provisional responses, but it MUST be prepared to
process PRACK
requests for those outstanding responses. A UAS MUST
NOT send new
reliable provisional responses (as opposed to
retransmissions of
unacknowledged ones) after sending a final response to
a request"
Scenario 1:
PRACK from UAC depends on initial INVITE. If invite had
"Require"
header field with value "100rel", UAS must send 1xx
respone (except 100
trying) back to UAC. If UAS has sent 101-199 in reponse
to INVITE
(Remember there will be Rseq header field in prov.
response) , UAS will
be expecting PRACK from UAC. Since UAC didn't recive
200 PRACK as yet
and UAC didn't receive PRACK, will 200 INV be accepted
by UAC? I don't
think so. I guess 481 will do or time out ( Possibily by
UAS). Again
INVITE, PRACK initiates transaction each, both the
transaction should be
rolled back as PRACK transaction is initiated by INVITE.
No doubt you
can let UAC accept after sending PRACK and before
receiving 200 PRACK
but that will be a violation of protocol, not just SIP
but definitation
of "transaction" as well. From rfc3262, "...........In
that case, it
MUST NOT send a final response until those provisional
responses are
acknowledged....", UAS definitely is not going to send
200 INV if PRACK
is not received.
Whats your take on this?
Scenario 2:
What "> ----CANCEL---->" is doing? Is it cancelling
PRACK or INVITE? I
guess you mean CANCEL to PRACK. Practically, I don't
see any reason/way
to cancel PRACK. It make sense for protocol completeness
though. Anyway,
if CANCEL was for PRACK, it should be re-transmitted
reason as stated in
scenarion 1 above.
> Scenario 1:
>
> UAC UAS
> ----INV------->
> <---180--------
> ---PRACK----->
> (Peer didnt respond to PRACK because of some problem)
<---200 INV----
> ----ACK------->
> ----PRACK-----> ??
>
> Should UAC retransmit PRACK ?
> or
> Should the PRACK retransmissions stop after receiving
200OK to INVITE?
>
>
> Scenario 2:
>
> UAC UAS
> ----INV------->
> <---180--------
> ----PRACK----->
> (Peer didnt respond to PRACK because of some problem)
> ----CANCEL---->
> <---200 CAN----
> <---487 INV----
> ----ACK------->
> ----PRACK-----> ??
>
> Should UAC retransmit PRACK ?
> or
> Should the PRACK retransmissions stop after receiving
487 to INVITE?
Thanks and regards
Nabam Serbang
-----Original Message-----
From: [email protected]
[mailto:[email protected]]
On Behalf Of
Arunachala
Sent: Wednesday, December 17, 2008 2:19 PM
To: Rockson Li (zhengyli)
Cc: [email protected]
Subject: Re: [Sip-implementors] INVITE Behaviour When
PRACK is
notrespondedwith 2xx
For the scenario 1,
I think, as PRACK is a in-dialog request, according to
RFC3261, it
SHOULD be retransmitted till timer-F expires.
For the scenario 2,
I think, we can STOP retransmitting PRACK (even if it
the Transaction
has NOT timed-out), because the early dialog which PRACK
might have
facilitated the establishment of, has been terminated by
CANCEL. Also,
even if we retransmit PRACK, UAS would NOT find any
unacknowledged '18x'
(which matches the CSeq# and CSeq method in RAck of
PRACK), so it would
send a '481' in response.
-Arun
On Tue, Dec 16, 2008 at 6:36 PM, Rockson Li (zhengyli)
<[email protected]>wrote:
> IMO, you should differentiate the retransmission of
PRACK in uac core
> and transaction layer.
> PRACK is a normal req, which has its own transaction,
so it's
> transaction who would assure the retransmission of the
PRACK, not UAC
> core layer.
> On retransmission in transaction expires, I don't
think it's
> necessary for UAC core to retransmit the PRACK.
>
> My 2 $
>
> -Rockson
> -----Original Message-----
> From: [email protected]
>
[mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Tuesday, December 16, 2008 6:26 PM
> To: [email protected]
> Subject: [Sip-implementors] INVITE Behaviour When
PRACK is not
> respondedwith 2xx
>
>
>
> Dear all,
>
> Could you please let me know the behaviour of UAC in
the following
> scenario (RFC3262 doesn't seem to address this
behaviour).
>
> Scenario 1:
>
> UAC UAS
> ----INV------->
> <---180--------
> ---PRACK----->
> (Peer didnt respond to PRACK because of some problem)
<---200 INV----
> ----ACK------->
> ----PRACK-----> ??
>
> Should UAC retransmit PRACK ?
> or
> Should the PRACK retransmissions stop after receiving
200OK to INVITE?
>
>
> Scenario 2:
>
> UAC UAS
> ----INV------->
> <---180--------
> ----PRACK----->
> (Peer didnt respond to PRACK because of some problem)
> ----CANCEL---->
> <---200 CAN----
> <---487 INV----
> ----ACK------->
> ----PRACK-----> ??
>
> Should UAC retransmit PRACK ?
> or
> Should the PRACK retransmissions stop after receiving
487 to INVITE?
>
> Thanks & Regards
> Tamal Tanu Biswas
>
>
>
>
> Please do not print this email unless it is absolutely
necessary.
>
> The information contained in this electronic message
and any
> attachments to this message are intended for the
exclusive use of the
> addressee(s) and may contain proprietary, confidential
or privileged
> information. If you are not the intended recipient,
you should not
> disseminate, distribute or copy this e-mail. Please
notify the sender
> immediately and destroy all copies of this message and
any
attachments.
>
> WARNING: Computer viruses can be transmitted via
email. The recipient
> should check this email and any attachments for the
presence of
viruses.
> The company accepts no liability for any damage caused
by any virus
> transmitted by this email.
>
> www.wipro.com
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
