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

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

Yes , but we use pre-conditions with the UPDATE(or may be PRACK) so that
the called party is not alerted till the early media is serially played
out according to q-value. So the called party can still decide which
device to answer from once he gets the alert 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 6:33 PM
To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks);
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Some thoughts on fixing early media

Ummm...  doesn't the called party get to decide which of his devices
answers first, not the caller?

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 24, 2006 12:55 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
>  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
> 
>  
> 
> > -----Original Message-----
> > 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)
> > Subject: RE: [Sipping] Some thoughts on fixing early media
> > 
> > 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.
> > 
> 
> 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.
> 
> <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>
> 
> > 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,
> > 
> > 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:
> > 
> > > 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
> > 
> > 
> > _______________________________________________
> > 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
> 

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 25 Jul 2006 09:03:01 -0400

Mike

> To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent 
> Networks); [email-masked]; [email-masked]
> 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.
> 
> <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. 
> 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). 
>         ----UPDATE(indicate finished all early media,maybe 
> new offer)------>
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>