headers
Prashant Mehrotra | 3 May 2006 17:48
Picon

H.248.14 (Inactivity Timer Package)

The inactivity timer package says that the possible values of the 
"maximum inactivity time" range from 0 to 65535 (10 ms steps). I'm not 
sure what a value of 0 means. If an MGC sends an event descriptor with a 
value of 0 for the mit (timer value), should the MG ignore this?

Thanks,
Prashant
Permalink | Reply | 1 comment |
headers
B Venkat S.R Swamy | 4 May 2006 07:47

Re: H.248.14 (Inactivity Timer Package)

Hi

MIT value of 0 indicates disabling of inactivity timing as clearly mentioned in the H248.14, EventID description.
Thus MG will stop the inactivity timer (if alreadty running) and will never going to report the Notify for Inactivity, untill MGC again
gives a non-zero value for MIT.

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
Prashant Mehrotra <prashant.mehrotra <at> alcatel.com>


          Prashant Mehrotra <prashant.mehrotra <at> alcatel.com>

          05/03/2006 09:18 PM

To
megaco <at> ietf.org

cc

Subject
[Megaco] H.248.14 (Inactivity Timer Package)

The inactivity timer package says that the possible values of the
"maximum inactivity time" range from 0 to 65535 (10 ms steps). I'm not
sure what a value of 0 means. If an MGC sends an event descriptor with a
value of 0 for the mit (timer value), should the MG ignore this?

Thanks,
Prashant

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software
Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Mudit Gupta | 4 May 2006 08:03
Favicon

IP V6 Address!!

Hi all,
 
I have a query regarding connection field for local descriptor. When I used "c= IN IP6 $", it failed at ABNF decoding level, but if I used "c=IN IP6 x.x.x.x.x.x" for local descriptor field, it was passed by the grammar. But, in case of IP4 both are being supported.
 
I am in doubt if the parser implementation is wrong or the ABNF does not support "c= IN IP6 $".
 
Regards,
Mudit
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 1 comment |
headers
Christian Groves | 4 May 2006 09:06

Re: IP V6 Address!!

Hello Mudit,

The H.248 ABNF for local is a string so it supports any type of text you 
place in it. The SDP parser might be giving you a problem. We have just 
consented new Recommendation H.248.39, “H.248 SDP Parameter 
Identification and Wildcarding” which gives examples of SDP usage and 
wildcarding in H.248.

For the c= it states:

Table 6.13/H.248.39 – Connection Information

SDP Specification:

Definition:

[Clause 6/RFC 2327]

	

c=* (connection information - optional if included at session-level)

	

ABNF:

[Appendix A/RFC 2327]

	

connection-field = ["c=" nettype space addrtype space

connection-address CRLF]

	

H.248/SDP encoding examples
with applied wildcarding:

	

Results:

c=?

c=? ?

	

Are invalid.

There are three mandatory parameters “nettype” and “addrtype” and 
“connection-address” which may be wildcarded.

c=? ? ?

	

Would give

c=nettype addrtype connection-address

So C=IN IP6 $ should be supported.

Regards, Christian

Mudit Gupta wrote:

> Hi all,
> I have a query regarding connection field for local descriptor. When I 
> used "c= IN IP6 $", it failed at ABNF decoding level, but if I used 
> "c=IN IP6 x.x.x.x.x.x" for local descriptor field, it was passed by 
> the grammar. But, in case of IP4 both are being supported.
> I am in doubt if the parser implementation is wrong or the ABNF does 
> not support "c= IN IP6 $".
> Regards,
> Mudit
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Megaco mailing list
>Megaco <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>  
>
Permalink | Reply | 0 comments |
headers
Ron Ho | 4 May 2006 17:18
Picon

Multiple SDP "m=" lines

Hi All,

I am confused about the SDP "m=" line use in Megaco. Should a session
contain more than one media stream, there should be multiple "m="
lines in the SDP session in the local/remote descriptor. If all the
media streams use different encoding scheme, we could clearly
distinguish one from the other. However, if there exists two streams
with identical encoding scheme. How can we distinguish one from the
other. For example, if we carry left channel and right channel in
different audio streams. How can the other end know which channel is
left and which is right? Should there be clear marking on the channel
to indicate which is which? The matter get more complicated in a IP/IP
border gateway environment. If there is a media streams switching in
the middle of the call, how do we associate the new streams channel
properly. E.g. the left and right channel may be swapped
un-intentionaly by the border gateway. Is there any spec. talked about
this? I would really appreciate if anyone can give me some pointer on
this.

Thanks,
Ron
Permalink | Reply | 0 comments |
headers
Kevin Boyle | 4 May 2006 17:47
Favicon

RE: Multiple SDP "m=" lines

Multiple streams must appear in multiple Stream Descriptors.  Therefore,
multiple m= lines are required to be separated by v= lines in order to
distinguish the m= lines as alternatives and not simultaneous options.
If you are trying to set up multiple simultaneous streams, you must have
one Stream Descriptor per stream, each with its own Local and Remote
Descriptor.

I would think the right/left channel information would be encoded in the
stream, so the receiving end will know how to play it out.  If so, then
all the concerns about which side is which and entities in the middle
moving stuff around becomes irrelevant.

Kevin 

-----Original Message-----
From: Ron Ho [mailto:ron.ho.megaco <at> gmail.com] 
Sent: Thursday, May 04, 2006 11:19 AM
To: megaco
Subject: [Megaco] Multiple SDP "m=" lines

Hi All,

I am confused about the SDP "m=" line use in Megaco. Should a session
contain more than one media stream, there should be multiple "m="
lines in the SDP session in the local/remote descriptor. If all the
media streams use different encoding scheme, we could clearly
distinguish one from the other. However, if there exists two streams
with identical encoding scheme. How can we distinguish one from the
other. For example, if we carry left channel and right channel in
different audio streams. How can the other end know which channel is
left and which is right? Should there be clear marking on the channel to
indicate which is which? The matter get more complicated in a IP/IP
border gateway environment. If there is a media streams switching in the
middle of the call, how do we associate the new streams channel
properly. E.g. the left and right channel may be swapped un-intentionaly
by the border gateway. Is there any spec. talked about this? I would
really appreciate if anyone can give me some pointer on this.

Thanks,
Ron

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
EhabMohammedKhrsheed 89115 | 4 May 2006 19:38
Favicon

H.248 over ATM

Dear All,

am trying to get sample scenario diagrams for H.248 over ATM connection, can anyone kindly help me get such
info pls!

Br,
Ehab

*******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for
the person or entity whose address is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: megaco-request <at> ietf.org
Date: Thursday, May 4, 2006 7:00 pm
Subject: Megaco Digest, Vol 25, Issue 2

> Send Megaco mailing list submissions to
> 	megaco <at> ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> 	megaco-request <at> ietf.org
> 
> You can reach the person managing the list at
> 	megaco-owner <at> ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: H.248.14 (Inactivity Timer Package) (B Venkat S.R Swamy)
>   2. IP V6 Address!! (Mudit Gupta)
>   3. Re: IP V6 Address!! (Christian Groves)
>   4. Multiple SDP "m=" lines (Ron Ho)
>   5. RE: Multiple SDP "m=" lines (Kevin Boyle)
> 
> 
> -------------------------------------------------------------------
> ---
> 
> Message: 1
> Date: Thu, 4 May 2006 11:17:45 +0530
> From: "B Venkat S.R Swamy" <b.swamy <at> flextronicssoftware.com>
> Subject: Re: [Megaco] H.248.14 (Inactivity Timer Package)
> To: Prashant Mehrotra <prashant.mehrotra <at> alcatel.com>
> Cc: megaco <at> ietf.org
> Message-ID:
> 	<OF78372A7D.A9F2A8CD-ON65257164.001ECADC-
> 65257164.001F9D07 <at> flextronicssoftware.com>	
> Content-Type: text/plain; charset="us-ascii"
> 
> An HTML attachment was scrubbed...
> URL: 
>
http://www1.ietf.org/pipermail/megaco/attachments/20060504/02393a82/attachment.html--------------
next part --------------
> A non-text attachment was scrubbed...
> Name: graycol.gif
> Type: image/gif
> Size: 848 bytes
> Desc: not available
> Url : 
>
http://www1.ietf.org/pipermail/megaco/attachments/20060504/02393a82/graycol.gif--------------
next part --------------
> A non-text attachment was scrubbed...
> Name: pic25957.gif
> Type: image/gif
> Size: 1255 bytes
> Desc: not available
> Url : 
>
http://www1.ietf.org/pipermail/megaco/attachments/20060504/02393a82/pic25957.gif--------------
next part --------------
> A non-text attachment was scrubbed...
> Name: ecblank.gif
> Type: image/gif
> Size: 813 bytes
> Desc: not available
> Url : 
> http://www1.ietf.org/pipermail/megaco/attachments/20060504/02393a82/ecblank.gif
> ------------------------------
> 
> Message: 2
> Date: Thu, 4 May 2006 11:33:24 +0530
> From: "Mudit Gupta" <mudit.gupta <at> ccpu.com>
> Subject: [Megaco] IP V6 Address!!
> To: <megaco <at> ietf.org>
> Message-ID: <22F058C3ED9D784E90CE473F2A9847F0582223 <at> in-exchange>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi all,
> 
> I have a query regarding connection field for local descriptor. 
> When I used "c= IN IP6 $", it failed at ABNF decoding level, but 
> if I used "c=IN IP6 x.x.x.x.x.x" for local descriptor field, it 
> was passed by the grammar. But, in case of IP4 both are being 
> supported. 
> 
> I am in doubt if the parser implementation is wrong or the ABNF 
> does not support "c= IN IP6 $".
> 
> Regards,
> Mudit
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://www1.ietf.org/pipermail/megaco/attachments/20060504/0fc1a181/attachment.html
> ------------------------------
> 
> Message: 3
> Date: Thu, 04 May 2006 17:06:34 +1000
> From: Christian Groves <Christian.Groves <at> nteczone.com>
> Subject: Re: [Megaco] IP V6 Address!!
> To: Mudit Gupta <mudit.gupta <at> ccpu.com>
> Cc: megaco <at> ietf.org
> Message-ID: <4459A7FA.30602 <at> nteczone.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hello Mudit,
> 
> The H.248 ABNF for local is a string so it supports any type of 
> text you 
> place in it. The SDP parser might be giving you a problem. We have 
> just 
> consented new Recommendation H.248.39, ?H.248 SDP Parameter 
> Identification and Wildcarding? which gives examples of SDP usage 
> and 
> wildcarding in H.248.
> 
> For the c= it states:
> 
> Table 6.13/H.248.39 ? Connection Information
> 
> SDP Specification:
> 
> Definition:
> 
> [Clause 6/RFC 2327]
> 
> 	
> 
> c=* (connection information - optional if included at session-level)
> 
> 	
> 
> ABNF:
> 
> [Appendix A/RFC 2327]
> 
> 	
> 
> connection-field = ["c=" nettype space addrtype space
> 
> connection-address CRLF]
> 
> 	
> 
> H.248/SDP encoding examples
> with applied wildcarding:
> 
> 	
> 
> Results:
> 
> c=?
> 
> c=? ?
> 
> 	
> 
> Are invalid.
> 
> There are three mandatory parameters ?nettype? and ?addrtype? and 
> ?connection-address? which may be wildcarded.
> 
> c=? ? ?
> 
> 	
> 
> Would give
> 
> c=nettype addrtype connection-address
> 
> 
> So C=IN IP6 $ should be supported.
> 
> Regards, Christian
> 
> Mudit Gupta wrote:
> 
> > Hi all,
> > I have a query regarding connection field for local descriptor. 
> When I 
> > used "c= IN IP6 $", it failed at ABNF decoding level, but if I 
> used 
> > "c=IN IP6 x.x.x.x.x.x" for local descriptor field, it was passed 
> by 
> > the grammar. But, in case of IP4 both are being supported.
> > I am in doubt if the parser implementation is wrong or the ABNF 
> does 
> > not support "c= IN IP6 $".
> > Regards,
> > Mudit
> >
> >------------------------------------------------------------------
> ------
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> >  
> >
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 4 May 2006 11:18:31 -0400
> From: "Ron Ho" <ron.ho.megaco <at> gmail.com>
> Subject: [Megaco] Multiple SDP "m=" lines
> To: megaco <megaco <at> ietf.org>
> Message-ID:
> 	<ae7fef390605040818s4e977e63je5ff89aafa6f7c37 <at> mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi All,
> 
> I am confused about the SDP "m=" line use in Megaco. Should a session
> contain more than one media stream, there should be multiple "m="
> lines in the SDP session in the local/remote descriptor. If all the
> media streams use different encoding scheme, we could clearly
> distinguish one from the other. However, if there exists two streams
> with identical encoding scheme. How can we distinguish one from the
> other. For example, if we carry left channel and right channel in
> different audio streams. How can the other end know which channel is
> left and which is right? Should there be clear marking on the channel
> to indicate which is which? The matter get more complicated in a IP/IP
> border gateway environment. If there is a media streams switching in
> the middle of the call, how do we associate the new streams channel
> properly. E.g. the left and right channel may be swapped
> un-intentionaly by the border gateway. Is there any spec. talked about
> this? I would really appreciate if anyone can give me some pointer on
> this.
> 
> 
> Thanks,
> Ron
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 4 May 2006 11:47:57 -0400
> From: "Kevin Boyle" <kboyle <at> nortel.com>
> Subject: RE: [Megaco] Multiple SDP "m=" lines
> To: "Ron Ho" <ron.ho.megaco <at> gmail.com>, "megaco" <megaco <at> ietf.org>
> Message-ID:
> 	<34B3EAA5B3066A42914D28C5ECF5FEA40831CF6E <at> zrtphxm2.corp.nortel.com>
> 
> Multiple streams must appear in multiple Stream Descriptors.  
> Therefore,multiple m= lines are required to be separated by v= 
> lines in order to
> distinguish the m= lines as alternatives and not simultaneous options.
> If you are trying to set up multiple simultaneous streams, you 
> must have
> one Stream Descriptor per stream, each with its own Local and Remote
> Descriptor.
> 
> I would think the right/left channel information would be encoded 
> in the
> stream, so the receiving end will know how to play it out.  If so, 
> thenall the concerns about which side is which and entities in the 
> middlemoving stuff around becomes irrelevant.
> 
> Kevin 
> 
> -----Original Message-----
> From: Ron Ho [ron.ho.megaco <at> gmail.com] 
> Sent: Thursday, May 04, 2006 11:19 AM
> To: megaco
> Subject: [Megaco] Multiple SDP "m=" lines
> 
> Hi All,
> 
> I am confused about the SDP "m=" line use in Megaco. Should a session
> contain more than one media stream, there should be multiple "m="
> lines in the SDP session in the local/remote descriptor. If all the
> media streams use different encoding scheme, we could clearly
> distinguish one from the other. However, if there exists two streams
> with identical encoding scheme. How can we distinguish one from the
> other. For example, if we carry left channel and right channel in
> different audio streams. How can the other end know which channel is
> left and which is right? Should there be clear marking on the 
> channel to
> indicate which is which? The matter get more complicated in a IP/IP
> border gateway environment. If there is a media streams switching 
> in the
> middle of the call, how do we associate the new streams channel
> properly. E.g. the left and right channel may be swapped un-
> intentionalyby the border gateway. Is there any spec. talked about 
> this? I would
> really appreciate if anyone can give me some pointer on this.
> 
> 
> Thanks,
> Ron
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> End of Megaco Digest, Vol 25, Issue 2
> *************************************
>
Permalink | Reply | 0 comments |
headers
liu qiumin | 4 May 2006 19:57
Picon

Re: Jain Megaco Implemention



 
On 4/29/06, Araz. <araz.megaco <at> gmail.com> wrote:
Hi Everybody ,
Does anyone knows a product or implemention of Megaco Stack which has used Jain Megaco API as specified in   JSR-000079 ?
(Excluding hss sample codes.)
thanks ahead ,
Araz.

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Richard Sun | 4 May 2006 22:39
Picon
Favicon

T.38 Signals {ctyp/ans{anstype=v21flags}}?

In T.38 (e.g. page 86 of the 09/2005 version), there is a command
       Signals {ctyp/ans{anstype=v21flags, SignalType=TimeOut}}
from MGC to MG to generate V21flags.

But from H248.2, v21flags is NOT a valid enum:
8.3.2.1.1	Answer Type
Possible values:
	ANS		(0x0001) V.25 ANS (equivalent to T.30 CED) for all modes
	ANSBAR	(0x0002) V.25 ANS with phase reversals for all modes
	ANSAM		(0x0003) V.8 ANSam for all modes
	ANSAMBAR	(0x0004) V.8 ANSam with phase reversals for all modes
	V18txp1	(0x0005) A V.18 txp signal played in V.21 channel (1) for TEXT
	V18txp2	(0x0006) A V.18 txp signal played in V.21 channel (2) for TEXT
	ansnosig	(0x0007)	Not used (Reserved)

is there a fix for this somewhere?
Thanks for any info.
-Richard
Permalink | Reply | 0 comments |
headers
Albrecht.Schwarz | 5 May 2006 14:15
Picon
Picon

H.248.qhr vs Y.pmm & Y.mpm


Hello Geoff,

had a quick look in the SG13 Drafts Y.pmm & Y.mpm:

Y.pmm Performance measurement and management for NGN (TD 70 (WP 4/13))
Y.mpm Management of performance measurement for NGN (Kobe-Q04-13-042)
[Guess Y.mpm obsoletes Y.pmm.]

My conclusion is, that they are not directly linked to H.248.qhr (or also
H.248.scr), but it could be worth in following this work (from a NGN
framework perspective).

- Albrecht
Permalink | Reply | 0 comments |

Gmane