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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

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


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

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic