Subject: [Sipping] Clarification on RFC 3959 - early media

From: Kapil Nayar <[email-masked]>
Date: Thu, 3 Aug 2006 20:08:44 +0100 (BST)

Hi

The RFC mentions the 183-session progress to have both
the early-offer and the answer which is replied with
the early-answer in PRACK.

The RFC seems to imply that we DONOT need an answer
(SDP) in the 200-OK. 
Is it correct?

thanks,
-kapil

___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html

_______________________________________________
Sipping mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Aug 2006 09:20:41 -0400

> The RFC seems to imply that we DONOT need an answer

*IF* the offer/answer cycle has been *completed* prior to the sending of 
the 200 for the INVITE, then SDP need not be conveyed in the 200. To get 
in this situation requires the use of reliable provisional responses.

This is a complex subject. Aspects of it are spread across many RFCs, 
and much is underspecified. See draft-sawada-sipping-sip-offeranswer-01 
for a more complete specification.

	Paul

---

From: Kapil Nayar <[email-masked]>
Date: Tue, 8 Aug 2006 23:04:14 +0100 (BST)

Thanks Paul for the response...the draft does clarify
a lot of bits and pieces on the offer-answer model
spread out in various RFCs. When do we expect a formal
RFC?

1. Although, not specifically mentioned but 100rel
would be a must to support the RFC3959 for early
media? 
2. How does this RFC address the forking problem
w.r.t. early media - could you throw in some more
views?
3. Are there any other early media models being used
by products out there?

thanks,
-kapil nayar

		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 8 Aug 2006 17:10:38 -0500

You may wish to take a look at the following:

http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media-co
ping-01.txt

Regards,
Brian 

> -----Original Message-----
> From: Kapil Nayar [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 5:04 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Sipping] Clarification on RFC 3959 - early media
> 
> Thanks Paul for the response...the draft does clarify a lot 
> of bits and pieces on the offer-answer model spread out in 
> various RFCs. When do we expect a formal RFC?
> 
> 1. Although, not specifically mentioned but 100rel would be a 
> must to support the RFC3959 for early media? 
> 2. How does this RFC address the forking problem w.r.t. early 
> media - could you throw in some more views?
> 3. Are there any other early media models being used by 
> products out there?
> 
> thanks,
> -kapil nayar
> 
> > *IF* the offer/answer cycle has been *completed* prior to 
> the sending 
> > of the 200 for the INVITE, then SDP need not be conveyed in 
> the 200. 
> > To get in this situation requires the use of reliable provisional 
> > responses.
> > 
> Try the all-new Yahoo! Mail. "The New Version is radically 
> easier to use" - The Wall Street Journal 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 8 Aug 2006 17:11:53 -0500

Although if the offer/answer cycle has been completed, technically, SDP
in the 200 response is not required, due to various mechanisms that try
to deal (poorly) with early media that exist in the wild, NOT doing so
may frequently cause one-way voice to occur in the presence of forking.

Regards,
Brian 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 8:21 AM
> To: Kapil Nayar
> Cc: [email-masked]
> > The RFC mentions the 183-session progress to have both the 
> early-offer 
> > and the answer which is replied with the early-answer in PRACK.
> > 
> *IF* the offer/answer cycle has been *completed* prior to the 
> sending of the 200 for the INVITE, then SDP need not be 
> conveyed in the 200. To get in this situation requires the 
> use of reliable provisional responses.
> 
> This is a complex subject. Aspects of it are spread across 
> many RFCs, and much is underspecified. See 
> draft-sawada-sipping-sip-offeranswer-01

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Aug 2006 19:12:57 -0400

> may frequently cause one-way voice to occur in the presence of forking.

Brian,

You are talking about some UAC that is trying to cope with forking, 
chooses one fork to listen to, which turns out not to be the one that 
answers?

In that case the UAC *should* still maintain the proper offer/answer 
state machine for each fork, so that when it learns which fork *did* 
answer it will know what answer to work with henceforth.

If it doesn't, it can depend on the "answer" in the 200 only if that 
really is the answer - when there was no reliable provisional with the 
answer.

When the UAS has sent an answer in a reliable provisional, it *can* put 
a copy of it in the 200. That will probably do no harm if there has only 
been one offer and one answer. But if there has been another 
offer/answer exchange before the 200, then putting SDP in the 200 is 
really problematic. As we have tried to interpret 3261, in that 
circumstance the SDP in the 200 must be the *first* answer, which is not 
the correct one to be used at that time. The dumb UAC that depends on 
the SDP in the 200 will then malfunction. To make it work correctly, the 
UAS would have to put the final answer into the 200, which violates 
3261. In that case it seems safer to put nothing into the 200.

So, what do you suggest here?

I guess we could recommend that if there was an offer in the invite, and 
it was answered with a reliable provisional, and if there has been no 
subsequent offer/answer, then the 200 should contain a copy of the 
answer. Would that be better than recommending that the 200 never 
contain SDP when the offer/answer cycle has been completed?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Aug 2006 19:26:10 -0400

> would be a must to support the RFC3959 for early

What we have been discussing is all the gateway model described in 3960, 
not the application model addressed by 3959.

In theory I think you could use 3959 without using 100rel - using only 
UPDATE. In practice I doubt anyone supports only UPDATE and not 100rel.

(In practice, I wonder if anybody supports 3959.)

> w.r.t. early media - could you throw in some more

Offer/answer is complicated. Early media is complicated. And they are 
related. We are trying to keep the problem factored as best we can to 
retain some sanity. (Not sure how successful we are being in preserving 
sanity.)

The offer/answer draft addresses part of the early media problem when 
the gateway model is used, in that it helps understand how the 
offer/answer exchange progresses on each fork. It does not say anything 
about how the media from the multiple sessions, that might be negotiated 
because of forking, is rendered to the user.

> 3. Are there any other early media models being used

I fear there are as many models as products. That is why we are trying 
to get this stuff more formalized.

There is long discussion thread on early media, and there is another 
draft on early media coping.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 9 Aug 2006 08:46:28 +0200

Hi, 

>>Although if the offer/answer cycle has been completed, technically, 
>>SDP in the 200 response is not required, due to various mechanisms 
>>that try to deal (poorly) with early media that exist in the wild, NOT

>>doing so may frequently cause one-way voice to occur in the presence
of forking.
>You are talking about some UAC that is trying to cope with forking,
chooses one fork to listen to, which turns out not to 
>be the one that answers?
state machine for each fork, so that when it learns 
>which fork *did* answer it will know what answer to work with
henceforth.
>If it doesn't, it can depend on the "answer" in the 200 only if that
really is the answer - when there was no reliable 
>provisional with the answer.
>
a copy of it in the 200. That will probably do no 
>harm if there has only been one offer and one answer. But if there has
been another offer/answer exchange before the 200, 
>then putting SDP in the 200 is really problematic. As we have tried to
interpret 3261, in that circumstance the SDP in 
>the 200 must be the *first* answer, which is not the correct one to be
used at that time. The dumb UAC that depends on 
>the SDP in the 200 will then malfunction. To make it work correctly,
the UAS would have to put the final answer into the 
>200, which violates 3261. In that case it seems safer to put nothing
into the 200.
>I guess we could recommend that if there was an offer in the invite,
and it was answered with a reliable provisional, and 
>if there has been no subsequent offer/answer, then the 200 should
contain a copy of the answer. Would that be better than 
>recommending that the 200 never contain SDP when the offer/answer cycle
has been completed?

My proposal would be to say that the UAC, if it has already received an
answer, simply doesn't care about the SDP in the 200 OK. Then it doesn't
matter what the UAS sends, what recommendations the UAS follows, etc...

Regards,

Christer

	Paul

>> *IF* the offer/answer cycle has been *completed* prior to the sending

>> of the 200 for the INVITE, then SDP need not be conveyed in the 200. 

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

_______________________________________________
Sipping mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 17:57:16 -0400

> matter what the UAS sends, what recommendations the UAS follows, etc...

Yes, but there is a lot of broken stuff out there in the wild. And its 
not particularly surprising because this stuff is pretty confusing.

What the UAS does can enhance interop with UACs that are confused. And 
visa versa. Of course no single set of rules is going to make interop 
possible among all the confused and all the different ways they may be 
confused.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 18:28:52 -0400

Brian,

I just got around to looking at this. I need to think about the 
techniques you propose at the end. But I am having trouble getting past 
the first half of the document. I have never heard mention of the things 
you describe as Pre-routing early media or Pre-presentation early media. 
Nor have I heard of the Proxy-side coping mechanisms you describe.

These are all positively *obscene*. You suggest that these are common. 
Is that really true??? (Maybe you live in a particularly dangerous 
neighborhood.)

Tell me it isn't true! Please!

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Aug 2006 16:58:22 -0700

Not to mention they're really nasty with SRTP, and create another reason for
endpoints to allow RTP to be played while SRTP is being set up.

-d 

> Sent: Thursday, August 10, 2006 3:29 PM
> To: Brian Stucker
> Cc: [email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 11 Aug 2006 10:37:59 -0500

Pre-routing, pre-presentation, etc. are monikers that I came up with to
try to explain at which points early media can arise during processing.
The idea here is that all early media is not equal, some early media is
more evil than others.

I've seen all of the techniques mentioned in the draft in the wild. Many
of them are undetectable to the originating UA.

Regards,
Brian 

> Sent: Thursday, August 10, 2006 5:29 PM
> To: Stucker, Brian (RICH1:B620)
> Cc: Kapil Nayar; [email-masked]
> I just got around to looking at this. I need to think about 
> the techniques you propose at the end. But I am having 
> trouble getting past the first half of the document. I have 
> never heard mention of the things you describe as Pre-routing 
> early media or Pre-presentation early media.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Aug 2006 14:25:23 -0400

> try to explain at which points early media can arise during processing.

It isn't the names that bother me. (It's obvious you coined those.)
It's the behaviors described that are disturbing.

> I've seen all of the techniques mentioned in the draft in the wild.

Time to declare open season!
(Kill those nasty beasts before they hurt the children.)

(I wouldn't be killing any of my kin would I?)

> Many of them are undetectable to the originating UA.

Except that things work funny, or sometimes don't work.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 11 Aug 2006 13:56:37 -0500

> Sent: Friday, August 11, 2006 1:25 PM
> > Pre-routing, pre-presentation, etc. are monikers that I 
> came up with 
> > to try to explain at which points early media can arise 
> during processing.
> 
> It isn't the names that bother me. (It's obvious you coined 
> those.) It's the behaviors described that are disturbing.
> 
> > The idea here is that all early media is not equal, some 
> early media 
> > is more evil than others.
> > 

:)

I'm not interested in pointing fingers, I just want to get the problem
under control. To others who may have experience with early media, and
know of a mechanism that they've seen used that is not currently
documented in the draft, please email me so I can include it in the
discussion.

> Except that things work funny, or sometimes don't work.

True, but you have to keep in mind that many of the things that work
funny or don't work with early media are things that happen on behalf of
the terminator. How is the originator going to tell that the early media
the network is trying to provide from a PSTN gateway or some service for
the terminator is missing?

> >> techniques you propose at the end. But I am having trouble getting 
> >> past the first half of the document. I have never heard mention of 
> >> the things you describe as Pre-routing early media or 
> >> Pre-presentation early media.
> http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media
> >> -
> >>> co
> >>> ping-01.txt
> > 
>