Re: MSRP switch question - H.248.69

Thanks Christian for your clarification.

I can understand that a device like media/conference server will take the
role of MSRP relay. What about BGF in the IMS network? It plays the role of
a session border controller. It is unlikely that a BGF will be used as a
conference server. It is just an intermediate device a IMS call must flow
through. In that scenario, is the BGF really acting as a MSRP relay as
specified in RCC 4976? Also, RFC 4976 mandated the TLS support. Is it
required for the BGF scenario? What if the endpoint does not support TLS? In
a pure peer-to-peer MSRP communication, TLS is not mandatory. A BGF is a
trusted network element in the IMS network and a user is sending a message
to another user in the network and is being forced to go thru the BGF. Does
it mean that TLS is forced on the connection?

Many thanks,
Ron

On Thu, May 21, 2009 at 9:56 PM, Christian Groves <
[email protected]> wrote:

> Hello Ron,
>
> This work stemmed from the work/requirements that 3GPP produced regarding
> MSRP. 3GPP TS23.333 and 29.333 contains more information regarding this:
> ftp://ftp.3gpp.org/specs/latest/Rel-8/23_series/23333-830.zip
> ftp://ftp.3gpp.org/specs/latest/Rel-8/29_series/29333-841.zip
>
> Regards, Christian
>
> Ron Ho wrote:
>
>> Hi All,
>>
>> I would like to learn more about the Megaco MSRP extension - H.248.69. I
>> am confused about the role of the MSRP switch.
>>
> [CNG] Section 3.2.3 gives a definition of "MSRP switch" its essentially a
> MSRP relay used for conferencing. Thus I would assume what is described in
> RFC4976 would largely apply. I think this should cover the question 1-3
> below.
>
>>
>> 1. Does the MG (aka the MSRP switch) has it own msrp uri? I assume it does
>> because the MG need to populate the a=path attribute in the local descriptor
>> in SDP. Am I right? I think it is needed for MG to send a message out. It
>> needs to populate the from-path msrp uri, correct?
>>
>> 2. When an endpoint send a message to another endpoint thru the MG (MSRP
>> switch), does it put the targeted endpoitn msrp uri or the MG's msrp uri
>> (the a=path that returned from the MG as the local descriptor in SDP)?
>>
>> 3. In H.248.69, it mentioned the MG is merely to relaying the message
>> between two or more terminations. Does it mean the message is passed from
>> one termination to the other termination as is keeping all the headers
>> identical? Or, does the MG need to create a new message but puting the
>> content of the receiving message there? Also, is the transaction in the
>> message to send out by the MG kept the same as in the received message if a
>> new message is created?
>> 4. H.248.69 allows playing of message from the MG to the termination. I
>> assume that the MG's msrp uri will be used in the from-path msrp uri field.
>> Right?
>>
> [CNG] Allows the MGC to request the MG to play a message from a
> termination?  Yes unless the MGC has specified something else in the message
> contents.
>
>>
>> 5. In section 13 of the extension (Messageing Filtering package), it
>> mentioned about incoming message in 13.1.1 and outgoing message in 13.1.3. I
>> am not entire clear about the defintion of incoming and outgoing message.
>> And it mentioned "User" in the 13.1.3 description. What is it refering to?
>> the endpoint? the MGC? or what?
>>
> [CNG] Think User = Termination, and that the Termination is a message box.
> Therefore messages that are received from other users (other terminations in
> the Context) are treated as incoming. Vice versa for outgoing message.
>
>>
>> 6. Is there any sample MSRP call flows/traces available for MSRP messages
>> flowing through the MG?
>> 7. Is there any sample Megaco call flows/trace avaiabel for the MSRP call?
>>
> [CNG] I only know of the 3GPP documents.
>
>>
>>
>> Thanks,
>> Ron
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Megaco mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>
>

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco