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

From: <[email-masked]>
Date: Thu, 3 Aug 2006 08:55:31 +0530

Hi Sayan,

Would it not be the UAS's responsibility to decide that the user should
be alerted only after the Early Media is played?
I think that the UAS which has early media to play, can decide to
postpone the alerting till it has been sent to the UAC. UAC need not
have to control this - I think this should satisfy all the use cases
needed. (for example "please hang-up in ten seconds from now unless you
wish to be billed a huge amount" or something like that should be played
before UAS alerts the user.)

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 11:21 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
> 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
> 
> 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
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: Tuesday, July 25, 2006 8:03 AM
> > To: Stucker, Brian (RICH1:B620)
> > Cc: Christer Holmberg (JO/LMF); Dean Willis; Stephen Sprunk; sipping
> > Subject: Re: [Sipping] Some thoughts on fixing early media
> > 
> > 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:
> > > 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,
> > > 
> > >> I'm proposing that the far end would not alert until 
> permission to 
> > >> send
> > > 
> > >> media had been granted.
> > > 
> > > 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,
> > > 
> > > 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
> > > 
> > 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Wed, 2 Aug 2006 22:51:27 -0500

Ok, so...

I have a call that forks. The first guy starts sending me colorful
ringback, the second guy sends me "please hang up or I'm about to bill
you a huge amount in 10 seconds". According to common practice with UAC
design, it plays neither early media and instead generates local
ringback.

You never hear the warning, the colorful ringback service is broken and
the originator gets billed a huge amount, but the terminator didn't
alert until after the warning was played. :)

If the UAC has no control, then the UAS has no guarantee that what
they're wanting to send will get presented to the originator.

Regards,
Brian 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, August 02, 2006 11:26 PM
> To: [email-masked]; Stucker, Brian (RICH1:B620); 
> [email-masked]
> Would it not be the UAS's responsibility to decide that the 
> user should be alerted only after the Early Media is played?
> I think that the UAS which has early media to play, can 
> decide to postpone the alerting till it has been sent to the 
> UAC. UAC need not have to control this - I think this should 
> satisfy all the use cases needed. (for example "please 
> hang-up in ten seconds from now unless you wish to be billed 
> a huge amount" or something like that should be played before 
> UAS alerts the user.)
> 
> Regards,
> Ravi.
> 
> 
> --
>  
> Ravishankar. G. Shiroor
> > 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 
> > Do we need a confirm-status mechanism as well wherein the 
> UAC can tell 
> > when to alert the UAS ?
> 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
> > 
> that to the 
> > text, actually, since I think it deserves being called out.
> > 
> 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: <[email-masked]>
Date: Thu, 3 Aug 2006 10:05:14 +0530

I am assuming that we will go with the option that the early medias will
be played sequentially as per your suggestion.
The thing I am suggesting is that the alerting-the-user need not be
controlled by the UAC, but it is can be controlled by UAS, as it has
enough information to make that decision.
According to the q value set, either the colorful ringtone or "please
hangup.." will be played first.
Whichever UAS finishes playing the early media first (according to the q
value set), will start alerting the user.

--
 
Ravishankar. G. Shiroor

> From: Stucker, Brian (RICH1:B620) [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 9:21 AM
> To: RaviShankar Shiroor (WT01 - Product Engineering 
> Solutions); Sayan Chowdhury (WT01 - IP-Multimedia Carrier & 
> Ent Networks); [email-masked]
> I have a call that forks. The first guy starts sending me 
> colorful ringback, the second guy sends me "please hang up or 
> I'm about to bill you a huge amount in 10 seconds". According 
> to common practice with UAC design, it plays neither early 
> media and instead generates local ringback.
> 
> You never hear the warning, the colorful ringback service is 
> broken and the originator gets billed a huge amount, but the 
> terminator didn't alert until after the warning was played. :)
> 
> If the UAC has no control, then the UAS has no guarantee that 
> what they're wanting to send will get presented to the originator.
> 
> Regards,
> Brian 
> 
> > Would it not be the UAS's responsibility to decide that the user 
> > should be alerted only after the Early Media is played?
> > needed. (for example "please hang-up in ten seconds from now unless 
> > you wish to be billed a huge amount" or something like that 
> should be 
> > played before UAS alerts the user.)
> > 
> > Regards,
> > Ravi.
> > 
> > 
> > --
> >  
> > Ravishankar. G. Shiroor

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 3 Aug 2006 07:46:01 +0200

Hi Brian,

I think there are two issues.

One is that the UAC gives permission to the UAS to play early media.
But, once that permission is given I am not sure the UAC needs to give
the UAS permission to alert the user. I think, as Ravinhankar said, it's
an UAS implementation issue when it alterts the user.

Also, even if the UAS is NOT given permisson to play early media (or,
the UAC indicates it won't listen to it), I think it's an UAS
implementation issue whether it "waits" for permission, or alterts the
UAS anyway, depending on the importance of the early media that the UAS
would have wanted to play. 

So, if a UAS would like to send a "please hang up or I'll bill you a
huge amount in 10 seconds" early media message, but is not given
permission to do so, I guess it should not wait for permission more than
10 seconds, but instead send an error response.

Regards,

Christer

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: 3. elokuuta 2006 6:51
To: [email-masked]; [email-masked];
[email-masked]
Cc: Christer Holmberg (JO/LMF); [email-masked];
[email-masked]
Subject: RE: [Sipping] Some thoughts on fixing early media

Ok, so...

Regards,
Brian 

> you wish to be billed a huge amount" or something like that should be

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 07:11:49 -0500

Ah, sorry... misunderstood you.

Yes, I think existing mechanisms (ie. preconditions) should be
acceptable to control any alerting behavior. 

Regards,
Brian

> Sent: Thursday, August 03, 2006 12:35 AM
> To: Stucker, Brian (RICH1:B620); [email-masked]; 
> [email-masked]
> I am assuming that we will go with the option that the early 
> medias will be played sequentially as per your suggestion.
> The thing I am suggesting is that the alerting-the-user need 
> not be controlled by the UAC, but it is can be controlled by 
> UAS, as it has enough information to make that decision.
> According to the q value set, either the colorful ringtone or 
> "please hangup.." will be played first.
> Whichever UAS finishes playing the early media first 
> (according to the q value set), will start alerting the user.
> 
> --
>  
> Ravishankar. G. Shiroor
> Solutions); Sayan 
> > Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks); 
> > [email-masked]
> > you a huge amount in 10 seconds". According to common practice with 
> > UAC design, it plays neither early media and instead 
> generates local 
> > ringback.
> > 
> > You never hear the warning, the colorful ringback service is broken 
> > and the originator gets billed a huge amount, but the terminator 
> > didn't alert until after the warning was played. :)
> >

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 07:18:22 -0500

Yes, I misunderstood his comment to mean that existing mechanisms would
work for early media.

I agree, unless someone can show me a use case where the UAC must
control the alerting of the UAS in the context of early media, I'll
include it. Otherwise I'll update the draft in the next revision to
spell out the interaction and specify that it's up to the UAS to decide
how long to queue for.

Regards,
Brian 

> Sent: Thursday, August 03, 2006 1:46 AM
> To: Stucker, Brian (RICH1:B620); 
> [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> But, once that permission is given I am not sure the UAC 
> needs to give the UAS permission to alert the user. I think, 
> as Ravinhankar said, it's an UAS implementation issue when it 
> alterts the user.
> 
> Also, even if the UAS is NOT given permisson to play early 
> media (or, the UAC indicates it won't listen to it), I think 
> it's an UAS implementation issue whether it "waits" for 
> permission, or alterts the UAS anyway, depending on the 
> importance of the early media that the UAS would have wanted to play. 
> 
> So, if a UAS would like to send a "please hang up or I'll 
> bill you a huge amount in 10 seconds" early media message, 
> but is not given permission to do so, I guess it should not 
> wait for permission more than 10 seconds, but instead send an 
> error response.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 08 Aug 2006 09:06:58 -0400

This is a little bit of a tangent, but the idea that "hang-up or be 
billed" messages are a driver for allowing early media is a little 
distasteful to me -- Such messages aren't media (they're not the 
"content" of the call), but rather signaling messages sent as an audio 
stream.  It seems to me like ideally, such a message would be sent as a 
1XX response (possibly with the audio included in the body?).  This 
would take a little more smarts in a PSTN gateway, but it doesn't seem 
like an insurmountable problem.

Does this line of thinking seem reasonable?

Thanks,
--Richard

---

From: <[email-masked]>
Date: Tue, 8 Aug 2006 18:43:41 +0530

Hello Richard , 
I think there are a a few difficulty in such an approach
For one thing the early media may not be only "hang up or be billed"
kind of thing , 
It can be a a two way stream collecting some user input as in-band DTMF
... i.e. two way 
There can be several other kinds as Brian mentions in his draft. 

Also at the PSTN gateway it may be very difficult(if not impossible) to
interpret and/or include the audio stream in some kind of signaling
message , specialy if the gateway is "distributed" in an MGC-MG
architecture. In that case the signaling entity will not be on the media
plane at all ... 
Regards ,
Sayan 

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 6:37 PM
To: RaviShankar Shiroor (WT01 - Product Engineering Solutions)
Cc: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sipping] Some thoughts on fixing early media

Thanks,
--Richard

[email-masked] wrote:
>> 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

>> Yes, this is pretty much what's going to happen. I'll add that to the

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