Hi Christer,
Thanks for your answers.
Is the other scenario raised by Paul below?
-> INVITE
<- 180rel
-> PRACK
<- 401
And are there any other cases?IMO, only prack with new offer could cause this problem.
Also another question:
Is the flows below valid according to recent arguments?
UAC UAS
|----invite(SDP)--->|
|<--- 183(SDP)------|
|-----prack(SDP)--->|
|<--- 200(SDP)------|
flow 1
UAC UAS
|----invite-------->|
|<--- 183-----------|
|-----prack(SDP)--->|
|<--- 200(SDP)------|
flow 2
Regards,
Eric
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-04-02 15:10 |
|
Hi,
>Questions:
>
>1. Is this argument arised because that the prack carrys a new offer?
That is what initially triggered thee discussion, but since then I think we have realized that there can be other reasons why a PRACK gets rejected.
>2. Is there a use-case the prack must contain a new offer?
Not as far as I know. You can always use UPDATE - assuming that you support UPDATE, that is.
Regards,
Christer
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx> 发件人: sipping-bounces@xxxxxxxx 2009-04-02 14:10 |
|
1xx.
The retransmitting of PRACK will of course cease when the respone (whatever the response code is) is received.
When I talk about "UAC sending a new PRACK" I don't mean re-transmit the previous PRACK. I am talking about generating a PRACK, which hopefully is less likely to be rejected.
-----Original Message-----
From: Hisham Khartabil [mailto:hisham.khartabil@xxxxxxxxx]
Sent: Thursday, April 02, 2009 7:07 AM
To: Christer Holmberg
Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); sipping@xxxxxxxx
Subject: Re: [Sipping] PRACK: Does non-200 response cease re-transmission ofreliable 18x?
Are you talking about retransmitting of PRACK or 1xx?
2009/4/2 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>:
>
> Hi,
>
>>>>If the 1xx carried and answer, then the PRACK would carry an offer.
>>>>Rejecting that offer in the PRACK with a 4xx by the UAS should not
>>>>impact the assertion that the 1xx has reached its destination.
>>>>Therefore no point in retransmitting the 1xx.
>>>
>>>True. But the UAC doesn't know whether the UAS, or some intermediate, rejected the offer.
>>
>>Yeah, that's not the issue.
>
> That IS the issue. If it wasn't, I think most people would agree that the re-transmission is ceased - at least nobody has said otherwise in the previous e-mail discussions we've had on this.
>
>>Of course the UAS will retransmit in this case. It hasnt seen the
>>PRACK. The issue is if the UAS does receive the PRACK but rejects it.
>>
>>In my opinion, unless the UAS responds with a 401, the PRACK has served its purpose.
>
> I agree with you, and the way 3262 is written is more or less says that the re-transmission of the 18x stops when the PRACK is received - before you know what the final response is going to be.
>
> But, again, the problem with that solution is that the UAC cannot be sure whether the UAS actually received the PRACK, and therefor the proposed solution is that it sends a new PRACK in case of a non-200 response.
>
> Regards,
>
> Christer
>
>
>
>
>>
>>>Again, we need to look at what the PRACK is really doing. It is acknowledging that the 1xx has reached its destination.
>>
>> As Hadriel said: I wish that was all it was doing.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
>>>> Behalf Of Hisham Khartabil
>>>> Sent: Wednesday, April 01, 2009 10:15 PM
>>>> To: Rockson Li (zhengyli)
>>>> Cc: Paul Kyzivat (pkyzivat); sipping@xxxxxxxx; Christer Holmberg
>>>> Subject: Re: [Sipping] PRACK: Does non-200 response cease
>>>> re-transmission ofreliable 18x?
>>>>
>>>> We already know that one. I was asking if there are any others.
>>>>
>>>> Hisham
>>>>
>>>> 2009/4/2 Rockson Li (zhengyli) <zhengyli@xxxxxxxxx>:
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx]
>>>> > On
>>>> Behalf Of Hisham Khartabil
>>>> > Sent: Thursday, April 02, 2009 9:37 AM
>>>> > To: Paul Kyzivat (pkyzivat)
>>>> > Cc: sipping@xxxxxxxx; Christer Holmberg
>>>> > Subject: Re: [Sipping] PRACK: Does non-200 response cease re-
>>>> transmission ofreliable 18x?
>>>> >
>>>> > That's a good scenario. Any others?
>>>> >
>>>> > The point of the PRACK is to indicate to the UAS that the 1xx it
>>>> > sent
>>>> was received successfully. Unless its a 401 to the PRACK, I don't
>>>> see any other reason why the UAS should continue retransmitting the
>>>> 1xx if its sent a non 2xx reponse to a PRACK. The PRACK has served its purpose.
>>>> >
>>>> > Having said that, what other reasons would a UAS reject a PRACK?
>>>> > [RL] authentication.
>>>> > https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-
>>>> March/022095.html
>>>> >
>>>> > Hisham
>>>> >
>>>> > 2009/4/1 Paul Kyzivat <pkyzivat@xxxxxxxxx>:
>>>> >>
>>>> >>
>>>> >> Christer Holmberg wrote:
>>>> >>>
>>>> >>> Hi,
>>>> >>>
>>>> >>> One of the PRACK related issues presented in SFO is whether a
>>>> >>> PRACK non-200 response would cease re-transmission of the
>>>> >>> assoicated reliable 18x response.
>>>> >>>
>>>> >>> Based on the mail discussions we've had I proposed that the
>>>> >>> non-200 response DOES NOT ceasee the re-transmission. However,
>>>> >>> some people seemed to have an issue with that, so I was asked
>>>> >>> to "take it to the
>>>> list".
>>>> >>>
>>>> >>> The main justification why a non-200 response would not cease
>>>> >>> the re-transmission is because an intermediate may reject the
>>>> >>> PRACK, in which case the UAS will never receive it (read: the
>>>> >>> UAS will continue to re-transmit the reliable 18x). So, when
>>>> >>> the UAC receives the PRACK non-200 response it should send a
>>>> >>> new PRACK, which hopefully will reach the UAS and trigger a 200 response.
>>>> >>>
>>>> >>> So, anyone who does not agree with the justification aboive,
>>>> >>> and thinks that a non-200 response DOES cease the
>>>> >>> re-transmission of the associated reliable 18x response, please indicate so.
>>>> >>
>>>> >> I agree with Christer here. Another scenario where this would be
>>>> >> important
>>>> >> is:
>>>> >>
>>>> >> -> INVITE
>>>> >> <- 180rel
>>>> >> -> PRACK
>>>> >> <- 401
>>>> >>
>>>> >> It this case it is essential to retry the PRACK with updated
>>>> credentials.
>>>> >> Certainly the UAS doesn't want to consider the 180 to have been
>>>> >> acknowledged in this case, since it might have been from a MiTM.
>>>> >>
>>>> >> This could come about in the case of a reINVITE, where the nonce
>>>> >> used in the original INVITE finally becomes stale by the time
>>>> >> the PRACK is
>>>> received.
>>>> >>
>>>> >> Thanks,
>>>> >> Paul
>>>> >> _______________________________________________
>>>> >> 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/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
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
