Hi Dale,
Looks pretty reasonable, though I think people will continue to use a
multiplicity of methods depending on their goals, constraints, and whims.
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
So:
- initial invite (F1) offers X,Y
- answer (F3) is for X
- second offer (F6,F7) is again for X,Y
- second answer (F8,F10) is for Y
- third offer (F11) is for X,Z
- third answer (F12) is for X
That all works. The parts that might be questioned are:
- the second offer including X,Y, not just Y
- the third offer including X,Z even though
neither of those are currently in use
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. :-)
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.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
