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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Jun 2006 20:43:39 +0300

Hi,

it seems that the discussions on this topic died somehow. Comments inline:

Ejzak, Richard P (Richard) wrote:
> 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

if the idea is to have a mechanism that does not work in the presence of
forking, this would need to be stated in the applicability statement. In
any case, given that most systems support forking (including the IMS),
assuming no forking may not be a valid assumption.

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

How are you going to enforce this in the network? When a proxy forks it
does not probably know whether or not each leg will reach an authorized UAS.

> 3) use SRTP on all dialogs

if the idea is to have a mechanism that only works when media security
is used, that would need to be stated in the applicability statement. In
any case, given that systems usually support plain RTP (including the
IMS), assuming media security may not be a valid assumption.

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

If a UAS sends early media without generating an answer, this would not
work. Also, if the UAS sends and receives media from different ports,
this would not work either.

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

if this is a media-stream thing, it should be encoded as 'a' lines in
the SDP, as opposed to p-headers in the SIP header.

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

My point was that you can include those policies *as examples*. That is,
the text should be clear that those are only possible policies folks may
want to use, but there may be more.

Thanks,

Gonzalo

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jun 2006 15:25:49 -0400

I just got to looking at the new version. It has cleaned up a number of 
things, and I find it improved because it is more up front about early 
media gating.

I still think there are major interoperability problems with 
implementations that don't understand this header. I would like to see 
an interop section in the document that investigates cases where only 
the calling side, or only the called side understands the header and is 
within the trust domain. I think that will bring to light issues that 
should be confronted.

The basic issue here is whether there can ever be an expectation that 
early media works in the absence of an extension like this. If the 
answer is "no" then this should probably be standards track rather than 
a P-header.

	Paul

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 23 Jun 2006 14:58:32 -0500

So, backward compatibility/interoperability is FINALLY an issue

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, June 23, 2006 3:26 PM
To: sipping
Cc: Ejzak, Richard P (Richard)
Subject: [Sipping] Continuing review of draft-ejzak-sipping-p-em-auth
now -01

	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 25 Jun 2006 22:17:40 -0500

> So, backward compatibility/interoperability is FINALLY an issue

more of a forward compatibility problem, really.

Lots of features require capability negotiation -- what we call a SIP  
"option tag". P-headers don't get option tags, because P-class  
extensions have to fall back to "normal" behavior if the P-header  
isn't supported. Only standards-track extensions can get option tags.

--
Dean