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

[Miguel Garcia <Miguel.Garcia at nsn.com>]

Hadriel Kaplan wrote:
> One note about the proposed T.120 encoding in this draft: it defines an SDP attribute for indicating the SIP call-id, from-tag, and to-tag.  This is the second time in the past couple weeks I've seen this idea (the other was mediactrl).  It's not good.
> 
> 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.
> 
> 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.

> 
> I also don't see what the field is used for when it's set to the dialog info.  The draft says the answerer verifies the attribute value by checking if a matching SIP dialog is found, but since that's in the SIP request carrying the SDP (because the draft says for the offerer to create it as such), what value is this? (wouldn't it always pass verification?)  I would expect verification to be something done in the T.120 connection layer itself, using the session info.

I agree with you that the explanation is lame. It goes in to the deeps 
of T.120. There is a parameter in T120 call ConferenceName that acts as 
some sort of conference identifier. This is the field that allows an 
endpoint to correlate the media plane with the signaling plane. That's 
the reason why the draft proposes that the T.120 session includes a well 
known ConferenceName.

/Miguel

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

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