As others have mentioned, the subsequent reliable provisionals must
increment RSeq. This flags them as distinct responses, rather than
retransmissions of the first response.
Paul
Ganesh P wrote:
> Hi Paul/Arun/Vikram,
>
> If it should not retransmit for extending the transaction what it
> should do. Whether it should again construct one more provisional response
> assume it is sending 183 session progress reliably for the second time in 2
> minute 30 seconds again if it wants to go ahead with extending the
> transaction which header it should change (we cannot increment the cseq
> number). I have copied some RFC sentences below please check
>
> "The CSeq number is incremented for each new request within a dialog
> and is a traditional sequence number. (it is not for responses)"
>
> " the UAS needs to send them more frequently (once a minute is
> recommended) because of the possibility of packet loss. As a more
> efficient alternative, the UAS can send the response reliably, in
> which case the UAS SHOULD send provisional responses once every two
> and a half minutes. Use of reliable provisional responses for
> extending transactions is RECOMMENDED."
>
>
> Thanks and Regards,
> Ganesh
>
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 20, 2008 5:45 PM
> To: Ganesh Pitchiah S
> Cc: [email protected]
> Subject: Re: [Sip-implementors] When need to send PRACK
>
> Clarification question:
>
> Is the second 180 truly a retransmission, or is it a *new* 180?
>
> Paul
>
> Ganesh Pitchiah S wrote:
>> Hi All,
>>
>> I have a doubt regarding continuous transmitting of provisional
>> response. In our system we are having two SIP entities
>>
>> Assume one sip entity is softx and other is SCP.
>>
>> SCP sends 180 with SDP to softx to have early dialog and we are having a
>> situation that early dialog should go for 4 minutes.
>>
>> After 2 minutes and 30 seconds SCP is retransmitting the 180 with SDP
> again
>> but the softx is not accepting the same because it has already send PRACK
>> for the earlier response and it is releasing the call after 3 minutes
>> because it did not get any new response.
>>
>>
>>
>> Can any one say whose behavior is correct? (I checked with RFC3262 I think
>> SCP behavior is correct)
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Thanks and Regards,
>>
>> Ganesh
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
