Dale,
I think there is a problem with your solution. It is that payload
numbers need not be the same in both directions. (Although it is
recommended that they be.)
So while you can list all the payload numbers you know of on your end,
that only constrains you. And you could constrain yourself without
telling the other guy you are doing so.
The problem is that the MOH server could decide to use payload numbers
in a different way on its end. (The numbers it expects to receive.) Of
course this isn't a *real* problem because it isn't expecting to receive
anything. Its just a formal problem.
In fact, as far as I can tell, it isn't a real problem any time the
address/port changes as well as the payload numbers. That's why I think
the real answer is the relax the restriction.
Thanks,
Paul
[EMAIL PROTECTED] wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
