Re: [MMUSIC] comments on draft-garcia-mmusic-sdp-collaboration-00

["Elwell, John" <john.elwell at siemens.com>]

Miguel,

See below.

John 

> -----Original Message-----
> From: mmusic-bounces at ietf.org 
> [mailto:mmusic-bounces at ietf.org] On Behalf Of Garcia, Miguel 
> (NSN - FI/Espoo)
> Sent: 18 March 2008 07:40
> To: Hadriel Kaplan
> Cc: Joerg Ott; IETF MMUSIC WG
> Subject: Re: [MMUSIC] comments on 
> draft-garcia-mmusic-sdp-collaboration-00
> 
> Inline
> 
> Hadriel Kaplan wrote:
> > 
> >> -----Original Message-----
> >> From: Miguel Garcia [mailto:Miguel.Garcia at nsn.com]
> >>
> >> Hadriel Kaplan wrote:
> >>> For one, I actually think it's architecturally unsound to 
> expect the
> >>> media plane to know squat about the SIP call-id, and 
> certainly not the
> >>> tags.  SIP is the rendezvous protocol of choice for you, 
> but there's no
> >>> reason the media mechanism couldn't use a different one 
> if warranted
> >>> someday.  (ie, it shouldn't be defining a SIP-only SDP attribute)
> >> Well, we are trying to correlate the media with the signaling. This
> >> requires a correlation mechanism of any kind, which 
> implies that the
> >> media plane must be aware of some piece of data from the 
> signaling plane.
> > 
> > Are you trying to correlate the media with the signaling 
> session, or with the media session?
> > By that I mean if the SDP contained a media session 
> identifier, is that good enough?
> 
> At this point, I think any kind of correlation will work. Perhaps 
> preferable with the media session, as you mentioned.
[JRE] Should it be with the entire session or with a particular m-line?
Depending on the answer the cookie could be a session level or a media
level attribute.

> 
> 
> > 
> >>> For another, there are middleboxes which change SIP 
> call-ids (and tags
> >>> for that matter), which will break it. (and no, it's not 
> just SBCs)
> >>> So I think if you need a session identifier at the media 
> plane, define
> >>> an SDP attribute that is one.  Like, oh, for example the already
> >>> existent o= line session-id... or a new one.  Maybe we 
> need a common
> >>> one, if multiple drafts are going this way?
> >> And those middleboxes that you refer earlier (including 
> also SBCs) do
> >> not change the o= line in SDP or "forget" to include unknown SDP
> >> parameters, right?
> >> I think any SBC in the path will create harm, no matter 
> which parameters
> >> we decided to use for the correlation.
> > 
> > It's a game of probabilities.  There are SBCs and B2BUA's 
> which have to know all SDP they see; or are provisioned to 
> work on a whitelist basis, only allowing SDP attributes they 
> are set to allow; or do so because they really are the 
> terminator of the media session (for example when doing transcoding).
> > 
> > However, for those types of SBCs, or when SBCs are 
> provisioned to act that way, they would need to add support 
> for this T.120 most likely anyway.  But I believe that type 
> of configuration is the minority, not majority. (though I 
> don't have a perfect view of what even my own customers 
> configure, let alone other SBC vendors)
> > 
> > There are SBC configurations which change the o= line 
> session id, because it has been found that one can fairly 
> accurately discern the endpoint vendor type based on that 
> field's contents.  Again I think it's a minority (maybe).  
> Using a new SDP attribute may be more successful.
> > 
> > The important thing though is not to make the T.120 
> behavior incompatible with what SBCs have to do - and that 
> includes topology hiding.  Using the SIP call-id is not the 
> type of thing that SBCs could go and stop changing if they 
> need to support T.120, because the Call-id has IP Addresses.  
> What we need to do is simply use something that is not 
> contradictory with their goals.  And my guess is doing so 
> will also happen to work through many currently deployed 
> configurations without changes, which is a good thing.
> 
> I think this is a fair requirement. So, any sort of magic cookie or 
> token expressed in SDP will make this work.
[JRE] I agree with Hadriel. Some end-to-end token, rather than call-ID,
would make it a lot more deployable.

> 
> > 
> > I'm not saying we need to support SBC environments, just 
> that I see no reason to explicitly make it NOT work in their 
> environments.  It's kinda like NATs - you can either try to 
> avoid things which you know will break, or you can knowingly 
> make a protocol not work through NATs.
> > 
> > -hadriel
> > 
> 
> /Miguel
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Siemens Networks     Espoo, Finland
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic