Subject: [Megaco] Remote desc in the reply to the MGC

From: "Ron Gilaad" <[email-masked]>
Date: Wed, 13 Jun 2007 01:35:35 +0300

Hi All

If the MGC request the MG to create media and includes both Local and
Remote desc in the request, shall the MG include both desc in the reply
or only the local desc?
In H.248 it is written that: The MG returns its selected alternative in
each of Local and Remote.
But, in the example in page 175 (when the MGC associate A5555 with a new
context on MG2, and establish an RTP
Stream) the MGC sends both local and remote desc, but the MG reply only
with the local.

Thanks in advance,

Ron
Ron Gilaad
RAD Data Communications.
24 Raoul Wallenberg St.
Tel Aviv 69719
Tel: 972-3-6455411 
mailto:[email-masked]

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Ashish Singh <[email-masked]>
Date: Tue, 12 Jun 2007 18:05:26 -0700

Hi Ron,

In case of RG= OFF and rv=oFF, If there are multiple alternatives in 
Remote descriptor and MG is selecting one alternative, then MG should 
return Remote descriptor.

In the example given in H.248.1, Remote desc is fully specified, thats 
why MG is not returning it in response.

-Ashish

Ron Gilaad wrote:
> Remote desc in the request, shall the MG include both desc in the 
> reply or only the local desc?
>
> In H.248 it is written that:_* The MG returns its selected alternative 
> in each of Local and Remote.*_
>
> But, in the example in page 175 (when the MGC associate A5555 with a 
> new context on MG2, and establish an RTP
>
> Stream) the MGC sends both local and remote desc, but the MG reply 
> only with the local.
>
> Thanks in advance,
>
> Ron
>
> Ron Gilaad
>
> RAD Data Communications.
>
> 24 Raoul Wallenberg St.
>
> Tel Aviv 69719
>
> Tel: 972-3-6455411
>
> _mailto:[email-masked]
>
>
> ------------------------------------------------------------------------
>

---

From: "Ron Gilaad" <[email-masked]>
Date: Wed, 13 Jun 2007 11:06:30 +0300

Hi Ashish,

Thanks for clarifying this.
Is it a must not to include the remote in case it is fully specified or
an option?

Regards,

Ron 

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 04:05
To: Ron Gilaad
Cc: [email-masked]
Subject: Re: [Megaco] Remote desc in the reply to the MGC

Hi Ron,

-Ashish

---

From: Ashish Singh <[email-masked]>
Date: Wed, 13 Jun 2007 10:33:17 -0700

Hi Ron,

H.248 mentions not to include descriptor in response if the descriptor 
is fully specified. This holds true for remote descriptor also. This is 
a recommendation by protocol. I am not very sure what will be MGC 
behavior if MG include it in response, as it is implementation 
dependent. Most likely MGC might be ignoring it.

Thanks
Ashish

---

From: "Stephen Mell (CV/ETL)" <[email-masked]>
Date: Wed, 13 Jun 2007 20:25:23 +0200

Hi Ashish,

I guess this can apply also if a Remote/Local Descriptor from the MGC
is:

Overspecified (multiple parameter values and/or groups, but NOT choose).
Given with ReserveValue and/or ReserveGroup set to ON.
And the MG responds having reserved everything that has been asked for.

Although its not a case mentioned in the standard, I think an MG could
also omit the Remote/Local Descriptor in this case (providing there are
no missing mandatory SDP parameters to be filled in).

Same reasoning applies - that the Reply descriptor is identical to the
request descriptor, so that including the descriptor in the reply adds
no value.

So MGC implementations should probably always turn to the request
descriptor, when the reply descriptor is missing (and no 510 error).

Steve.

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: 13 June 2007 18:33
To: Ron Gilaad
Cc: [email-masked]; Asaf Vadai
Subject: Re: [Megaco] Remote desc in the reply to the MGC

Hi Ron,

Thanks
Ashish

Ron Gilaad wrote:
> Is it a must not to include the remote in case it is fully specified 
> or an option?
>
> Regards,
>
> Ron
>

>> ---------------------------------------------------------------------
>> -
>> --
>>