Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 3 Jun 2013 19:22:33 +0000

Hi Christer,
Thanks for asking me to comment on 5.42.  First of all, I agree with all your other comments.  I would recommend that the category for all the items in 5.42 be listed as "SPECIAL" since more work would need to be done in 3GPP to specify their potential use with BUNDLE.  These attributes are all transport related but not in a way that can be easily captured by the category "TRANSPORT".

There are two typos in the table: "visited realm" should be "visited-realm" and the second occurrence of "omr-m-att" should be "omr-m-bw".

Richard

From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, May 31, 2013 2:33 AM
To: [email-masked]; [email-masked]; Ari Keränen; Flemming Andreasen ([email-masked])
Cc: Ejzak, Richard P (Richard)
Subject: Review of draft-nandakumar-mmusic-sdp-mux-attributes-02: sections 5.22, 5.40, 5.41, 5.42

Hi,

I was requested to review the attributes listed in sections 5.22, 5.40, 5.41 and 5.42.

However, first I have a general comment on the document:

For some attributes (e.g. MSRP-CEMA), there is note text saying:

"Not recommended due to legacy interop purposes"

Making such statements is completely outside the scope of the document. The document is about multiplexing, and how/if attributes are affected.

There is also similar note text saying:

"Not recommended due to interop purposes"

Now, for the 3GPP defined attributes you could say "Usage only defined for IMS", or something. But, again, it's not within the scope of this document to recommend against using things.

...unless, of course, there from a multiplexing perspective is a reason to do so, and they should be listed under the NOT RECOMMENDED category:

5.22

  +------------+---------------------------------+---------+----------+
   | Name       | Notes                           | Current | Category |
   +------------+---------------------------------+---------+----------+
   | msrp-cema  |                                 | M       | NORMAL   |
   |            |                                 |         |          |
   |            |                                 |         |          |
   +------------+---------------------------------+---------+----------+

5.40

   +-------------+--------------------------------+---------+----------+

   | Name        | Notes                          | Current | Category |

   +-------------+--------------------------------+---------+----------+

   | g.3gpp.cat  | Usage defined for the IP       | M       | NORMAL   |

   |             | Multimedia Subsystem [ref]     |         |          |

   |             |                                |         |          |

   +-------------+--------------------------------+---------+----------+

5.41

   +-------------+--------------------------------+---------+----------+

   | Name        | Notes                          | Current | Category |

   +-------------+--------------------------------+---------+----------+

   | g.3gpp.crs  | Usage defined for the IP       | M       | NORMAL   |

   |             | Multimedia Subsystem [ref]     |         |          |

   |             |                                |         |          |

   +-------------+--------------------------------+---------+----------+

5.42

This is actually an interesting one, and needs a little more investigation. So, I'll have to come back on that one. It would be good if Richard Ejzak, who is the "architect" behind the attributes, could take a look :)

  +------------------+---------------------------+---------+----------+

   | Name             | Notes                     | Current | Category |

   +------------------+---------------------------+---------+----------+

   | secondary-realm  | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | visited realm    | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-m-cksum      | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-s-cksum      | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-m-att        | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-s-att        | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-s-bw         | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-m-att        | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   | omr-codecs       | Usage defined for the IP  | M       | TBD      |

   |                  | Multimedia Subsystem [ref]|         |          |

   |                  |                           |         |          |

   +------------------+---------------------------+---------+----------+

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 5 Jun 2013 07:33:36 +0700

Richard, 

Could things like "visited realm" just need to be the same if using Bundle? What I mean is that if two m-lines had different "visited realm" values, then they could not be bundled? It seems unlikely to me they would have a different "visited realm" but I don't really understand all of this. 

Any advice you could give on what the values should be would be great. If more work is needed TBD may be the correct values but SECIAL would imply that there was text in some draft that said what to do and it was not one of the default actions. 

Thanks, Cullen

On Jun 3, 2013, at 1:22 PM, "Ejzak, Richard P (Richard)" <[email-masked]> wrote:

> Hi Christer,
> Thanks for asking me to comment on 5.42.  First of all, I agree with all your other comments.  I would recommend that the category for all the items in 5.42 be listed as “SPECIAL” since more work would need to be done in 3GPP to specify their potential use with BUNDLE.  These attributes are all transport related but not in a way that can be easily captured by the category “TRANSPORT”.
>  
> There are two typos in the table: “visited realm” should be “visited-realm” and the second occurrence of “omr-m-att” should be “omr-m-bw”.
>  
> Richard
>  
> “Not recommended due to legacy interop purposes”
>  
> “Not recommended due to interop purposes”
>  
> Now, for the 3GPP defined attributes you could say “Usage only defined for IMS”, or something. But, again, it’s not within the scope of this document to recommend against using things.
>  
> …unless, of course, there from a multiplexing perspective is a reason to do so, and they should be listed under the NOT RECOMMENDED category:
>  
>  
> 5.22
>  
> This is actually an interesting one, and needs a little more investigation. So, I’ll have to come back on that one. It would be good if Richard Ejzak, who is the “architect” behind the attributes, could take a look :)
>  
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 5 Jun 2013 13:42:08 +0000

Hi Cullen,
Having looked into it further, I would suggest that the "visited-realm" and "alternate-realm" attributes be assigned the TRANSPORT category.  They represent information similar to the candidate attribute and can be different across m lines as a result of various 3pcc scenarios.  IDENTICAL would not be appropriate.  The remaining attributes in 5.42 should be assigned the NORMAL category.

Thanks,
Richard

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2013 7:34 PM
> To: Ejzak, Richard P (Richard)
> Cc: [email-masked] WG; [email-masked]
> Subject: Re: [MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-
> attributes-02: sections 5.22, 5.40, 5.41, 5.42
> 
> 
> Richard,
> 
> Could things like "visited realm" just need to be the same if using
> Bundle? What I mean is that if two m-lines had different "visited
> realm" values, then they could not be bundled? It seems unlikely to me
> they would have a different "visited realm" but I don't really
> understand all of this.
> 
> Any advice you could give on what the values should be would be great.
> If more work is needed TBD may be the correct values but SECIAL would
> imply that there was text in some draft that said what to do and it was
> not one of the default actions.
> 
> Thanks, Cullen
> 
> 
> 
> 
> On Jun 3, 2013, at 1:22 PM, "Ejzak, Richard P (Richard)"
> <[email-masked]> wrote:
> 
> > Hi Christer,
> > Thanks for asking me to comment on 5.42.  First of all, I agree with
> all your other comments.  I would recommend that the category for all
> the items in 5.42 be listed as "SPECIAL" since more work would need to
> be done in 3GPP to specify their potential use with BUNDLE.  These
> attributes are all transport related but not in a way that can be
> easily captured by the category "TRANSPORT".
> >
> > There are two typos in the table: "visited realm" should be "visited-
> realm" and the second occurrence of "omr-m-att" should be "omr-m-bw".
> >
> > Richard
> >
> > Making such statements is completely outside the scope of the
> document. The document is about multiplexing, and how/if attributes are
> affected.
> >
> > Now, for the 3GPP defined attributes you could say "Usage only
> defined for IMS", or something. But, again, it's not within the scope
> of this document to recommend against using things.
> >
> > .unless, of course, there from a multiplexing perspective is a reason
> to do so, and they should be listed under the NOT RECOMMENDED category:
> >
> >
> > 5.22
> >
> >    |            |                                 |         |
> |
> >    |            |                                 |         |
> |
> >    |             |                                |         |
> |
> >    |             |                                |         |
> |
> > This is actually an interesting one, and needs a little more
> investigation. So, I'll have to come back on that one. It would be good
> if Richard Ejzak, who is the "architect" behind the attributes, could
> take a look :)
> >
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |
> >    |                  |                           |         |
> |