Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header - PRACK or no PRACK?

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi Bob,

Please take a look at the proposed rules I sent out some rules ago. In
normal cases you would not send Recv-Info in ACK.

Regards,

Christer 

-----Original Message-----
From: Bob Penfield [mailto:BPenfield at acmepacket.com] 
Sent: 19. marraskuuta 2009 14:57
To: Paul Kyzivat
Cc: Christer Holmberg; sipcore at ietf.org
Subject: RE: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header - PRACK or no PRACK?

I was trying to avoid race conditions where the ACK might arrive before
the PRACK, which could occur if the UAS is allowed to send the 200-OK to
the INVITE with an un-PRACKed 1xx that did not contain SDP. Maybe we
should say that if Recv-Info was in a PRACK or UPDATE for an "early"
dialog, that the ACK should not contain Recv-Info.

As far as repeating the Recv-Info in 200-OK, that should only apply for
unreliable 1xx response.


cheers,
(-:bob




-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Wednesday, November 18, 2009 8:58 PM
To: Bob Penfield
Cc: Christer Holmberg; sipcore at ietf.org
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header - PRACK or no PRACK?



Bob Penfield wrote:
> As I said before, I think allowing Recv-Info in a PRACK can be useful.
Recv-Info does not have the problems that SDP has because it is NOT a
negotiation, it is an advertisement. Whatever you last got in a
Recv-Info is what you can send.

I agree.

> I would recommend that Recv-Info be optional in a PRACK,

Yes.

> but require that the same Recv-Info be sent in the ACK.
> I would also make Recv-Info optional in 1xx, but require the same
Recv-Info in the 200-OK.

Why? I don't think this is necessary.

Especially for PRACK, you know if it got there when you get the 
response. No value in sending again later. And then it gets messy if you

later change with an UPDATE before the ACK.

For 1xx, I would agree that if you send in an *unreliable* 1xx that you 
SHOULD send again in a reliable response or other message. But even 
then, you might change your mind and want to send something else.

How about just a note that if sent in an unreliable 1xx then it may not 
get there, and you should take that into account.

	Thanks,
	Paul

> cheers,
> (-:bob
> 
> 
> 
> 
> -----Original Message-----
> From: sipcore-bounces at ietf.org [mailto:sipcore-bounces at ietf.org] On
Behalf Of Christer Holmberg
> Sent: Wednesday, November 18, 2009 6:36 AM
> To: sipcore at ietf.org
> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info
header - PRACK or no PRACK?
> 
>  
> Folks,
> 
> We need to come to a conclusion on this topic: do we allow Recv-Info
in
> PRACK or not?
> 
> I hear those people saying that we have enough problems with allowing
> SDPs etc in PRACK, and that we shouldn't add more.
> 
> I also hear those people saying that we would be able to re-use a
PRACK,
> instad of sending an UPDATE, if there is a need to provide a Info
> Package set "in the middle of" an INVITE/re-INVITE transaction.
> 
> Personally, since I've been involved in the problems-with-PRACK
> discussions, I would vote for NOT allowing it in PRACK. But, I will
> implement whatever the group decides upon :)
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore at ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore at ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>