Subject: Re: [Sipping] Fwd: PRACK: Does non-200 response ceasere-transmissionofreliable 18x?

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 5 Apr 2009 22:23:39 -0400

To be clearer, your wrong and you have your head up a horse's tail end

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Sun Apr 05 22:07:03 2009
Subject: [Sipping] Fwd: PRACK: Does non-200 response ceasere-transmissionofreliable 18x?

Hi All,

Please read Martin's private response to my email. Just wanted to show
the community his professionalism. I don't know this person and have
never interacted with him, yet he calls me names and responds
unprofessionally.

Hisham

---------- Forwarded message ----------
From: DOLLY, MARTIN C, ATTLABS <[email-masked]>
Date: 2009/4/6
Subject: Re: [Sipping] PRACK: Does non-200 response cease
re-transmissionofreliable 18x?
To: [email-masked]

Because your an acedemic, at best

----- Original Message -----
From: Hisham Khartabil <[email-masked]>
To: DOLLY, MARTIN C, ATTLABS
Sent: Sun Apr 05 21:58:31 2009
Subject: Re: [Sipping] PRACK: Does non-200 response cease
re-transmissionofreliable 18x?

why are you calling me an a-hole?

2009/4/6 DOLLY, MARTIN C, ATTLABS <[email-masked]>:
> What do you know?
>
> ----- Original Message -----
> From: Hisham Khartabil <[email-masked]>
> To: DOLLY, MARTIN C, ATTLABS
> Sent: Sun Apr 05 21:50:57 2009
> Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmissionofreliable 18x?
>
> Excuse me?
>
> 2009/4/6 DOLLY, MARTIN C, ATTLABS <[email-masked]>:
>> No a-hole
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: Christer Holmberg <[email-masked]>
>> Cc: [email-masked] <[email-masked]>; Brett Tate <[email-masked]>
>> Sent: Sun Apr 05 19:37:29 2009
>> Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmissionofreliable 18x?
>>
>> 2009/4/3 Christer Holmberg <[email-masked]>:
>>>
>>> Hi,
>>>
>>>>>The UAC is unaware if the PRACK has served its purpose since it
>>> doesn't know if rejected by middle box or the UAS
>>>>>performing the retries.
>>>>
>>>>That's not the UAC's problem. The only reasone a PRACK has a response
>>> is because you had to fit it into one of the state
>>>>machines defined in RFC3261. That doesnt mean we go a sover analyse its
>>> response.
>>>
>>> So, how do you propose that we solve the issue if the PRACK was rejected
>>> by an intermediate, and the UAS never got it?
>>
>> That's already solved in RFC3262. Read Section 3:
>>
>> "The reliable provisional response is passed to the transaction layer
>>   periodically with an interval that starts at T1 seconds and doubles
>>   for each retransmission"
>>
>> and
>>
>> "Retransmissions of the reliable provisional response cease when a
>>   matching PRACK is received by the UA core"
>>
>> and
>>
>> "If a PRACK request is received by the UA core that does not match any
>>   unacknowledged reliable provisional response, the UAS MUST respond to
>>   the PRACK with a 481 response.  If the PRACK does match an
>>   unacknowledged reliable provisional response, it MUST be responded to
>>   with a 2xx response"
>>
>> and
>>
>> "If a reliable provisional response is retransmitted for 64*T1 seconds
>>   without reception of a corresponding PRACK, the UAS SHOULD reject the
>>   original request with a 5xx response."
>>
>> But I guess your issue is with the following text in section 4:
>>
>> "   Note that the PRACK is like any other non-INVITE request within a
>>   dialog.  In particular, a UAC SHOULD NOT retransmit the PRACK request
>>   when it receives a retransmission of the provisional response being
>>   acknowledged, although doing so does not create a protocol error."
>>
>> You want the UAC to retransmit the PRACK. Or the UAC can remvoe state
>> of the 1xx it PRACKed and treat the retrasmission of the 1xx as a new
>> one (I haven't thought this one through properly though).
>>
>> Hisham
>>
>>>
>>> Even if it's not the UAC's "problem", the UAC can help to ensure that
>>> the UAS really gets the PRACK.
>>>
>>> I agree that we shouldn't start to analyse responses in detail. The
>>> proposal is simply that a non-200 response does not cease the
>>> re-transmission of the reliable response.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>> _______________________________________________
>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments of core SIP
>>
>
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP