Hi Dale,
Glad that this draft is getting there.
I have an editorial comment...
I think I'd find it more readable if the information in section 4 was changed a
bit:
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
F6/F7 offers X and Y, F8/F10 answers Y
F11 offers X and Z, F12 answers X
In the above, it starts with Alice, Bob and Music but then talks about F1/F3,
etc.
I feel this makes it a bit harder to match Alice, Bob and Music Source with the
messages.
I'd prefer it like this:
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:
1. Alice offers X and Y (corresponding message F1),
Bob answers X (F3)
2. Alice (via Bob) offers X and Y (F6/F7),
Music Source (via Bob) answers Y (F8/F10)
3. Bob offers X and Z (F11),
Alice answers X (F12)
I feel this makes it easier to follow.
You could even explain further:
1. Alice calls Bob:
Alice offers X and Y (corresponding message F1),
Bob answers X (F3)
2. Bob puts Alice on hold:
Alice (via Bob) offers X and Y (F6/F7),
Music Source (via Bob) answers Y (F8/F10)
3. Bob takes Alice off hold:
Bob offers X and Z (F11),
Alice answers X (F12)
Regards,
Attila
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dale Worley
Sent: 06 March 2009 04:14
To: sip-implementors
Subject: Re: [Sip-implementors] draft-worley-service-example-02
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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
