Subject: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS generated Early Media: EMIND)

From: "Brian Stucker" <[email-masked]>
Date: Mon, 20 Nov 2006 13:33:48 -0600

<<<Resending to correct format and snip extra content that was blowing
out the mailing list buffer>>>

Thanks for going through the proposal Siddhartha. I have had to keep
going back to make sure that I'm not restating RFC-3959 as I've gone
through this process. I also had at one point (if you go looking for
earlier incarnations of my early media draft you'll see this) thought
about marking up the SDP. There's some problems with this around a
proxy's ability to manipulate message bodies.
 
You did prompt me to try to simplify my thinking some more...
 
What I've done is essentially depricated early media. There's just media
now. Some of it may get played while another call is being setup. The
UAC gets back places that it may wish to contact (and some extra help in
knowing what the intended ordering was) to play or contact another
endpoint while an associated call is being established. The RTP payload
magic is just an extra little helper to know when to switch back to the
original call without suffering from clipping.
 
Early media is broken. It will always be broken. So let's get rid of it
and have 'associated media'. Essentially media that is related to
another call, but is a different priority. I think we could also use
this general model for other purposes, such as music on hold, or
periodic announcements during a call (ie. a tone that plays every so
often to denote some account balance remaining, etc). I'm sure there are
others (or will be).
 
This keeps the model much simpler. Every media stream should be signaled
separately. I'm not suggesting that we depricate forking, but instead to
not expect any media to necessarily be rendered prior to answer which is
what RFC-3261 says, but not what RFC-3960 intimates at times. Just that
we should get the guy in the middle out of the end-to-end SDP
negotiations.
 
I think this is a much more powerful architecture, and one that lets
everyone involved on both ends of the media stream know what the status
of that stream is at either end without having to introduce
complications into the basic call setup flow.
 
Regards,
Brian

_______________________________________________
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: "Siddhartha Bhakta" <[email-masked]>
Date: Tue, 21 Nov 2006 16:52:51 -0000

Brain,

Your proposal may simplify the Media server driven (early) media cases as
UAC shall send another INVITE to create early-media or associated-media
session. But we need to check whether basic purpose of early media shall be
achieved by your proposal or not. Apology in advance, if I am asking some
question which has been answered and concluded in past.

The early media in PSTN domain has following salient points,

	a) A tone/indication to the Calling party to indicate that your call
attempt is being honored by network. Call progress, Ringback tones are
serving that purpose. Without those, caller shall disconnect the call.

	b) Early media indicates whether voice path will be through once
Called side shall answer. If user can not hear the ringback tone
properly then typically Caller shall terminate the call. Therefore,
Caller shall not have to pay for a call that does not have good
quality. This indicates that early media and regular media should use 	the
same media path(Soure RTP IP/port, Dest RTP IP/port). That was the 	main
reason why ringback tone were generated by Called side exchange.

	c)The early media is not billed since it is there just to indicate
whether media path shall be through while Called party shall answer.
Typically early media is shall be one-way (Called side to calling
side). Since early media is not billed, there is chance that people 	may
mis-use it. To avoid the misuse, early media was one-way. In SIP
world the early media shall needs to be bothway just to avoid media
clipping in NATed environment. The early-media shall be clipped for
discovering media NAT pinhole(who cares about early media clipping). 	But
this shall ensure that regular 	media shall not be clipped.

If we forget about forking case then all the above points were complied by
very simple SIP call flow. The 18x contains same SDP as that of 200 OK. This
ensures that early media and regular media follow the same media path(point
b) above.
The point b) is very important from the NAT traversal point of view.
Otherwise, we shall experience the regular media clipping. The point c) was
implemented quite easily as typically Application server starts billing on
getting 200 OK of dialog initiating INVITE.

In your architecture you have to make sure that you are ensuring point b)
and point c). To satisfy the point b), your proposal shall have two dialogs
with same Media path. Will that create any problem? If any SBC is between
then two separate dialog shall have separate media paths.

It shall quite difficult to satisfy the point c) in your proposal. You need
to add some header, ext to indicate that a particular dialog is for
early-media/associated-media only so that Application server does not bill
it.

But I thought, the original intention was to take care early media in case
of forking. I don't think we have proposed any proper solution to take care
of that. The early media is broken in case forking if SIP user does not have
the conferencing ability(in that case, it can put all the early dialogs in
conference). So, let it be broken.

Can we introduce some SIP header or extension to indicate that a particular
dialog is a forked dialog so that Called party does not initiate early
media?
Let the calling side to play local ringtone for forking case as per the
local policy as specified in RFC3960. If SIP user have the conferencing
ability and wants to do the conferencing of all early media then it may
indicate so in the new SIP header or extension.

In summery, I am suggesting two things,
	1. Deprecation of Application Server Model and
	2. Avoid (inband) early media in case of forking if Calling user
does 	not have the ability to do conferencing of early media.

Any comment on this?

Thanks & Regards,
Siddhartha

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: 20 November 2006 19:34
To: Siddhartha Bhakta; [email-masked]; Francois Audet
Cc: [email-masked]
Subject: Deprication of Early Media (was RE: [Sipping] A Test Balloon For AS
generated Early Media: EMIND)

 

 

Regards,
Brian

---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 21 Nov 2006 14:05:08 -0600

Comments below. 

> From: Siddhartha Bhakta 

Thanks. :)

> 
> Your proposal may simplify the Media server driven (early) 
> media cases as UAC shall send another INVITE to create 
> early-media or associated-media session. But we need to check 
> whether basic purpose of early media shall be achieved by 
> your proposal or not. Apology in advance, if I am asking some 
> 	a) A tone/indication to the Calling party to indicate 
> that your call attempt is being honored by network. Call 
> progress, Ringback tones are serving that purpose. Without 
> those, caller shall disconnect the call.

Send the calling party a 180 Ringing and have it generate local ringback
(if necessary) ala RFC-3960.

> 
> 	b) Early media indicates whether voice path will be 
> through once Called side shall answer. If user can not hear 
> the ringback tone properly then typically Caller shall 
> terminate the call. Therefore, Caller shall not have to pay 
> for a call that does not have good

I'm not sure I followed all of that. I don't see how I'm degrading the
quality of the call.

The proposal allows multiplexing of media streams to the same SDP
offered IP/port of the originator (RTP payload types are used to figure
out which is which).

If the PSTN gateway has something other than ringback to generate, it
can use the proposal to setup a separate dialog for that early media if
it desires. Keep in mind, that PSTN gateway generated early media is
frequently broken when forking occurs as noted in RFC-3960 and
elsewhere. It can't be fixed unless the protocol that you're
interworking with can handle forking as well, which ISUP can't. 

> 
> 	c)The early media is not billed since it is there just 
> to indicate whether media path shall be through while Called 
> party shall answer.
> mis-use it. To avoid the misuse, early media was one-way. In 
> SIP world the early media shall needs to be bothway just to 
> avoid media clipping in NATed environment. The early-media 
> shall be clipped for

I think there's a bit of confusion here. I don't view all media that
arrives at the originator prior to the originator getting the 200 OK as
"early media". To my mind, there are three basic types of media:

- Early media: media that is generated by a device prior to a
terminating device sending a 200 OK to the INVITE.
- Transitional media: media that is generated after a terminating device
has sent the 200 OK to the INVITE, but arrives at the originator before
the 200 OK is received.
- Final media: media that is generated after a terminating device has
sent the 200 OK to the INVITE, and arrives at the originator after the
200 OK is received.

I'm talking about deprecating early media, not transitional or final
media. You have to send a 200 OK to send media and expect the originator
to do anything with it. They might render it if they're feeling nice
about it, but there's no guarantee that they're going to do anything
with it but drop it on the floor. This is what we have, in effect,
today. The difference is that I've given a way to create associated
transitional/final media streams that may get rendered during the time
period when "early media" would have been sent before.

> 
> If we forget about forking case then all the above points 
> were complied by very simple SIP call flow. The 18x contains 
> same SDP as that of 200 OK. This ensures that early media and 
> regular media follow the same media path(point
> b) above.
> Otherwise, we shall experience the regular media clipping. 
> The point c) was implemented quite easily as typically 
> Application server starts billing on getting 200 OK of dialog 
> initiating INVITE.

I'm not following. I'm setting up separate calls for each media stream.
I don't see how this complicates NAT traversal at all. You simply apply
the same technique (perhaps utilizing knowledge gained during the setup
of the original call, like gathering candidate addresses for ICE) to the
associated call.

I have yet to see an application server, or any server, that bills on
SIP signaling. Proxies do, however, start accounting based off of SIP
signaling. I think it's a trivial matter to craft the associated call
URI sent back in the Alert-Info header from the main call to identify
the media resource you wanted to contact, and have the accounting
mechanism mark the record accordingly so that downstream billing
processes treat this call as non-billable. 

> 
> In your architecture you have to make sure that you are 
> ensuring point b) and point c). To satisfy the point b), your 
> proposal shall have two dialogs with same Media path. Will 
> that create any problem? If any SBC is between then two 
> separate dialog shall have separate media paths.

You will have separate media paths today, that's part of the problem.
I'm not trying to solve end-to-end early media because it's my
contention that there are very few (or none) applications that allow
end-to-end early media to be heard anyhow. It's transitional and final
media that you wind up with. Any early media getting generated by a some
box in the middle of the signaling path is going to have a separate
media path to the originator.

> 
> It shall quite difficult to satisfy the point c) in your 
> proposal. You need to add some header, ext to indicate that a 
> particular dialog is for early-media/associated-media only so 
> that Application server does not bill it.

Nope. They look at where the URI routes to. You can fake out headers. If
the call is routing to a media server in the network to play "Mary Had a
Little Lamb" for the originator, then the network can mark the
accounting record accordingly. Besides, accounting is out of scope of
our specifications (but not outside of the design).

> 
> But I thought, the original intention was to take care early 
> media in case of forking. I don't think we have proposed any 
> proper solution to take care of that. The early media is 
> broken in case forking if SIP user does not have the 
> conferencing ability(in that case, it can put all the early 
> dialogs in conference). So, let it be broken.

It is fixed. The originator can contact each forked leg for their early
media in turn. 

> 
> Can we introduce some SIP header or extension to indicate 
> that a particular dialog is a forked dialog so that Called 
> party does not initiate early media?
> Let the calling side to play local ringtone for forking case 
> as per the local policy as specified in RFC3960. If SIP user 
> have the conferencing ability and wants to do the 
> conferencing of all early media then it may indicate so in 
> the new SIP header or extension.

??? No conferencing ability is necessary. I think you've missed my
point.

> does 	not have the ability to do conferencing of early media.

I am proposing deprecation of early media, period. Everything else falls
out from there.

> Subject: Deprication of Early Media (was RE: [Sipping] A Test 
> Balloon For AS generated Early Media: EMIND)
> 
> 
> This e-mail may contain confidential and/or privileged 
> information. If you are not the intended recipient (or have 
> received this e-mail in error) please notify the sender 
> immediately and delete this e-mail. Any unauthorized copying, 
> disclosure or distribution of the contents in this e-mail is 
> strictly forbidden.
> ---------------
> 
>