Subject: RE: [Sipping] Some thoughts on fixing early media

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 23 Jul 2006 08:14:29 +0300

Hi Brian,

What if an UAS wants to send 200 OK (and media) before the UAC has told him it's ok to send media? Someone would have to send an UPDATE, to switch the media to sendrecv. 

Or, are you proposing that the UAS, until it's given permission to send media, wouldn't even alert the user behind it?

Regards,

Christer

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 23 Jul 2006 13:07:38 -0500

On Jul 23, 2006, at 12:14 AM, Christer Holmberg wrote:

> Hi Brian,
>
> What if an UAS wants to send 200 OK (and media) before the UAC has  
> told him it's ok to send media? Someone would have to send an  
> UPDATE, to switch the media to sendrecv.
>

That's the design goal here, I think -- giving the UAC an opportunity  
to consider and accept, defer, or reject media, be it early or  
otherwise.

> Or, are you proposing that the UAS, until it's given permission to  
> send media, wouldn't even alert the user behind it?

I suppose that would depend on the nature of the UAS. But if we made  
this assumption in all cases, it seems like this would let us fix the  
forking-to-multiple-answers problem. We've more or less found away  
for a UAC that care to serialize its forking,  even if its proxy  
forks parallel.

If we couple this to some sort of indicator to the UAC about what the  
media (especially early) flow is (I mean, how it is being used, or at  
least whether or not is required for normal operation)) we might have  
a fairly complete solution set for the problem.

I haven't thought this entirely through, but I believe it also  
reduces the attack scenario that Jonathan Rosenberg calls the "voice  
hammer", which basically involves sending an INVITE (probably with a  
spoofed source)  that includes an SDP offer pointing at the victim.  
If the recipient of the INVITE starts blasting media out according to  
that SDP, the victim gets sprayed with RTP packets, and (outside of  
an ICMP source quench, which never works anyhow) has basically no way  
to tell the sender to stop -- something like a 1,000 to 1 amplifier  
that also allows anonymous attacks. I believe Brian's model in effect  
requires verified return-routability before transitioning to active  
media. This doesn't prevent the attack, but at least prevents the  
typical use of a spoofed source address. If we were to couple this to  
another requirement that signaling and media be at the same IP  
address (sorry, softswitch vendors), we'd have a fairly complete  
answer to the voice hammer, since spoofing with return routability is  
MUCH harder than simple source spoofing.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Sun, 23 Jul 2006 15:02:38 -0500

I'm proposing that the far end would not alert until permission to send
media had been granted. 

Regards,
Brian 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Sunday, July 23, 2006 12:14 AM
To: Stucker, Brian (RICH1:B620); Dean Willis; Stephen Sprunk
Cc: sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

Hi Brian,

What if an UAS wants to send 200 OK (and media) before the UAC has told
him it's ok to send media? Someone would have to send an UPDATE, to
switch the media to sendrecv. 

Or, are you proposing that the UAS, until it's given permission to send
media, wouldn't even alert the user behind it?

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 24 Jul 2006 00:18:28 +0200

Hi,

>to consider and accept, defer, or reject media, be it early or 

That doesn't automatically mean that a UAS shouldn't be able to send 200 OK and media  (without first sending, or expeciting others to send, UPDATEs etc) when it acceptes a call. Just because an UAS may ask for permisson to send early meida I don't think a UAS should have to ask for permission to answer a call (and send "real" media).
 
I think a UAS shall not have to delay a 200 OK, and once a 200 OK is sent the UAS should be allowed to send media. Otherwise we'll end up with clipping problems.

>for a UAC that care to serialize its forking,  even if its proxy 

It's a question on how far you want to go. Do you want all UASs to receive the INVITE at once (in case of parallel forking), but not allow them to start sending early media until permission has been given? OR, do you want the UAS to not even alert the user before it has given permission to do so (I think this is what Brian proposes?

>media.
>This doesn't prevent the attack, but at least prevents the 

Well, I guess I don't speak only for myself when I am saying that such single address requirement is not acceptable :)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 24 Jul 2006 00:19:46 +0200

Hi,

>I'm proposing that the far end would not alert until permission to send

That's called pre-conditions, isn't it? :)
 
Or, you could also send an INVITE WITH SDP, but the UAS would not altert the user until some other type of indicator has been sent to it.
 
Regards,
 
Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Sunday, July 23, 2006 12:14 AM
To: Stucker, Brian (RICH1:B620); Dean Willis; Stephen Sprunk
Cc: sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

Hi Brian,

Regards,

Christer

---

From: "Brian Stucker" <[email-masked]>
Date: Sun, 23 Jul 2006 18:30:40 -0500

Yes, I think you understand what I am suggesting.

Regards,
Brian 

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Sunday, July 23, 2006 5:20 PM
To: Stucker, Brian (RICH1:B620); Dean Willis; Stephen Sprunk
Cc: sipping
Subject: VS: [Sipping] Some thoughts on fixing early media

Hi,

 
Or, you could also send an INVITE WITH SDP, but the UAS would not altert
the user until some other type of indicator has been sent to it.
 
Regards,
 
Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Sunday, July 23, 2006 12:14 AM
To: Stucker, Brian (RICH1:B620); Dean Willis; Stephen Sprunk
Cc: sipping
Subject: RE: [Sipping] Some thoughts on fixing early media

Hi Brian,

Regards,

Christer

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 24 Jul 2006 09:18:37 +0200

> I haven't thought this entirely through, but I believe it also  reduces 
> the attack scenario that Jonathan Rosenberg calls the "voice  hammer", 
> which basically involves sending an INVITE (probably with a  spoofed 
> source)  that includes an SDP offer pointing at the victim.  If the 
> recipient of the INVITE starts blasting media out according to  that SDP, 
> the victim gets sprayed with RTP packets, and (outside of  an ICMP source 
> quench, which never works anyhow) has basically no way  to tell the sender 
> to stop -- something like a 1,000 to 1 amplifier  that also allows 
> anonymous attacks. I believe Brian's model in effect  requires verified 
> return-routability before transitioning to active  media. This doesn't 
> prevent the attack, but at least prevents the  typical use of a spoofed 
> source address. If we were to couple this to  another requirement that 
> signaling and media be at the same IP  address (sorry, softswitch 
> vendors), we'd have a fairly complete  answer to the voice hammer, since 
> spoofing with return routability is  MUCH harder than simple source 
> spoofing.

Some random thoughts on this:

- this scenario assumes that all RTP transmitters are not evil but simply 
ignorant, right?
- Sounds like you would need the RTCP equivalent of "please stop sending". 
RTCP BYE only means that its originator will stop?
- Perhaps we could have some mechanism to determine the SIP signalling 
address from the received RTP (or RTCP)? Then the victim could send SIP BYE
- return routeability: receiving a PRACK on your Contact can provide the 
same, in combination with a unique 'grid' parameter (from GRUU). This also 
avoids the extra round trip
- could we put challenges in 1xx responses, with the challenge response 
either in ACK or in PRACK (for 100rel)?
- sending 401 has HERFP potential. So you would need a Require to ensure 
that other endpoints don't proceed with 2xx

Regards,

Jeroen

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 24 Jul 2006 07:55:16 -0500

Alrighty,

I got a few moments to sit down and try to write some of this out. I
invite interested parties to take a look at:

http://ietf.obsidian97.dyndns.org/drafts/draft-stucker-sipping-early-med
ia-coping-00.txt

It should be posted to the regular drafts repository soon, but in the
meantime you can paruse the above if you like. I tried to capture the
various types of early media, how different systems tend to cope with
it, requirements that seem to be a common theme in discussions, and a
mechanism to address the problem.

I didn't have access at the time to the complete SIPPING email thread,
so if I missed something, please let me know. It's not on purpose.

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Sunday, July 23, 2006 1:08 PM
To: Christer Holmberg
Cc: sipping
Subject: Re: [Sipping] Some thoughts on fixing early media

On Jul 23, 2006, at 12:14 AM, Christer Holmberg wrote:

> told him it's ok to send media? Someone would have to send an UPDATE, 
> to switch the media to sendrecv.
>

That's the design goal here, I think -- giving the UAC an opportunity to
consider and accept, defer, or reject media, be it early or otherwise.

I suppose that would depend on the nature of the UAS. But if we made
this assumption in all cases, it seems like this would let us fix the
forking-to-multiple-answers problem. We've more or less found away for a
UAC that care to serialize its forking,  even if its proxy forks
parallel.

If we couple this to some sort of indicator to the UAC about what the
media (especially early) flow is (I mean, how it is being used, or at
least whether or not is required for normal operation)) we might have a
fairly complete solution set for the problem.

I haven't thought this entirely through, but I believe it also reduces
the attack scenario that Jonathan Rosenberg calls the "voice hammer",
which basically involves sending an INVITE (probably with a spoofed
source)  that includes an SDP offer pointing at the victim.  
If the recipient of the INVITE starts blasting media out according to
that SDP, the victim gets sprayed with RTP packets, and (outside of an
ICMP source quench, which never works anyhow) has basically no way to
tell the sender to stop -- something like a 1,000 to 1 amplifier that
also allows anonymous attacks. I believe Brian's model in effect
requires verified return-routability before transitioning to active
media. This doesn't prevent the attack, but at least prevents the
typical use of a spoofed source address. If we were to couple this to
another requirement that signaling and media be at the same IP address
(sorry, softswitch vendors), we'd have a fairly complete answer to the
voice hammer, since spoofing with return routability is MUCH harder than
simple source spoofing.

--
Dean

_______________________________________________
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: <[email-masked]>
Date: Mon, 24 Jul 2006 20:01:45 +0530

Hi Brian , 

Thanks for the draft ... It was good to read of all the issues put in
one place .. 
I have couple of questions. 

how do we transition to final media ... 
suppose one of the the UA has successfully rendered one of the early
media streams 
but the final answer is from a different forked branch .. 
are we going to do another offer answer again using UPDATE ..this still
has the disadvantage of clipping. 

On early media class , When interworking with PSTN some element deep
inside the PSTN network may be 
sending the early media (for eg a PSTN based voice mail or a premium
phone no).. however the gateway which interfaces 
with the SIP network does not have an idea of what kind of early media
the PSTN element is going to play .. 
so it will be difficult for him to insert the early media class. max it
can do is indicate "early media is available" 
based on the progress indicator in the OBCI parameter of ACM/CPG. 

It may be difficult to address the full problem space with the
classification , because it may be difficult to do so totally on the
signaling path for all the involved elements ...

Regards ,
Sayan 

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 6:25 PM
To: Dean Willis; Christer Holmberg
Cc: sipping; Mary Barnes
Subject: RE: [Sipping] Some thoughts on fixing early media

Alrighty,

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Sunday, July 23, 2006 1:08 PM
To: Christer Holmberg
Cc: sipping
Subject: Re: [Sipping] Some thoughts on fixing early media

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 24 Jul 2006 09:40:54 -0500

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 9:32 AM
> To: Stucker, Brian (RICH1:B620); [email-masked]; 
> [email-masked]
> Cc: [email-masked]; Barnes, Mary (RICH2:B601)
> Thanks for the draft ... It was good to read of all the 
> issues put in one place .. 
> suppose one of the the UA has successfully rendered one of 
> the early media streams but the final answer is from a 
> different forked branch .. 
> are we going to do another offer answer again using UPDATE 
> ..this still has the disadvantage of clipping. 
> 

The current proposal in the draft, in the interest of avoiding as much
clipping as possible, is to revert to RFC-3261/3264 rules on answer. No
matter what you had negotiated for early media, when you see an endpoint
has answered the call, drop everything and start playing their packets.
This is essentially what the last paragraph in section 6.2.2 is all
about.

> based on the progress indicator in the OBCI parameter of ACM/CPG. 

That's correct, and there's nothing we can do about elements that can't
tell us what they're up. If all they can tell us is that they may have
early media available, then they'd probably need to use an
early-media-class set to "two-way" (because who knows) and some sort of
fairly high q-value (just in case they're sending us an advice of charge
announcement). Or we could ignore it in favor of other endpoints that
give us more information to work with. It's definitely open to debate.

> signaling path for all the involved elements ...

I don't expect that we'll be able to address the full problem space
because even without forking, if an endpoint isn't going to tell us what
it's up to, there's not much we can do about it but play dumb. This
point is acknowledged in the abstract, but probably deserves a larger
chunk of text than it was.

---

From: <[email-masked]>
Date: Mon, 24 Jul 2006 22:24:47 +0530

Some thoughts inline ... 

-----Original Message-----
From: Stucker, Brian (RICH1:B620) [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 8:11 PM
To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks);
[email-masked]; [email-masked]
Cc: [email-masked]; Barnes, Mary (RICH2:B601)
Subject: RE: [Sipping] Some thoughts on fixing early media

> media streams but the final answer is from a different forked branch 
> ..
> are we going to do another offer answer again using UPDATE ..this 
> still has the disadvantage of clipping.
> 

<sayan>
I misunderstood... I thought from that section that we are still
following the one answer to one offer rule.. 
With this proposal we have one offer two answers .. One for early media
and one for regular media. 
If my understanding is correct now and I consider this scenario  ,

1> The originating UAC is rendering the early media serially based on
the q value. 
2> Now one of UAS which was sending early media decides to send a final
response. 
3> The forking proxy forwards this to the UAC.
UAC lands up listening to the regular media from this source although
there were 2 or 3 other early media streams that were not rendered. 
Now , if it would have listened to all those sources it might have
selected a different UAS to 
receive regular media from and may be say billed less for the service or
received a better service(instead of getting forwarded to a voice mail
box from the home POTS phone , getting forwarded to the mobile from an
online SIP B2BUA on the network say). 
May be we can do a "pre-conditions like" flow to control this ?
Party A
Party B 
 
---INVITE(SDP1)-------------------------------------------------->
        <---
183(SDP2)-----------------------------------------------------
        ----UPDATE(indicate finished all early media,maybe new
offer)------>
        <------200 OK(UPDATE,may be new
answer)--------------------------- (alert user if not automata)
        <------180
Ringing(optional)--------------------------------------
        <---------200
OK(INVITE)------------------------------------------   
 
play regular media.

</sayan>

> forking-to-multiple-answers problem. We've more or less found away for

> a UAC that care to serialize its forking,  even if its proxy forks 
> parallel.
> 

> voice hammer, since spoofing with return routability is MUCH harder 
> than simple source spoofing.
> 
> 
> 
> --
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2006 09:03:25 -0400

If the UAC only gives permission to one tine of the fork to send media, 
and preconditions are used to prevent alerting until permission to send 
is granted, then parallel forking has been turned into serial forking 
under the control of the UAC.

While it seems a little odd, it is perhaps the best that can be done 
under the circumstances. It works well in that those destinations that 
don't require early media can all alert in parallel, and only the ones 
requiring early media are serialized. That is a huge improvement over 
the proxy making the choice, because it doesn't know which ones will 
require early media.

	Paul

---

From: <[email-masked]>
Date: Tue, 25 Jul 2006 19:13:21 +0530

Can there be an use case where it may be required to render two
different early media stream parallely coming from two different
branches of the fork(for example MSRP and video , the UAC can render
them parallely) ?
How will this solution work in such a case ? 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 6:33 PM
To: Brian Stucker
Cc: Dean Willis; sipping; Christer Holmberg (JO/LMF)
Subject: Re: [Sipping] Some thoughts on fixing early media

	Paul

Brian Stucker wrote:
> Or, you could also send an INVITE WITH SDP, but the UAS would not 
> altert the user until some other type of indicator has been sent to
it.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2006 10:04:10 -0400

> How will this solution work in such a case ?

It seems as though the UAC has full discretion on this. If it wants to 
accept media from multiple targets it is free to do so.

	Paul

>> From: Christer Holmberg (JO/LMF)
> 
>> [mailto:[email-masked]]
>>
> 
>>> I'm proposing that the far end would not alert until permission to
> 
>>> send
> 
>>> media had been granted.
> 
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
> 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
> 
> 
> www.wipro.com
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:27:24 +0200

Hi,
 
I had the same use-case in mind as Sayan.
 
Also, I don't think we should mix pre-conditions with early media. For example, there may be cases where one wants to make sure everything is ok (e.g. the pre-conditions are met), but still not allow early media to be sent at that point.
 
It is true that by "simulating" serial forking, as described by Paul, we make sure that only one UAS is alerting at a time, and therefor there is never even a theoretical chance of early media from multiple UASs. 
 
HOWEVER, I think that is too restrictive. Some UASs may not want to send early media, so we should have a mechanism that allows them to be contacted at the same time. The bad thing with serial forking is that it may take a while before the UAS that actually is going to answer the call is reached.
 
Regards,
 
Christer

________________________________

Lähettäjä: [email-masked] [mailto:[email-masked]]
Lähetetty: ti 25.7.2006 15:43
Vastaanottaja: [email-masked]; [email-masked]
Kopio: [email-masked]; [email-masked]; Christer Holmberg (JO/LMF)
Aihe: RE: [Sipping] Some thoughts on fixing early media

-----Original Message-----

        Paul

it.

www.wipro.com

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 25 Jul 2006 10:31:35 -0500

Yes, this is pretty much what's going to happen. I'll add that to the
text, actually, since I think it deserves being called out.

In cases where network interworking is not present (ie. no SIP-to-PSTN
type gateways are present in the routing tree) things will basically
behave as they always have been because most SIP endpoints do not
generate early media. It's services like CRBT and PSTN gateways that get
us into trouble. For the other endpoints we simply don't wish to clip
the media if possible. For the ones that do generate early media, we can
fork to them, but don't necessarily want to hear what they all have to
say in as a chorus.

Regards,
Brian

> Sent: Tuesday, July 25, 2006 8:03 AM
> To: Stucker, Brian (RICH1:B620)
> Cc: Christer Holmberg (JO/LMF); Dean Willis; Stephen Sprunk; sipping
> If the UAC only gives permission to one tine of the fork to 
> send media, and preconditions are used to prevent alerting 
> until permission to send is granted, then parallel forking 
> has been turned into serial forking under the control of the UAC.
> 
> While it seems a little odd, it is perhaps the best that can 
> be done under the circumstances. It works well in that those 
> destinations that don't require early media can all alert in 
> parallel, and only the ones requiring early media are 
> serialized. That is a huge improvement over the proxy making 
> the choice, because it doesn't know which ones will require 
> early media.
> 
> 	Paul
> 
> Brian Stucker wrote:
> > altert the user until some other type of indicator has been 
> sent to it.
> >  
> > Regards,
> >  
> > Christer
> >  
> > 
> >

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:32:15 +0200

Hi,

> accept media from multiple targets it is free to do so.

I thought the idea behind this discussion was to try to figure out a way how remote entities can be given permission to play early media, i.e. that the UAC can control (or at least request) what type of early media it wants, depending on the capabilities of the UAC (and the early media content, IF such information is available)

Regards,

Christer

        Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 25 Jul 2006 10:34:29 -0500

Yes, it would be free to do so since the emflow attribute is on a
per-flow basis. I thought about this when writing it up, and left it
open, but I couldn't think of a reasonable usecase that anyone is likely
to run across that would require it.

Specifically, I was thinking about what would happen if the UAC decided
to allow early video from one end-point and early audio for a different
one. You'd probably wind up with Mystery Science Theatre 3000 at the
UAC, which could be mildly entertaining, but probably not too useful. So
in practice, I don't envision this really occurring.

Regards,
Brian

> Sent: Tuesday, July 25, 2006 9:04 AM
> To: [email-masked]
> Cc: Stucker, Brian (RICH1:B620); [email-masked]; 
> [email-masked]; [email-masked]
> It seems as though the UAC has full discretion on this. If it 
> wants to accept media from multiple targets it is free to do so.
> 
> 	Paul
> 
> > If the UAC only gives permission to one tine of the fork to send 
> > media, and preconditions are used to prevent alerting until 
> permission 
> > to send is granted, then parallel forking has been turned 
> into serial 
> > forking under the control of the UAC.
> > 
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > The information contained in this electronic message and 
> any attachments to this message are intended for the 
> exclusive use of the addressee(s) and may contain 
> proprietary, confidential or privileged information. If you 
> are not the intended recipient, you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender 
> immediately and destroy all copies of this message and any 
> attachments.
> > 
> > 
> > WARNING: Computer viruses can be transmitted via email. The 
> recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any 
> damage caused by any virus transmitted by this email.
> > 
> > 
> > www.wipro.com
> > 
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:35:13 +0200

Hi,
 
Reading Brian's draft, I do NOT think it is what is going to happen.
 
Yes, it is possible to instruct only one UAS at a time to play early media, so from that perspective it is "serial".
 
But, all UASs will still receive the INVITE at the same time, so from that perspective it is still parallel forking.
 
Regards,
 
Christer

Lähettäjä: Brian Stucker [mailto:[email-masked]]
Lähetetty: ti 25.7.2006 17:31
Vastaanottaja: Paul Kyzivat
Kopio: Dean Willis; sipping; Christer Holmberg (JO/LMF)
Aihe: RE: [Sipping] Some thoughts on fixing early media

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 25 Jul 2006 10:38:57 -0500

I'm not mixing RFC-3312 preconditions with early media. The two can run in parallel as they are two different problem spaces (ie. QoS and early media staging). I think we're going to find that the types of boxes that typically have early media to stream are ones that will always have their QoS preconditions immediately met (because they're sitting in a core network somewhere).

As far as serial forking is concerned, the mechanism allows them all to be contacted at the same time per regular SIP routing. There's no change to SIP routing whatsoever, so whatever is there today, it's still there today. The early media that is coming back though is flow-controlled, so it's the delivery of the media that can be serialized if the UAC wants to do that. Do you have a usecase that requires the UAC to not serialize the media?

Regards,
Brian

> Sent: Tuesday, July 25, 2006 10:27 AM
> To: [email-masked]; [email-masked]; Stucker, 
> Brian (RICH1:B620)
> Cc: [email-masked]; [email-masked]
> Also, I don't think we should mix pre-conditions with early 
> media. For example, there may be cases where one wants to 
> make sure everything is ok (e.g. the pre-conditions are met), 
> but still not allow early media to be sent at that point.
>  
> It is true that by "simulating" serial forking, as described 
> by Paul, we make sure that only one UAS is alerting at a 
> time, and therefor there is never even a theoretical chance 
> of early media from multiple UASs. 
>  
> HOWEVER, I think that is too restrictive. Some UASs may not 
> want to send early media, so we should have a mechanism that 
> allows them to be contacted at the same time. The bad thing 
> with serial forking is that it may take a while before the 
> UAS that actually is going to answer the call is reached.
>  
> Regards,
>  
> Christer
> 
> Can there be an use case where it may be required to render 
> two different early media stream parallely coming from two 
> different branches of the fork(for example MSRP and video , 
> the UAC can render them parallely) ?
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> The information contained in this electronic message and any 
> attachments to this message are intended for the exclusive 
> use of the addressee(s) and may contain proprietary, 
> confidential or privileged information. If you are not the 
> intended recipient, you should not disseminate, distribute or 
> copy this e-mail. Please notify the sender immediately and 
> destroy all copies of this message and any attachments.
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 25 Jul 2006 10:41:16 -0500

That's what the currently proposed mechanism does. I see that the I-D
announcer still hasn't announced the draft (I believe the admin is on
vacation currently) so here's the link again...

Take a look at section 6, section 6.2 in particular.

Regards,
Brian

> Sent: Tuesday, July 25, 2006 10:32 AM
> To: Paul Kyzivat; [email-masked]
> [email-masked]
> I thought the idea behind this discussion was to try to 
> figure out a way how remote entities can be given permission 
> to play early media, i.e. that the UAC can control (or at 
> least request) what type of early media it wants, depending 
> on the capabilities of the UAC (and the early media content, 
> IF such information is available)
> 
> Regards,
> 
> Christer
> 
>  
> 
> 
> 
>         Paul
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:44:56 +0200

Hi Brian,
 
I KNOW it is what the draft does :) My response was towards Paul. But, I may have missunderstood him.
 
Also, the case where audio is coming from one place, and video from another, has been mentioned. Another case is when you only accept one early media type from a UAS, but when the session is fully established you will accept multiple ones.
 
Regards,
 
Christer

Lähettäjä: Brian Stucker [mailto:[email-masked]]
Lähetetty: ti 25.7.2006 17:41
Vastaanottaja: Christer Holmberg (JO/LMF); Paul Kyzivat; [email-masked]
Kopio: [email-masked]; [email-masked]
Aihe: RE: [Sipping] Some thoughts on fixing early media

Regards,
Brian

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:47:38 +0200

Hi Brian,
 
Again, I KNOW you are not missing preconditions (a'la 3312) with early media :) My comment was, again, to Paul, because my understanding was the he proposed that we solve the whole early media issue just by using preconditions. 
 
But, I appologize if I missunderstood him.
 
Regards,
 
Christer

Lähettäjä: Brian Stucker [mailto:[email-masked]]
Lähetetty: ti 25.7.2006 17:38
Vastaanottaja: Christer Holmberg (JO/LMF); [email-masked]; [email-masked]
Kopio: [email-masked]; [email-masked]
Aihe: RE: [Sipping] Some thoughts on fixing early media

Regards,
Brian

---

From: <[email-masked]>
Date: Tue, 25 Jul 2006 23:21:21 +0530

Hello Brian , 
I am trying to put a call flow here , (I will not try to draw as my mail
client is messing it up) 

1>Callee sends an offer with emflow=none 
2>gets back say two 183 responses (establishing early dialog) both with
early media class as two-way.
3>it selects the 183 with the higher q-value and more critical em class
and adds new offer in the PRACK with emflow as sendrecv.
4>PRACKs the other 183 as well but with emflow=none and gets back 200 OK
for that.
4>Gets back the answer in the 200 OK to PRACK for the 183 with higher
q-value.
5>Does early media. 
6>Sends an UPDATE to the next 183 with lower q-value with emflow as
sendrcv
... continues

If my understanding of the flow is correct , then in the above scenario
how does the UAC indicate to the UAS(s) 
not to alert the user until early media is over ? 

Do we need a confirm-status mechanism as well wherein the UAC can tell
when to alert the UAS ?
There may be use cases when the UAC wants to defer the alerting until
the UAC has heard all the early media "flows".
For eg , when the UAC chooses which UAS it wants to have a regular media
session with after hearing to all the early media sessions.

Regards ,
Sayan  

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 9:02 PM
To: Paul Kyzivat
Cc: Dean Willis; sipping; Christer Holmberg (JO/LMF)
Subject: RE: [Sipping] Some thoughts on fixing early media

Regards,
Brian

> media, and preconditions are used to prevent alerting until permission

> to send is granted, then parallel forking has been turned into serial

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 25 Jul 2006 13:09:35 -0500

Hello Sayan,

I'll be updating the draft to put in a better example to the call flow
this week. I wanted to get some feedback before I broke out the ASCII
art toolbox.

I believe your understanding of the flow is correct. Although for those
who have not read the draft and are reading this, I want to be clear
that there's no coupling with 100rel (so for those who do not like SDP
in the PRACK/200 exchange, there's no requirement that you have to do
this).

You bring up an interesting point around UAC control over UAS alerting
beyond early media. I think I need to add some text to cover this area
in my update.

My feeling is that giving the UAC the ability to delay alerting at the
UAS is all that's needed, not total control. This is due to the
beneficial effect that the delaying has for the UAS because it helps
ensure that the UASs early media is heard instead of being dropped and
since early media can be immediately interrupted by any given leg in the
route set answering the call.

The ability to choose from a set of UASs that present early media could
be tough to manage. Is the usecase you bring up one that you know to
exist today or one that you are concerned about existing in the future?

Regards,
Brian

> Sent: Tuesday, July 25, 2006 12:51 PM
> To: Stucker, Brian (RICH1:B620); [email-masked]
> Cc: [email-masked]; [email-masked]; 
> I am trying to put a call flow here , (I will not try to draw 
> as my mail client is messing it up) 
> 
> If my understanding of the flow is correct , then in the 
> above scenario how does the UAC indicate to the UAS(s) not to 
> alert the user until early media is over ? 
> 
> Do we need a confirm-status mechanism as well wherein the UAC 
> can tell when to alert the UAS ?
> There may be use cases when the UAC wants to defer the 
> alerting until the UAC has heard all the early media "flows".
> For eg , when the UAC chooses which UAS it wants to have a 
> regular media session with after hearing to all the early 
> media sessions.
> 
> Regards ,
> Sayan  
> 
> Yes, this is pretty much what's going to happen. I'll add 
> that to the text, actually, since I think it deserves being 
> called out.
> 
> In cases where network interworking is not present (ie. no 
> SIP-to-PSTN type gateways are present in the routing tree) 
> things will basically behave as they always have been because 
> most SIP endpoints do not generate early media. It's services 
> like CRBT and PSTN gateways that get us into trouble. For the 
> other endpoints we simply don't wish to clip the media if 
> possible. For the ones that do generate early media, we can 
> fork to them, but don't necessarily want to hear what they 
> all have to say in as a chorus.
> 
> Regards,
> Brian
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 25 Jul 2006 20:26:51 +0200

> I want to be clear

That's too bad - I was just considering a mechanism that works with current 
extensions, using just this:

1) UAC sends INVITE with Require: 100rel but without SDP
2) Each UAS sends back a 183 containing SDP, and a description of any early 
media (eg in regular SDP i= lines)
3) UAC sends PRACK to each UAS, muting the ones it does not want to hear 
just know

For (2) the UAS must not start ringing yet, and should not send 200 OK to 
the INVITE just yet either. Perhaps an extension token that does not add any 
protocol elements but just dictates behavior in this case could achieve this 
(ie Require: give-me-control-over-early-media)

For (2) it would be convenient to standardize some common types of early 
media, such that the UAC can use a pre-provisioned automatic answer (eg 
never play advertisements, always select direct conversation with target 
user, etc). This could also be placed in extensions to Content-Disposition 
(eg "Content-Disposition: session; type=announcement")

This would allow the UAC to pick the flows it likes, from multiple sources 
if desired. Then, to transition to the 'active' phase of the call, an UPDATE 
or reINVITE could be used (perhaps the latter to indicate 'start ringing, 
I've heard enough early media now')

Regards,

Jeroen

---

From: <[email-masked]>
Date: Wed, 26 Jul 2006 01:31:45 +0530

<sayan>

But at this stage the UAC does not know whether there is going to be early media or whether the INVITE is going to get forked at all. We will have to do a late start on all calls then ?

</sayan>

<sayan>

This part is pretty similar to the other approach ?  the a=emflow attribute matches with the muting stuff and early media class matches with the content-disposition stuff

</sayan>

Regards,

Jeroen

---

From: <[email-masked]>
Date: Wed, 26 Jul 2006 01:23:08 +0530

I put stuff inline ....

From: Stucker, Brian (RICH1:B620) [mailto:[email-masked]]
Sent: Tue 7/25/2006 11:39 PM
To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sipping] Some thoughts on fixing early media

Hello Sayan,

<sayan>

Yes , I agree that's the primary idea , even then say early media from one branch is being played , the UAS on the other branch has got emflow=none in the PRACK it received. So it does not know whether to alert the user or not as a new offer re-negotiating emflow may or maynot come. So , an indication from the UAC for delaying the alert on this branch may be helpful...

</sayan>

<sayan>

i was thinking of couple of services where it may be nice to choose between the UAS's playing early media 

1> The invite forks to three different gateways each playing an announcement that about the long distance rates through that gateway , it will be nice if the UAC can choose the cheapest one

2> invite forks to PSTN gateway and to a SIP B2BUA. PSTN plays annc "you will be connected to Bob's voicemail" ,B2BUA plays annc "press zero to be forwarded to Bob's mobile" 

It may be nice if UAC listen's two both the announcement before deciding what to do.

Although , even as I write I realize it's difficult if not impossible to do this , due to the serial nature of the media being rendered and if the flows are sendrecv(i.e the UAS is collecting inputs from the user) then the user will have to decide what to do even before he has gone through all the different early media announcements.

</sayan>

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 28 Jul 2006 10:44:24 -0500

An updated version of the draft with an additional mechanism for
correlating early media RTP with its SDP offer/answer has been added.
Clarifying text has been added to the mechanism.

Until the draft is announced by the I-D editor, you may find it at the
following link (there is a bug in the -01 draft in that the internal
revision number in the draft posted at this address is still -00 which
will be fixed later today).

ia-coping-01.txt

Regards,
Brian

> From: Stucker, Brian (RICH1:B620) 
> Sent: Tuesday, July 25, 2006 1:10 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> I'll be updating the draft to put in a better example to the 
> call flow this week. I wanted to get some feedback before I 
> broke out the ASCII art toolbox.
> 
> I believe your understanding of the flow is correct. Although 
> for those who have not read the draft and are reading this, I 
> want to be clear that there's no coupling with 100rel (so for 
> those who do not like SDP in the PRACK/200 exchange, there's 
> no requirement that you have to do this).
> 
> You bring up an interesting point around UAC control over UAS 
> alerting beyond early media. I think I need to add some text 
> to cover this area in my update.
> 
> My feeling is that giving the UAC the ability to delay 
> alerting at the UAS is all that's needed, not total control. 
> This is due to the beneficial effect that the delaying has 
> for the UAS because it helps ensure that the UASs early media 
> is heard instead of being dropped and since early media can 
> be immediately interrupted by any given leg in the route set 
> answering the call.
> 
> The ability to choose from a set of UASs that present early 
> media could be tough to manage. Is the usecase you bring up 
> one that you know to exist today or one that you are 
> concerned about existing in the future?
> 
> Regards,
> Brian
> 
> > I am trying to put a call flow here , (I will not try to draw as my 
> > mail client is messing it up)
> > 
> > If my understanding of the flow is correct , then in the above 
> > scenario how does the UAC indicate to the UAS(s) not to 
> alert the user 
> alerting until 
> > For eg , when the UAC chooses which UAS it wants to have a regular 
> > media session with after hearing to all the early media sessions.
> > 
> > Regards ,
> > Sayan
> > 
> that to the 
> SIP-to-PSTN 
> > generate early media. It's services like CRBT and PSTN 
> gateways that 
> > get us into trouble. For the other endpoints we simply 
> don't wish to 
> > clip the media if possible. For the ones that do generate 
> early media, 
> > we can fork to them, but don't necessarily want to hear 
> what they all 
> > have to say in as a chorus.
> > 
> > Regards,
> > Brian
> >