Re: Fwd: PRACK: Does non-200 response ceasere-transmissionofreliable 18x?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

----- Original Message -----
From: sipping-bounces@xxxxxxxx <sipping-bounces@xxxxxxxx>
To: sipping@xxxxxxxx <sipping@xxxxxxxx>
Sent: Sun Apr 05 22:07:03 2009
Subject:  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 <mdolly@xxxxxxx>
Date: 2009/4/6
Subject: Re:  PRACK: Does non-200 response cease
re-transmissionofreliable 18x?
To: hisham.khartabil@xxxxxxxxx


Because your an acedemic, at best

----- Original Message -----
From: Hisham Khartabil <hisham.khartabil@xxxxxxxxx>
To: DOLLY, MARTIN C, ATTLABS
Sent: Sun Apr 05 21:58:31 2009
Subject: Re:  PRACK: Does non-200 response cease
re-transmissionofreliable 18x?

why are you calling me an a-hole?

2009/4/6 DOLLY, MARTIN C, ATTLABS <mdolly@xxxxxxx>:
> What do you know?
>
> ----- Original Message -----
> From: Hisham Khartabil <hisham.khartabil@xxxxxxxxx>
> To: DOLLY, MARTIN C, ATTLABS
> Sent: Sun Apr 05 21:50:57 2009
> Subject: Re:  PRACK: Does non-200 response cease re-transmissionofreliable 18x?
>
> Excuse me?
>
> 2009/4/6 DOLLY, MARTIN C, ATTLABS <mdolly@xxxxxxx>:
>> No a-hole
>>
>> ----- Original Message -----
>> From: sipping-bounces@xxxxxxxx <sipping-bounces@xxxxxxxx>
>> To: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
>> Cc: sipping@xxxxxxxx <sipping@xxxxxxxx>; Brett Tate <brett@xxxxxxxxxxxxx>
>> Sent: Sun Apr 05 19:37:29 2009
>> Subject: Re:  PRACK: Does non-200 response cease re-transmissionofreliable 18x?
>>
>> 2009/4/3 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>:
>>>
>>> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
>> Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________Sipping mailing list  https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux