📄 draft-ietf-speechsc-mrcpv2-05.txt
字号:
CSeq: 314161 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
S Shanmugham IETF-Draft Page 10
MRCPv2 Protocol October, 2004
s=-
c=IN IP4 224.2.17.12
m=control 9 TCP application/mrcpv2
a=setup:active
a=connection:new
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=control 32416 TCP application/mrcpv2
a=setup:passive
a=connection:new
a=channel:32AECB234338@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 00 96
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 ACK
Content-Length: 0
Example 2:
S Shanmugham IETF-Draft Page 11
MRCPv2 Protocol October, 2004
This exchange continues from example 1 allocates an additional
resource control channel for a recognizer. Since a recognizer would
need to receive an audio stream for recognition, this interaction
also updates the audio stream to sendrecv making it a 2-way audio
stream.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=control 9 TCP application/mrcpv2
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:1
m=control 9 TCP application/mrcpv2
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
S Shanmugham IETF-Draft Page 12
MRCPv2 Protocol October, 2004
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=control 32416 TCP application/mrcpv2
a=setup:passive
a=connection:existing
a=channel:32AECB234338@speechrecog
a=cmid:1
m=control 32416 TCP application/mrcpv2
a=setup:passive
a=connection:existing
a=channel:32AECB234339@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314164 ACK
Content-Length: 0
Example 3:
This exchange continues from example 2 and de-allocates recognizer
channel. Since a recognizer would not need to receive an audio
stream any more, this interaction also updates the audio stream to
recvonly.
C->S:
INVITE sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
S Shanmugham IETF-Draft Page 13
MRCPv2 Protocol October, 2004
Content-Length: ...
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=control 0 TCP application/mrcpv2
a=resource:speechrecog
a=cmid:1
m=control 9 TCP application/mrcpv2
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C:
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
To: MediaServer <sip:mresources@mediaserver.com>
From: sarvi <sip:sarvi@cisco.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314163 INVITE
Contact: <sip:sarvi@cisco.com>
Content-Type: application/sdp
Content-Length: 131
v=0
o=sarvi 2890844526 2890842809 IN IP4 126.16.64.4
s=-
c=IN IP4 224.2.17.12
m=control 0 TCP application/mrcpv2
a=channel:32AECB234338@speechrecog
a=cmid:1
m=control 32416 TCP application/mrcpv2
a=channel:32AECB234339@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mresources@mediaserver.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf9
Max-Forwards: 6
To: MediaServer <sip:mresources@mediaserver.com>;tag=a6c85cf
From: Sarvi <sip:sarvi@cisco.com>;tag=1928301774
S Shanmugham IETF-Draft Page 14
MRCPv2 Protocol October, 2004
Call-ID: a84b4c76e66710
CSeq: 314164 ACK
Content-Length: 0
4.3. Media Streams and RTP Ports
The client or the server would need to add audio (or other media)
pipes between the client and the server and associate them with the
resource that would process or generate the media. One or more
resources could be associated with a single media channel or each
resource could be assigned a separate media channel. For example, a
synthesizer and a recognizer could be associated to the same media
pipe(m=audio line), if it is opened in "sendrecv" mode.
Alternatively, the recognizer could have its own "sendonly" audio
pipe and the synthesizer could have its own "recvonly" audio pipe.
The association between control channels and their corresponding
media channels is established through the mid attribute defined in
RFC 3388[20]. If there are more than 1 audio m-line, then each audio
m-line MUST have a "mid" attribute. Each control m-line MUST have a
"cmid" attribute that matches the "mid" attribute of the audio m-
line it is associated with.
cmid-attribute = "a=cmid:" identification-tag
identification-tag = token
A single audio m-line can be associated with multiple resources or
each resource can have its own audio m-line. For example, if the
client wants to allocate a recognizer and a synthesizer and
associate them to a single 2-way audio pipe, the SDP offer should
contain two control m-lines and a single audio m-line with an
attribute of "sendrecv". Each of the control m-lines should have a
"cmid" attribute whose value matches the "mid" of the audio m-line.
If the client wants to allocate a recognizer and a synthesizer each
with its own separate audio pipe, the SDP offer would carry two
control m-lines (one for the recognizer and another for the
synthesizer) and two audio m-lines (one with the attribute
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -