Sirs,
According to RFC 2705 (MGCP), these are the parameters that are used in the
transactions:
ReturnCode,
Connection-parameters
<-- DeleteConnection(CallId,
EndpointId,
ConnectionId,
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode,
<-- DeleteConnection( CallId,
EndpointId,
ConnectionId,
Reason-code,
Connection-parameters)
ReturnCode,
<-- DeleteConnection( CallId,
EndpointId)
ReturnCode,
<-- DeleteConnection( EndpointId)
ReturnCode,
EndPointIdList|{
[RequestedEvents,]
[DigitMap,]
[SignalRequests,]
[RequestIdentifier,]
[NotifiedEntity,]
[ConnectionIdentifiers,]
[DetectEvents,]
[ObservedEvents,]
[EventStates,]
[BearerInformation,]
[RestartReason,]
[RestartDelay,]
[ReasonCode,]
[Capabilities]}
<--- AuditEndPoint(EndpointId,
[RequestedInfo])
ReturnCode,
[CallId,]
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters]
<--- AuditConnection(EndpointId,
ConnectionId,
RequestedInfo)
ReturnCode,
[NotifiedEntity]
<------- RestartInProgress ( EndPointId,
RestartMethod,
[RestartDelay,]
[Reason-code])
ReturnCode
<-- EndpointConfiguration( EndpointId,
BearerInformation)
ReturnCode
<-- NotificationRequest( EndpointId,
[NotifiedEntity,]
[RequestedEvents,]
RequestIdentifier,
[DigitMap,]
[SignalRequests,]
[QuarantineHandling,]
[DetectEvents,]
[encapsulated EndpointConfiguration])
ReturnCode
<-- Notify( EndpointId,
[NotifiedEntity,]
RequestIdentifier,
ObservedEvents)
ReturnCode,
ConnectionId,
[SpecificEndPointId,]
[LocalConnectionDescriptor,]
[SecondEndPointId,]
[SecondConnectionId]
<--- CreateConnection(CallId,
EndpointId,
[NotifiedEntity,]
[LocalConnectionOptions,]
Mode,
[{RemoteConnectionDescriptor |
SecondEndpointId}, ]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
ReturnCode,
[LocalConnectionDescriptor]
<--- ModifyConnection(CallId,
EndpointId,
ConnectionId,
[NotifiedEntity,]
[LocalConnectionOptions,]
[Mode,]
[RemoteConnectionDescriptor,]
[Encapsulated NotificationRequest,]
[Encapsulated EndpointConfiguration])
My questions:
1) I am using Asterisk and a softphone called MGCP eyeP Phone. I was
watching the traffic between them at Ethereal and observed that some of them
have extra parameters. Example: CreateConnection has "Request Identifier
(X)", that is not described on RFC 2705. Should I ignore or consider it?
2) There are some parameters that don't have identifier? I mean,
"Request
Identifier" is "X:"; "Observed Events" is "O:
"; "Call ID" is "C: "... These
are them:
- "Notified Entity"
- "Remote Connection Descriptor"
- "encapsulated Endpoint Configuration"
- "Second Endpoint Id"
- "encapsulated Notification Request"
2.1) How can I identify them when they exist?
2.2) What means "encapsulated" parameters??
Thanks in advance,
Leonardo
The RFC specification alone is not sufficient, there are many signaling "packages" that are defined elsewhere. Also, RFC 2705 is out of date, see RFC 3435 Leonardo J. Tramontina wrote:> Sirs, > > According to RFC 2705 (MGCP), these are the parameters that are used > in the transactions: > > > ReturnCode, > Connection-parameters > <-- DeleteConnection(CallId, > EndpointId, > ConnectionId, > [Encapsulated NotificationRequest,] > [Encapsulated EndpointConfiguration]) > > > ReturnCode, > <-- DeleteConnection( CallId, > EndpointId, > ConnectionId, > Reason-code, > Connection-parameters) > > ReturnCode, > <-- DeleteConnection( CallId, > EndpointId) > > > ReturnCode, > <-- DeleteConnection( EndpointId) > > > ReturnCode, > EndPointIdList|{ > [RequestedEvents,] > [DigitMap,] > [SignalRequests,] > [RequestIdentifier,] > [NotifiedEntity,] > [ConnectionIdentifiers,] > [DetectEvents,] > [ObservedEvents,] > [EventStates,] > [BearerInformation,] > [RestartReason,] > [RestartDelay,] > [ReasonCode,] > [Capabilities]} > <--- AuditEndPoint(EndpointId, > [RequestedInfo]) > > > ReturnCode, > [CallId,] > [NotifiedEntity,] > [LocalConnectionOptions,] > [Mode,] > [RemoteConnectionDescriptor,] > [LocalConnectionDescriptor,] > [ConnectionParameters] > <--- AuditConnection(EndpointId, > ConnectionId, > RequestedInfo) > > > > ReturnCode, > [NotifiedEntity] > <------- RestartInProgress ( EndPointId, > RestartMethod, > [RestartDelay,] > [Reason-code]) > > > > ReturnCode > <-- EndpointConfiguration( EndpointId, > BearerInformation) > > > > ReturnCode > <-- NotificationRequest( EndpointId, > [NotifiedEntity,] > [RequestedEvents,] > RequestIdentifier, > [DigitMap,] > [SignalRequests,] > [QuarantineHandling,] > [DetectEvents,] > [encapsulated EndpointConfiguration]) > > > > ReturnCode > <-- Notify( EndpointId, > [NotifiedEntity,] > RequestIdentifier, > ObservedEvents) > > > ReturnCode, > ConnectionId, > [SpecificEndPointId,] > [LocalConnectionDescriptor,] > [SecondEndPointId,] > [SecondConnectionId] > <--- CreateConnection(CallId, > EndpointId, > [NotifiedEntity,] > [LocalConnectionOptions,] > Mode, > [{RemoteConnectionDescriptor | > SecondEndpointId}, ] > [Encapsulated NotificationRequest,] > [Encapsulated EndpointConfiguration]) > > > > > ReturnCode, > [LocalConnectionDescriptor] > <--- ModifyConnection(CallId, > EndpointId, > ConnectionId, > [NotifiedEntity,] > [LocalConnectionOptions,] > [Mode,] > [RemoteConnectionDescriptor,] > [Encapsulated NotificationRequest,] > [Encapsulated EndpointConfiguration]) > > > > > My questions: > > 1) I am using Asterisk and a softphone called MGCP eyeP Phone. I was > watching the traffic between them at Ethereal and observed that some > of them have extra parameters. Example: CreateConnection has "Request > Identifier (X)", that is not described on RFC 2705. Should I ignore or > consider it? > > 2) There are some parameters that don't have identifier? I mean, > "Request Identifier" is "X:"; "Observed Events" is "O: "; "Call ID" is > "C: "... These are them: > - "Notified Entity" > - "Remote Connection Descriptor" > - "encapsulated Endpoint Configuration" > - "Second Endpoint Id" > - "encapsulated Notification Request" > > 2.1) How can I identify them when they exist? > > 2.2) What means "encapsulated" parameters?? > > > > Thanks in advance, > > Leonardo > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
On Fri, Dec 31, 2004 at 10:03:54AM -0300, Leonardo J. Tramontina wrote:> 1) I am using Asterisk and a softphone called MGCP eyeP Phone. I was > watching the traffic between them at Ethereal and observed that some of > them have extra parameters. Example: CreateConnection has "Request > Identifier (X)", that is not described on RFC 2705. Should I ignore or > consider it?I believe X is spec'd in RFC 3435.> > 2) There are some parameters that don't have identifier? I mean, "Request > Identifier" is "X:"; "Observed Events" is "O: "; "Call ID" is "C: "... > These are them: > - "Notified Entity" > - "Remote Connection Descriptor" > - "encapsulated Endpoint Configuration" > - "Second Endpoint Id" > - "encapsulated Notification Request"See above.> 2.1) How can I identify them when they exist?See above. RFCs 2705 and 3435 both specify how to handle unknown commands and parameters.> 2.2) What means "encapsulated" parameters??When you receive a RQNT (request for notify) you include the action to be taken for different types of events. The action can be a stripped down RQNT that provides new instructions, just like a new RQNT packet. This can include parameters. I've heard it call encapsulated parameters but I believe that the spec calls it embedded. YMMV. FWIW, Asterisk's MGCP support is a bit dubious and definitely not what the spec intended. The spec intended for a call agent to manage various media gateways and orchestrate what was going on. Asterisk is a media gateway that attempts to be a call agent for itself and another media gateway (the phone) with interesting but limited results. It probably will never operate in a real MGCP environment unless chan_mgcp is implemented as a media gateway. Right now, it just provides a hack that allows MGCP phones to hit it...sometimes. Good luck. -- Jayson Vantuyl