Re: [sipcore] Requesting assist with expert review of media feature tag

[Christer Holmberg <[e-mail]>]

Hi,

>>> - it establishes a media-less INVITE dialog, for the purpose of 
>>> exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason 
>>> session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.
>>
>> the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag.
>
> I"m not questioning the general use of info packages. I'm questioning establishing an invite dialog usage with no intent to include
> media, with the sole intent of exchanging INFO messages as a form of session mode messaging. Way back during the time of SIMPLE, we 
> decided that it was bad to establish a messaging *session* over the sip signaling channel. At the time that alternative was via MESSAGE, but 
> using INFO doesn't change the argument. It is still bad.

I think this issue should have been raised when the Info package was registered. That's when one should look at how the Info Package is going to be used etc. I don't think it's fair to reject the media feature tag registration on such grounds at this point.

In my opinion it's about whether the media feature tag semantics is aligned with the rules for a media feature tag. In my opinion it is, as it only indicates support of a feature. It does NOT indicate do-what-I-mean, it does NOT assume anything from the remote party etc.

Regards,

Christer





>> - a new mechanism is introduced for passing alert indications, rather 
>> than reusing the defined mechanism of Alert-Info. (RFC3261 and 
>> RFC7462)
>
> The alertingPattern is an application level indication.
>
> The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request.

I still don't understand. Is this alerting, in concept, any different from that which Alert-Info is intended for?

Is it that you want to alert for individual messages within a messaging session?

	Thanks,
	Paul

> Kind regards
>
> Ivo Sedlacek
>
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer
>
> -----Original Message-----
> From: sipcore [mailto:[e-mail]] On Behalf Of Paul 
> Kyzivat
> Sent: Monday, October 19, 2015 4:36 PM
> To: SIPCORE
> Subject: [sipcore] Requesting assist with expert review of media 
> feature tag
>
> I'm the designated expert reviewer for IANA registration of new media 
> feature tag values. (Often for use as sip caller capabilities.)
>
> I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first.
>
> The request comes from 3gpp - it has had no action in ietf. It is for 
> the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 
> 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using 
> IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”)
>
> It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are:
>
> - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.
>
> - a new mechanism is introduced for passing alert indications, rather 
> than reusing the defined mechanism of Alert-Info. (RFC3261 and 
> RFC7462)
>
> My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage.
>
> 	Thanks,
> 	Paul
>

_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore