Re: [Sipping] draft-ietf-sipping-service-examples-10.txt

On Sat, 2006-05-27 at 15:17 -0700, Venkatesh wrote:
> I was taking a look at the call flows outlined in section 2.3 for MOH.
> I think the call flow outlined could potentially violate the
> offer/answer requirements as regards dynamic codec selection. Say when
> the call between A and B gets set up, B selected payload number 46 to
> mean x. When B sends an INVITE w/o SDP towards the MOH server, the MOH
> server could potentially end up using payload number 46 to mean y.  

Looking at RFC 3264, section 8.3.2, that does seem to be a problem.  But
it's a bit more complicated than it looks -- the payload number
assignments are definitively controlled by the recipient of the RTP, not
the sender, and any RTP payload number named in an offer and used for
sending is just a tentative assignment that the answerer can change.

RFC 3264 section 5.1, bottom of page 6 correctly:

   For sendonly RTP streams, the payload type
   numbers indicate the value of the payload type field in RTP packets
   the offerer is planning to send for that codec.  [...]
   However, for sendonly and sendrecv streams, the answer might indicate
   different payload type numbers for the same codecs, in which case,
   the offerer MUST send with the payload type numbers from the answer.

So perhaps in practice it isn't so important whether MOH offers reused
payload numbers, as A can/will/should give an answer with proper payload
numbers.

Another challenge is the specification in RFC 3264 section 8, which
requires that any new offer be phrased as a modification of the previous
SDP, presenting the same sequence of m= lines, though possibly with
additions at the end.  There is no a priori constraint that guarantees
that the MOH server will deliver SDP that directly correlates with the
SDP of the call, so B may have to do SDP translation.

(Suppose that A initiates the call with SDP that contains two m= lines,
one for audio and one for video.  B's answer has a=inactive for the
m=video line, but section 8 requires that all later SDP in the call
contains that m=video line in position 2 in the SDP.)

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

Re: [Sipping] draft-ietf-sipping-service-examples-10.txt - issue with MOH call flows?