Subject: [Megaco] Implications Of New SDP Features

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 8 Jan 2002 09:11:07 -0500

SDP is in the process of picking up some new features, including FID,
SIMCAP, connection-oriented media, and the new negotiation model.  I'm just
testing the waters here, but is there any sentiment in favour of altering
the text to encourage the use of these features in place of existing Megaco
protocol provisions?  For instance, should we discourage the use of
wildcarding, sub-lists, and ranges when text encoding Local and Remote,
saying that applications SHOULD use the alternatives provided by MMUSIC?

Alternatively, should we hold our fire until we introduce SDPnG?

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Jan 2002 16:17:45 +0200

Hi,

Don't the ReserveGroup- and ReserveValue properties already handle lots
of the issues FID, SIMCAP etc are trying to solve?

Also, I don't think those extensions can replace all the cases we use
wildcarding for.

Regards,

Christer Holmberg
Ericsson Finland

Tom-PT Taylor wrote:
> SIMCAP, connection-oriented media, and the new negotiation model.  I'm
> just testing the waters here, but is there any sentiment in favour of
> altering the text to encourage the use of these features in place of
> existing Megaco protocol provisions?  For instance, should we
> discourage the use of wildcarding, sub-lists, and ranges when text
> encoding Local and Remote, saying that applications SHOULD use the
> alternatives provided by MMUSIC?
> 

 
> Ph. +1 613 736 0961 (ESN 396 1490)

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Jan 2002 16:17:45 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: "PSK Chakravarthi" <[email-masked]>
Date: Tue, 8 Jan 2002 20:00:16 +0530

Implications Of New SDP FeaturesHi List,
As per draft-manyfolks-megaco-caspackage-01.txt Section
6.4.5 
    Signal Name: Address 
    SignalID: addr (0x0005) 
    Description: Applies the address signals in the form of either 
          DTMF, dial-pulse or MF-tones on the trunk. The actual 
          frequency, cadence, duration and amplitude values for the 
          multi-frequency tones that convey the address information are 
          provisioned in the MG. 
    Signal Type: (BR) Brief 
    Duration: Provisioned 
    Additional Parameters:  
        Parameter Name: Digit String 
        ParameterID: ds (0x0001) 
        Description: The digit string that needs to be sent as address 
          signals. 
        Type: string of digits. 
        Possible Values: a sequence of the characters "0" through "9" 
          as well as "A" through "H" ("A" through "H" used for MF 
          signalling - refer to the symbols defined for the digit map 
          in the MF Tone Detection package). 
        Parameter Name: Address Delay 
        ParameterID: ad (0x0002) 
        Description: Specifies a timed delay that is applied prior to 
          signalling the address. The address delay is optional. If the 
          address delay parameter is not provided, the MG uses the 
          provisioned value by default.  
        Type: integer 
        Possible Values: 0 and up in milliseconds 

Question:
MGC can instruct gateway to out pulse digits either in DTMF or MF or dial pulse.
How MGC can tell gateway about the mode of the digits is MF or DTMF or Dial Pulse?

Thanks in advance.

Chak

---

From: "PSK Chakravarthi" <[email-masked]>
Date: Tue, 8 Jan 2002 20:00:16 +0530

Question:

Thanks in advance.

Chak