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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 18 Jul 2006 11:23:17 -0400

> I'd clearly trade a "Billing Starts" message for deprecating 
> early media.  Wouldn't even have to be a P-header.

Is this a new Method?

UAC ---BILLING ---> UAS
    <--200 OK ----

Mike

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 18:25:29 +0200

>>Sure, it could do that. Drawback is that you could loose other pending
> branches, if any (and proxy is not instructed >>otherwise)
>but since early media doesn't currently work with forking, what exactly
would be the drawback?

Isn't solving early media with forking one of the issues we're
discussing here?

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Jul 2006 11:49:12 +0300

Hi,

> I think many parts of your solution are ok - I've implemented similar
> things myself :) However, the only thing it generically solves is that
> media isn't mixed on the UAC side. I does not, for example, allow early
> media from multiple UAS entities.

We don't have the horsepower available to mix multiple incoming media streams, so we _have to_ pick one and stick with it.  Not that mixing is likely to produce good results anyways; how useful is hearing US and UK ringback mixed together?  Or someone's CRBT mixed with a standard land line ringback?  Forking and early media are fundamentally incompatible.

[CHH] I wasn't talking about mixing early media from multiple nodes, but to be abl to receive early media from one node, and then "switch" to early media from another node.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Jul 2006 23:07:52 +0300

Hi,

Is the do-not-alert-the-user until the early media has been played really part of the problem we're trying to solve ???

Regards,

Christer
________________ Reply Header ________________
Subject:	RE: [Sipping] Some thoughts on fixing early media
Author:	[email-masked]
Date:		25th July 2006 11:21:21 pm

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

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: Jeroen Van Bemmel <[email-masked]>
Date: Sat, 29 Jul 2006 17:05:11 +0200

Brian,

Some brief comments:

- I like explicit communication of ssrc. Perhaps it has broader application than only early media (eg conferencing)
- i don't see the value of the 'q' parameter, as they are uncoordinated. Each UAS (or proxy) will consider its early media most important, but what matters is what the UAC (user) prefers 
- i think 'advertisement' won't be used much. If I were an operator, I would set class to 'unknown' to ensure highest priority for my ad
- the use of Require for an SDP feature seems odd
- does emflow:none imply that the UAS must wait for ACK before sending RTP? After all, it could arrive as early media...you'd probably want to allow that, to prevent clipping

Regards,

Jeroen

-----Oorspronkelijk bericht -----
Van: "Brian Stucker" <[email-masked]>
Aan: "Brian Stucker" <[email-masked]>; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; christer.holmberg@ericssoncom
Verzonden: 28-7-06 17:44
Onderwerp: RE: [Sipping] Some thoughts on fixing early media

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

http://ietf.obsidian97.dyndns.org/drafts/draft-stucker-sipping-early-med
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]
> Hello Sayan,
> I'll be updating the draft to put in a better example to the