Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 1 May 2006 09:01:57 -0400

So you think early media sucks - got it.  :)

It definitely creates headaches, but making and receiving calls to/from the
PSTN using my sip phone is worth it.  We're not going to get complete
switchover to sip in one revolutionary day; we've got to bridge the 2 to get
an evolution.

Whether pstn-pstn transit calls over SIP has any IETF value/role is
controversial, but that's why I think handling it as a private extension
makes sense vs. a SIP RFC. (Personally I think getting transit traffic over
SIP will expedite migration)

-hadriel

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, April 29, 2006 7:11 AM
> To: 'Hadriel Kaplan'; 'Dean Willis'; [email-masked]
> Cc: 'Paul Kyzivat'; 'Sipping'
> Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
> xt
> 
> And here I though I was helping you :)
> 
> Let me be more clear:
>   I think early media, in all forms, is a bad idea
>      It was a mistake to allow early media
>   I think stopping early media, in any form, is a bad idea
>   I think creating new mechanisms to authorize or stop early media
>     is a bad idea.
> 
> Those that want to have, or not have, early media have tools.
> We don't need to create more tools.
> 
> 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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 2 May 2006 09:59:05 -0400

Juha,

No, Cisco is an equal opportunity vendor and does not subscribe to one
religion or another.  The only thing I see wasting BW on this list is
religious discussions.  There are real-world problems and differences of
opinion about how to solve that.  Opinions vary on that.  I have
opinions too, but that doesn't mean I need to be intolerant of others
ideas.

Mike

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Tuesday, May 02, 2006 12:56 AM
> To: Michael Hammer (mhammer)
> Cc: Hadriel Kaplan; Sipping; Dean Willis
> Subject: RE: [Sipping] Expert review of 
> draft-ejzak-sipping-p-em-auth-00.t xt
> 
> Michael Hammer (mhammer) writes:
> 
>  > The discussion needs to be in the place where the most 
> knowledgable  > (SIP-wise) folks are.  There is much value 
> for both sides to exchange  > ideas that may prompt new and 
> better approaches in both worlds.
> 
> machael,
> 
> 3gpp folks only come to ietf when they have some walled 
> garden problem to be solved.  they are not a bit interested 
> in making sip work the internet.  as the result, ietf mailing 
> list bandwidth is wasted on solving non-internet related problems.
> 
> but i guess most companies (cisco included, i just saw its IMS
> whitepaper) has already stopped believing open sip based 
> communication and we can merge ietf sip working groups with 
> those of 3gpp.
> 
> -- juha
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 10 May 2006 10:15:47 -0500

Hi Gonzalo,
Thanks for your comments.  My apologies for not responding to these points earlier.

Regarding how to distinguish between early media from multiple remote UASs and how to associate the early media with the correct dialog: The early media can be distinguished from one another since they should come from different address/port combinations.  But it appears to be difficult to associate each media stream with a specific dialog using RTP, since there does not appear to be a foolproof way to identify the source address/port for packets from the remote UAS, and no requirement that this source address/port be the same as the destination address/port for packets sent to the remote UAS.  In practice it is usually the case that one can assume that the remote source and destination address/port are the same, due to the design of most equipment and the use of NATs.  But from a specification perspective, a network needs to do one of the following:

1) disallow parallel forking via callerprefs
2) define an early media authorization policy and procedures that result in assigning the exact same authorization to all dialogs resulting from parallel forking.  (This is a change from my previous ill-considered response on this point.)  If the early media is authorized as a group, then follow RFC 3960 to decide how to handle the authorized streams, even though the streams cannot be associated with their corresponding dialogs.
3) use SRTP on all dialogs
4) we might include an option for a network to only allow traffic from remote address/port combinations that are identified in SDP as the destinations for traffic towards authorized remote endpoints (this does not mean that traffic towards the UASs need to be authorized).  It is not clear to me if including this option would violate any existing RFCs and I would appreciate your input on this.  This approach is clearly not foolproof, may inadvertently inhibit all early media, and may cause clipping.
5) other methods?

It is not surprising that early media authorization in the presence of parallel forking will usually work no better than early media handling for forking per RFC 3960.

Regarding your observation that media authorization should not be per dialog (as demonstrated clearly by considering forking) but rather per media stream: I agree completely (now).  The notion of creating a separate header parameter for each media line was suggested earlier during this thread.  I suggest that if more than one direction parameter exists in the header, they be understood to apply, in order, to the existing media lines in the SDP.  The last parameter would apply to all remaining m lines, if any.

I'm a bit concerned about leaving out all discussion of types of early media policy, although I have no problem trying to make the text more neutral.  I'm not sure how to motivate the need for the header without some discussion of policies.  This doesn't seem like a technical issue?

BR Richard

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, May 10, 2006 6:45 AM
> To: Gonzalo Camarillo
> Cc: Ejzak, Richard P (Richard); Cullen Jennings; Jon Peterson; 'Paul
> Kyzivat'; 'David R Oran'; Mary Barnes; sipping; Aki Niemi
> Subject: Re: [Sipping] Expert review of
> draft-ejzak-sipping-p-em-auth-00.txt
> 
> 
> Hi,
> 
> there have been plenty of discussions on whether or not what 
> this draft 
> is trying to do should be allowed or not. However, I do not see any 
> discussions on the technical points below.
> 
> I would like to see the questions below answered to 
> understand how you 
> intend to use this mechanism. For example, the type of 
> policies you can 
> implement depend heavily on which means you intend to use to 
> correlate 
> early media with early dialogs and where you intend to stop 
> unauthorized 
> media. I believe that your answers will help us have a clearer 
> understanding on the issues being discussed.
> 
> Thanks,
> 
> Gonzalo
> 
> Gonzalo Camarillo wrote:
> > Hi,
> > 
> > some comments on the draft under discussion.
> > 
> > RFC 3960 points out a few issues related to forking and 
> early media. 
> > This draft should address them. For example, it should 
> explain how user 
> > agents are supposed to correlate a particular SIP early 
> dialog with its 
> > media packets. That is, how to distinguish between the 
> early media sent 
> > by two remote UASs and how to associate it with their 
> respective SIP 
> > dialogs.
> > 
> > Regarding which entity is authorized to send backward early 
> media or 
> > receive forward early media, this does not seem like a per 
> dialog issue; 
> > it seems more a per media stream issue. For example, if I 
> have two media 
> > streams (audio and video), the IVR in the network may be 
> authorized to 
> > send me backward early media (audio), but the UAS is not 
> authorized to 
> > send me anything. However, since both media streams (audio 
> and video) 
> > were established with the same SIP early dialog, the P-Early-Media 
> > header field cannot provide this granularity. So, if early media is 
> > authorized for this early dialog, the UAS will be able to 
> send video... 
> > the draft should discuss the granularity the solution 
> should provide.
> > 
> > With respect to the policies the draft talks about, I do 
> not think it is 
> > necessary to spell them out. It would be better if the 
> draft only talked 
> > about early media that is authorized or unauthorized, and 
> the mechanism 
> > to achieve that distinction. Which types of early media a 
> domain may 
> > want or may not want to authorize (e.g., media from PSTN 
> gateways vs. 
> > media from UASs) can be left outside the scope of the draft.
> > 
> > Cheers,
> > 
> > Gonzalo
>