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

From: Venkatesh <[email-masked]>
Date: Sat, 27 May 2006 15:17:51 -0700

Hi:

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.

Venkatesh
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 11:50:02 -0400

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

---

From: Venkatesh <[email-masked]>
Date: Sun, 28 May 2006 20:00:15 -0700

Dale:

I am not sure why you believed that changing dynamic payload numbers with in
a session is not a problem per RFC 3264. I specifically found these in
section 8.3.2 that indicate the problem I am referring to:

".... For example, if A generates an offer  with G.711 assigned to dynamic
payload type number 46, payload type number 46 MUST refer to G.711 from that
point forward in any offers or answers for that media stream within the
session".

When the call between A and B first got set up, B could have ended up
choosing payload type number 46 to be G.711. Howver, when B initiates an
INVITE w/o SDP towards the MOH service, there is nothing preventing the MOH
service to use payload type number 46 for G.729. Should B use this as an
offer towards A, I was thinking it would violate the above MUST NOT?

I agree there are other issues with respect to ordering of m lines, the
number of m lines and so on that are indicated in RFC 3261 but I just wanted
to start off with the first one :-).

Venkatesh

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 23:16:15 -0400

On Sun, 2006-05-28 at 20:00 -0700, Venkatesh wrote:
> choosing payload type number 46 to be G.711. Howver, when B initiates
> an INVITE w/o SDP towards the MOH service, there is nothing preventing
> the MOH service to use payload type number 46 for G.729. Should B use
> this as an offer towards A, I was thinking it would violate the above
> MUST NOT? 

I had missed the item you pointed out, and only saw the passage where it
mentioned that the payload type could only be "used" (or some such) for
a particular codec, which left it ambiguous whether an *offer*
containing the payload type with a different codec was valid, but it was
clear that any *answer* had to select a different payload type, in order
to avoid "using" the paylod type incorrectly.

Dale