Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO?

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Nov 2009 10:46:04 -0600

Wading through the long list of mail on this looking for loose ends:

I don't think we've established agreement that you have to wait for an
ACK (or PRACK) to arrive before sending an INFO.

If I'm wrong, the draft needs to say that very explicitly - things  
will send
media immediately after the 183 or a 200 without waiting for the  
associated
PRACK or ACK and I rather expect they think the dialog (early or  
otherwise) has
been established when they do that. Can you point to some existing RFC  
text that
says otherwise?

  I suspect if there are every any packages for INFO, one of them  
might expect to be able to send them
as soon as they start sending media.

RjS

On Oct 17, 2009, at 12:22 PM, Christer Holmberg wrote:

>
> Hi,
>
>> One thing that didn't survive the rewrite that I think we should work
> back in is a note to implementors that an INFO might arrive from a  
> peer
> even before the first end-to-end provisional (because it
>> might win a race with an immediate 200 OK) and this is not an error.
>
> You gave this comment to me earlier, in your previous comments. I
> replied, but you never got back to me :)
>
> The idea is that the UAS can start sending INFOs once the dialog  
> (early
> or final) has been established from the UAS's perpective. If I  
> remember
> corretly, that occurs when the UAS receives an acknolwedgement  
> (PRACK or
> ACK) to the response which established the dialog. In that case there
> could be no race condition, because the UAS knows that the UAC has
> received the 18x/200 response.
>
> Regards,
>
> Christer
>
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Nov 2009 11:27:58 -0600

On 11/3/09 10:46, Nov 3, Robert Sparks wrote:
>  I suspect if there are every any packages for INFO, one of them might 
> expect to be able to send them

Think, in particular, of the DTMF transit case. As much as I dislike 
that particular use of INFO, it seems to be the dominant deployed use 
case. If you have a mismatch between when you can send RTP and when you 
can send INFO, you can end up with some unfortunate consequences.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 19:04:08 +0100

Hi, 

>>will send media immediately after the 183 or a 200 without waiting for

>>the associated PRACK or ACK and I rather expect they think the dialog 
>>(early or otherwise) has

>>text that says otherwise?
>>
>>expect to be able to send them as soon as they start sending media.
>
that particular use of INFO, it seems to be the dominant deployed use
case. If you have a mismatch between when you can send RTP and 
>when you can send INFO, you can end up with some unfortunate
consequences.

I am not arguing against the potential need to be able to start sending.

However, as far as I understand a UAS is not allowed to send a SIP
request (INFO, or whatever other request, except NOTIFY) in the
UAS-to-UAC direction until it has received an acknowledgement (PRACK or
ACK) that the early dialog has been established. If I'm wrong I will add
text as suggested by Robert.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 13:34:37 -0500

I agree that there will be some that will start sending INFO as soon as 
they have a place to send it. And I think that is ok. You don't really 
need the PRACK for that.

	Thanks,
	Paul

> If I'm wrong, the draft needs to say that very explicitly - things will 
> send
> media immediately after the 183 or a 200 without waiting for the associated
>> back in is a note to implementors that an INFO might arrive from a peer
>> The idea is that the UAS can start sending INFOs once the dialog (early
>> or final) has been established from the UAS's perpective. If I remember
>> corretly, that occurs when the UAS receives an acknolwedgement (PRACK or
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 13:35:54 -0500

> can send INFO, you can end up with some unfortunate consequences.

That may be true. But that seems like something for the individual I-P 
spec to address.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 03 Nov 2009 12:38:41 -0600

On 11/3/09 12:35, Nov 3, Paul Kyzivat wrote:
>> case. If you have a mismatch between when you can send RTP and when 
>> you can send INFO, you can end up with some unfortunate consequences.
>

I agree. But you don't want it to have to contravene normative language 
in the base INFO spec to do so.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 13:40:37 -0500

> text as suggested by Robert.

You are not allowed to send until there is at least an early dialog. For 
the UAC that is when it receives a response with a to-tag. It need not 
be reliable, or if it is, you don't need to wait for the PRACK and response.

For the UAS, its as soon as it receives the initial request with from-tag.

For instance, without 100rel, you can send an UPDATE as soon as you have 
received a 1xx with a to-tag.

The same should apply to INFO.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 20:06:42 +0100

Hi, 

>> ACK) that the early dialog has been established. If I'm wrong I will 
>> add text as suggested by Robert.
>
>You are not allowed to send until there is at least an early dialog.
For the UAC that is when it receives a response with a to-tag. It need
not be reliable, or if it is, you don't need to wait for the 
>PRACK and response.

Agree.

>For the UAS, its as soon as it receives the initial request with
from-tag.

Where is that specified? We normally refer to the rules for BYE when we
define new mid-dialog requests, but are you really allowed to send a BYE
at that point?

The UAC could still be re-transmitting the INVITE, and if the UAC
receives the INFO before a 18x the INFO would create the early dialog at
the UAC side. I thought we only allowed that for NOTIFY...

>For instance, without 100rel, you can send an UPDATE as soon as you
have received a 1xx with a to-tag.
>The same should apply to INFO.

Yes, the UAC can do that, but my issue is the UAS.

Regards,

Christer