Subject: Re: [Sipping] PRACK update: other changes than allowing SDP offer inPRACK to be rejected?

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 08:48:30 +0100

Hi,
 
Now, when everybody is in offer/answer mode, please let me remind me of
the other issue we need to solve: rejecting SDP offers in PRACKs.

The status at the moment is that we agreed that one should be able to
reject an SDP offer in a PRACK with a 4xx response.

Q1. One of the questions were whether that 4xx response should also
terminate the re-transmission of the reliable 18x response the PRACK is
supposed to acknowledge.
 
- One problem with saying that the re-transmission of the 18x shall stop
is that if an intermediate rejects the PRACK, the UAS will still
re-transmit the 18x - eventhough the UAC will think the re-transmission
has ceased.
 
- One problem with saying that the re-transmission of the 18x shall not
stop (basically meaning that the UAC would have to send a new PRACK) is
that the current PRACK RFC more or less says that the re-transmission
stops when the PRACK is received - no matter what the response code is
going to be (maybe it was written in that way because it was assumed
that the response code would always be 200).
 
So, we really need some input and thoughts on that.

 
Q2. Another issue was whether we were going to loose up some other PRACK
restrictings, e.g. that the first reliable 18x must contain an SDP offer
if the INVITE didn't. We agreed that we are NOT going to do that, unless
someone can show that the current rules causes problems.
 
So, if you have use-cases or scenarios where the
first-reliable-18x-must-contain-SDP-offer rule causes problems, please
post them on the list.

Regards,
 
Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Mar 2009 03:37:30 -0500

Pl. see inline ...

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christer Holmberg
	Sent: Wednesday, March 04, 2009 1:19 PM
	To: SIPPING List
	Subject: Re: [Sipping] PRACK update: other changes than allowing
SDP offerinPRACK to be rejected?

	Hi,
	 
	Now, when everybody is in offer/answer mode, please let me
remind me of the other issue we need to solve: rejecting SDP offers in
PRACKs.

	The status at the moment is that we agreed that one should be
able to reject an SDP offer in a PRACK with a 4xx response.
	[Sanjay Sinha (sanjsinh)]  What happens if PRACK needs to be
rejected for reason other than for offer-answer, like say CSEQ or RAck
header is malformed? I would think that the behavior would be same as if
rejecting the PRACK because offer sdp is unacceptable.
	Moreover for rejecting offer in PRACK, I think a non error
response approach may be good. Probably Gonzallo's rollback proposal
mechanism can be followed here also, ie send 200 OK to PRACK with port
number set to 0 or c line set to 0 or media attribute line set to
inactive and then have UAS send an UPDATE to go back to the earlier
negotiated offer-answer session. 
	 
	Q1. One of the questions were whether that 4xx response should
also terminate the re-transmission of the reliable 18x response the
PRACK is supposed to acknowledge.
	 
	- One problem with saying that the re-transmission of the 18x
shall stop is that if an intermediate rejects the PRACK, the UAS will
still re-transmit the 18x - eventhough the UAC will think the
re-transmission has ceased.
	 
	- One problem with saying that the re-transmission of the 18x
shall not stop (basically meaning that the UAC would have to send a new
PRACK) is that the current PRACK RFC more or less says that the
re-transmission stops when the PRACK is received - no matter what the
response code is going to be (maybe it was written in that way because
it was assumed that the response code would always be 200).

	 
	 
	Q2. Another issue was whether we were going to loose up some
other PRACK restrictings, e.g. that the first reliable 18x must contain
an SDP offer if the INVITE didn't. We agreed that we are NOT going to do
that, unless someone can show that the current rules causes problems.
	[Sanjay Sinha (sanjsinh)]  I think there should be some
explanation for why the first reliable provisional response needs to
have offer sdp. I do not have first hand experience, but I have been in
discussion where it was mentioned that this rule causes problem in
interworking scenarios, say with a H323 gw. In that case, the media is
not available till capabilities exchange is done and OLC received. So
for SIP responses to be sent in response to H225 signaling,
ALERT/PROGRESS etc., far end sdp is not available.
	 
	Sanjay

	Regards,
	 
	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 11:55:32 +0100

Hi, 
		 
>[Sanjay Sinha (sanjsinh)]  What happens if PRACK needs to be rejected
for reason other than for offer-answer, like say CSEQ or RAck header is
malformed?

The same thing applies there, of course. So, maybe we should talk about
PRACK reject in general, instead of offer/answer.

>I would think that the behavior would be same as if rejecting the PRACK
because offer sdp is unacceptable.

Sure, but that is not specified either at the moment :)

I think the only PRACK reject use-case which is specified is when there
is no matching provisional response to acknowledge in the first place.

...and, of course, in cases the call doesn't exist etc.

>Moreover for rejecting offer in PRACK, I think a non error response
approach may be good. Probably Gonzallo's rollback proposal mechanism
can be followed here also, ie send 200 OK to PRACK with 
>port number set to 0 or c line set to 0 or media attribute line set to

We could of course do that. However, I don't think the justfication is
the same. Here we are talking about rejecting an offer when it's
received - nothing more, nothing less :)

Also, as you said, PRACK can be rejected for other reasons, so I think
we should focus on what happens if it is rejected - for whatever reason.

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 4 Mar 2009 07:26:16 -0500

Since RFC 3261 says that mid-dialog requests are processed atomic, I
think UAS should not cease retransmission of the provisional response
and wait for UAC to fix the error with PRACK. If it runs out of
retransmissions, it should reject the Invite with 5xx response.

Having re-read RFC 3262, I think offer handling in PRACK should be
treated differently than Prack failing to match the response, because it
mentions that retransmissions should cease when matching Prack is
received. But sdp offer is not part of matching request to ongoing
transaction.
So I still think that answer should be sent in 200 OK with rejection
represented in the answer followed by an UPDATE to restore previous
media session.

Sanjay

>-----Original Message-----
>From: Christer Holmberg [mailto:[email-masked]] 
>Sent: Wednesday, March 04, 2009 4:26 PM
>To: Sanjay Sinha (sanjsinh); SIPPING List
>Subject: RE: [Sipping] PRACK update: other changes than 
>allowing SDP offerinPRACK to be rejected?
>
>
>Hi, 
>		 
>for reason other than for offer-answer, like say CSEQ or RAck 
>header is malformed?
>
>The same thing applies there, of course. So, maybe we should 
>talk about PRACK reject in general, instead of offer/answer.
>
>I think the only PRACK reject use-case which is specified is 
>when there is no matching provisional response to acknowledge 
>in the first place.
>
>approach may be good. Probably Gonzallo's rollback proposal 
>mechanism can be followed here also, ie send 200 OK to PRACK with 
>inactive and then have UAS send an UPDATE to go back to the 
>earlier negotiated offer-answer session. 
>
>We could of course do that. However, I don't think the 
>justfication is the same. Here we are talking about rejecting 
>an offer when it's received - nothing more, nothing less :)
>
>Also, as you said, PRACK can be rejected for other reasons, so 
>I think we should focus on what happens if it is rejected - 
>for whatever reason.
>
>Regards,
>
>Christer
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 4 Mar 2009 14:57:32 +0100

Hi, 

>Since RFC 3261 says that mid-dialog requests are processed 
>atomic, I think UAS should not cease retransmission of the 
>provisional response and wait for UAC to fix the error with 
>PRACK. If it runs out of retransmissions, it should reject 
>the Invite with 5xx response.

So, do you agree that we in any case would need to say whether an error
response also ceases retransmission of the provisional response - no
matter what triggers that error response?

>Having re-read RFC 3262, I think offer handling in PRACK 
>should be treated differently than Prack failing to match the 
>response, because it mentions that retransmissions should 
>cease when matching Prack is received. But sdp offer is not 
>part of matching request to ongoing transaction.
>So I still think that answer should be sent in 200 OK with 
>rejection represented in the answer followed by an UPDATE to 
>restore previous media session.

There could also be an intermediate which rejects the PRACK offer, and
it may not be willing/capable of generating UPDATEs, because that would
require rather heave B2BUA functionality.

Earlier there were also some other ideas, e.g:

- don't include an SDP in the 200
- don't update the SDP version number in the 200
- etc etc etc

But, I think that we at that time decided not to go for any of those.

Regards,

Christer

> >Subject: RE: [Sipping] PRACK update: other changes than allowing SDP 
> >offerinPRACK to be rejected?
> >
> >
> >Hi,
> >		 
> talk about 
> when there 
> mechanism 
> justfication is

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 5 Mar 2009 00:18:16 -0500

>Sent: Wednesday, March 04, 2009 7:28 PM
>So, do you agree that we in any case would need to say whether 
>an error response also ceases retransmission of the 
>provisional response - no matter what triggers that error response?

No, I am not saying that, in fact I am saying that error response to
Prack *does not* cease retransmission of provisional response.

>>treated differently than Prack failing to match the response, because 
>>it mentions that retransmissions should cease when matching Prack is 
>There could also be an intermediate which rejects the PRACK 
>offer, and it may not be willing/capable of generating 
>UPDATEs, because that would require rather heave B2BUA functionality.

What are the use cases for an intermediate rejecting offer in Prack if
it is not interested in media?

>- don't update the SDP version number in the 200

I think this option is better than not sending any sdp in 200 OK, since
that violates offer answer model.

BTW, what about the other issue you brought up, about first reliable
provisional response having an offer sdp for delayed media cases. IMO,
that problem is more widespread compared to Prack offer case, which I
think it used for precondition case.

Thanks

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 08:02:43 +0100

Hi, 

And you think that is clear in the RFC, so no change/update is needed
for that?

The intermediate WOULD most likely be interested in media.

provisional response having an offer sdp for delayed media cases. IMO,
that problem is more widespread compared to Prack offer case, 
>which I think it used for precondition case.

Well, so far nobody has demonstrated that the rule about the first
reliable provisional response would cause problems. If you have
scenarios where it does cause problem, please let us know.

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 6 Mar 2009 01:35:31 -0500

Pl. see inline..

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>Sent: Thursday, March 05, 2009 12:33 PM
>Subject: Re: [Sipping] PRACK update: other changes than 
>allowing SDPofferinPRACK to be rejected?
>
>
>Hi, 
>
>atomic, I 
>And you think that is clear in the RFC, so no change/update is 
>needed for that?

No it is not and I think putting together a document clarifying that
will be good.

>rejection 
>offer, and

Then I think intermediate should also update media to be in previous
state before offer was rejected.

>provisional response having an offer sdp for delayed media 
>cases. IMO, that problem is more widespread compared to Prack 
>offer case, 
>Well, so far nobody has demonstrated that the rule about the 
>first reliable provisional response would cause problems. If 
>you have scenarios where it does cause problem, please let us know.

I sent you one, about interop with H323 gw, in case of slow start.
Here is another one involving a call forward (CFALL or CFBusy) on a SIP
device -
 
INVITE without SDP comes into a SIP PBX for user A.
User A has forwarded their calls to user B or User A has CFBusy to B.
SIP PBX sends a 181 to UAC. This 181 does not have SDP as the PBX has
not yet routed the call to user B. If PRACK is enabled, this will
violate the first reliable provisional response MUST have SDP rule.
SIP PBX then routes the call to user B and sends 183 Session Progress
with the offer SDP.

I will ask around to see if there are any more.

Thanks

>_______________________________________________
>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
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Mar 2009 13:29:17 +0100

Hi, 

>>And you think that is clear in the RFC, so no change/update 
>>is needed for that?
> 
will be good.

I believe it would require a number of editorial changes in 3261.
Because, currently the text more or less says that the re-transmission
is ceased as soon as the PRACK is received, before it is further
processed.

But, there is probably nothing we can do about that.

Also, a PRACK can be rejected for other reasons even if it contains an
SDP body. It all depends how the receiver processes the request, so one
must be prepared to receive a 4xx response for a PRACK carrying SDP.

>>>>it may not be willing/capable of generating UPDATEs, because that
would require rather heave B2BUA functionality.

Sure, but that is not the issue. The issue is that if intermediate wants
to reject the SDP offer in the PRACK, the intermediate would have to
generate an UPDATE.

Also, I don't think that PRACKs will be rejected because of SDP offer
very often, so I doubt people would implement an UPDATE based solution
anyway. So, I think it's better to simply say that the offer can be
rejected with a 4xx response.

>I sent you one, about interop with H323 gw, in case of slow start.

I may have lost that one, but I'll check my archieve.

>Here is another one involving a call forward (CFALL or 
>CFBusy) on a SIP device -
>  
>SIP PBX sends a 181 to UAC. This 181 does not have SDP as the 
>PBX has not yet routed the call to user B. If PRACK is 
>enabled, this will violate the first reliable provisional 
>response MUST have SDP rule.
>SIP PBX then routes the call to user B and sends 183 Session 
>Progress with the offer SDP.

Seems valid. I guess this would happen if the call comes from a H.323
gateway, or from an application server doing 3pcc, but never the less...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Mar 2009 13:43:43 +0100

Correction:

Editorial changes to 3262.

> Sent: 6. maaliskuuta 2009 14:29
> allowingSDPofferinPRACK to be rejected?
> 
> 
> Hi, 
> 
> >>>>>Since RFC 3261 says that mid-dialog requests are 
> processed atomic,
> I
> is needed 
> Because, currently the text more or less says that the 
> re-transmission is ceased as soon as the PRACK is received, 
> before it is further processed.
> 
> Also, a PRACK can be rejected for other reasons even if it 
> contains an SDP body. It all depends how the receiver 
> processes the request, so one must be prepared to receive a 
> 4xx response for a PRACK carrying SDP.
> 
> 
> 
> 
> Sure, but that is not the issue. The issue is that if 
> intermediate wants to reject the SDP offer in the PRACK, the 
> intermediate would have to generate an UPDATE.
> 
> Also, I don't think that PRACKs will be rejected because of 
> SDP offer very often, so I doubt people would implement an 
> UPDATE based solution anyway. So, I think it's better to 
> simply say that the offer can be rejected with a 4xx response.
> 
> Seems valid. I guess this would happen if the call comes from 
> a H.323 gateway, or from an application server doing 3pcc, 
> but never the less...
> 
> Regards,
> 
> Christer
> 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
>