From: Paul Kyzivat <[EMAIL PROTECTED]>
Looks pretty reasonable, though I think people will continue to use a
multiplicity of methods depending on their goals, constraints, and whims.
Oh, yes. I just want to document a method we think is useful.
This is all consistent with the offeranswer draft section on hold, that
recommends always offering everything you would like, constrained only
by the o/a rules, rather than trying to guess what you think the other
end wants. Here it is essential to follow that discipline wrt the codecs
in order that a common codec be discovered.
Since we all know that most implementation is done to examples rather
than specs, it might be helpful to put this into the example. :-)
Yes, I think I'll add an example to illustrate the pitfalls.
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 think that's covered in section 2.7. In summary, the executing
phone inserts into the offer generated by the remote phone additional
a=rtpmap lines to specify any payload numbers that have been
previously used in the dialog but aren't present in the remote phone's
offer. That prevents the MOH source from using them in a way
inconsistent with the original dialog. Viz.:
But strict compliance to [2] (section 8.3.2) requires that payload
type numbers used in the SDP answer may duplicate the payload type
numbers used in any offers and answers previously used in the dialog
only 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 [2].
We can prevent this problem by utilizing the requirement itself to
control the behavior of the MOH source: 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 in
the original dialog but which are not mapped to a media format in the
offer SDP. (The executing UA must be maintaining a list of all
previously used payload type numbers anyway, in order to comply with
[2].) 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 cannot
propose those payload type numbers for any other media format.
Someone named "Kyzivat" raised the problem:
5. Acknowledgments
[...]
Paul Kyzivat[10] pointed out the difficulties regarding re-use of
payload type numbers.
[...]
[10] Kyzivat, P., "Subject: Re: [Sipping] I-D
ACTION:draft-ietf-sipping-service-examples-11.txt", IETF
Sipping mailing list msg12181, October 2006.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
