I've just submitted draft-worley-service-example-03, "Session Initiation
Protocol Service Example -- Music on Hold". It describes a robust and
reasonably simple way to implement music on hold. At least one major
phone vendor has adopted this technique.
Paul Kyzivat wrote many moons ago:
> One thing I was thinking about here is what happens if common codecs
> don't exist at all parties. I think your proposal can still work in that
> environment, but perhaps its worth discussing.
>
> For example, lets take your case and assume codec support is as follows:
>
> - Alice: X,Y
> - Bob: X,Z
> - Music: Y,Z
Thanks for pointing this out! I've documented this scenario in section
4 of -03, titled "The Importance of Offering All Available Media
Formats".
> On another subject - payload type numbers - there is a *potential*
> problem. The music server *can* choose its own payload numbers. This is
> most likely in an offer (which in these flows it never does), but also
> in an answer. It is preferred to use the same payload number in answer
> as offer, but it isn't required. And the answer can also include codecs
> not present in the offer, in which case the music server will be
> choosing for sure.
>
> In these cases, its possible that the payload number chosen by the music
> server will conflict with one used previously by Bob for some other
> codec. For instance, in my example above, the payload number chosen by
> the music server for Y in F8 might turn out to be the same as the number
> used by Bob for X in F3. If this happens, and if the UAs *care* about
> this violation of the specs, then there is little that Bob can do about
> it. IMO that restriction needs to be relaxed a bit.
I thought I had gotten this fixed in -02, but you've shown that I
haven't. But I think that I can get around this problem as long as the
MOH server obeys a SHOULD requirement in section 6.1 of the offer/answer
RFC. Quoting from section 2.7 of -03:
2.7. Payload Type Numbers
In this technique, the MOH source generates an SDP answer that the
executing UA presents to the remote UA as an answer within the original
dialog. In basic functionality, this presents no problem, because
[offer‑answer] (section 6.1, at the very end) specifies that the payload
type numbers used in either direction of RTP are the ones specified in
the SDP sent by the recipient of the RTP.
But strict compliance to [offer‑answer] (section 8.3.2) requires that
payload type numbers used in SDP may only duplicate the payload type
numbers used in any SDP used in the same direction in the dialog if the
payload type numbers represent the same media format (codec) as they did
previously. However, the MOH source has no knowledge of the payload type
numbers previously used in the original dialog, and it may accidentally
specify a media format for a previously used payload type number in its
answer (or in a subsequently generated INVITE or UPDATE). This would
cause no problem with media decoding, as it cannot send any format that
was not in the remote UA's offer, but it would violate [offer‑answer].
Strictly speaking, it is impossible to avoid this problem because the
generator of a first answer in its dialog can choose the payload numbers
independently of the payload numbers in the offer, and the MOH server
believes that its answer is first in the dialog. Thus the only absolute
solution is to have the executing UA rewrite the SDP that passes through
it to reassign payload type numbers, which would also require it to
rewrite the payload type numbers in the RTP packets -- a very
undesirable solution. But we can exploit a SHOULD-level requirement in
[offer‑answer] (section 6.1): "In the case of RTP, if a particular codec
was referenced with a specific payload type number in the offer, that
same payload type number SHOULD be used for that codec in the answer."
If the MOH source obeys this restriction, the executing UA can modify
the offer SDP to "reserve" all payload type numbers that have ever been
offered by the executing UA to prevent the MOH source from using them
for different media formats.
When the executing UA is composing the INVITE to the MOH source, it
compiles a list of all the (dynamically-assigned) payload type numbers
which have been used by it (or by MOH sources on its behalf) in the
original dialog but which are not mapped to a media format in the
current offer SDP. (The executing UA must be maintaining a list of all
previously used payload type numbers anyway, in order to comply with
[offer‑answer].) Then, for each of these payload type numbers, it
inserts session-level or media-level (as appropriate) a=rtpmap lines
specifying the payload type number and the media format that it has been
used for. Because of the reuse rule, the MOH source SHOULD not propose
those payload type numbers for any other media format.
Note that any re-INVITEs from the remote UA that the executing UA passes
through to the MOH server require similar modification, as payload type
numbers that the MOH server receives in past offers are not absolutely
reserved against its use (as they have not been sent in SDP by the MOH
server) nor is there a SHOULD-level proscription against using them in
the current answer (as they do not appear in the current offer).
This should provide an adequate solution to the problems with payload
type numbers, as it will fail only if (1) the remote UA is particular
that other UAs follow the rule about not re-defining payload type
numbers, and (2) the MOH server does not follow the SHOULD-level
requirement of [offer‑answer] section 6.1.
Let us show how this process works by modifying the example Section 2.3
(Example Message Flow) with this specific assignment of supported
codecs:
Alice supports formats X and Y
Bob supports formats X and Z
Music Source supports formats Y and Z
In this case, the SDP exchanges are:
F1 offers X and Y, F3 answers X and Z (which cannot be used)
F6 offers X and Y, but F7 offers X, Y, and a place-holder to
block type 92
F8/F10 answers Y
F1 INVITE Alice -> Bob
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:[email protected]>;tag=1234567
To: Bob <sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:[email protected];gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
F3 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:[email protected]>;tag=1234567
To: Bob <sips:[email protected]>;tag=23431
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:[email protected]>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 90 92
a=rtpmap:90 X/8000
a=rtpmap:92 Z/8000
F6 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:[email protected]>;tag=1234567
From: Bob <sips:[email protected]>;tag=23431
Call-ID: [email protected]
CSeq: 712 INVITE
Contact: <sips:[email protected];gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 90 91
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
F7 INVITE Bob -> Music Source
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:[email protected]>;tag=02134
To: Music Source <sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:[email protected]>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 49170 RTP/AVP 90 91 92
a=rtpmap:90 X/8000
a=rtpmap:91 Y/8000
a=rtpmap:92 x-reserved/8000
a=recvonly
F8 200 OK Music Source -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:[email protected]>;tag=02134
To: Music Source <sips:[email protected]>;tag=56323
Call-ID: [email protected]
Contact: <sips:[email protected]>
CSeq: 1 INVITE
Content-Length: [omitted]
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 91
a=rtpmap:91 Y/8000
a=sendonly
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
