On 2/22/12 5:59 PM, Kevin P. Fleming wrote:
> On 02/22/2012 04:11 PM, Iñaki Baz Castillo wrote:
>> 2012/2/22 Paul Kyzivat<pkyzi...@alum.mit.edu>:
>>> If I was in the position of needing to construct a temporary offer, with
>>> no ability to handle media myself, and no knowledge of what the caller
>>> might be looking for or what is likely to be offered later, I would be
>>> inclined to offer audio with G.711 and a black holed IPv4 media address.
>>> Or maybe I would offer both audio and video and a whole bunch of codecs,
>>> still with black holed IPv4 address. But if possible it would be better
>>> to tailor the offer to the sorts of capabilities that will be offered later.
>>
>> And all of this makes the requirement of an SDP offer in the first 1XX
>> response really a pain, am I wrong?
>>
>> BTW, what about if a SIP proxy/server receives an INVITE with no SDP
>> offer and "Require: 100rel" and the SIP proxy/server wants to reply a
>> 181 "Call Is Being Forwarded" or 182 "Queued" before ruting the call
>> to the appropriate destination (imagine an specific SIP application
>> server for an incoming call-center)? why should such a SIP
>> server/proxy include an SDP offer in the 181/182 response? It makes no
>> sense at all, and hence the requirement within RFC 3262 is wrong
>> (IMHO).
>>
>> Maybe this annoying requirement is inheritance from RFC 3261 in which
>> is stated that "the first reliable response to an INVITE MUST contain
>> an SDP answer/offer (depending on the presence of SDP offer in the
>> INVITE or not)?
>
> Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
> that 181/182 response into a 'reliable response'.

AFAIK that language came before my time.
If we had it to do over, I suspect that requirement would be relaxed.
But we are where we are, and changing it would probably cause more grief 
than living with it. (The problem being backward compatibility with any 
implementations that depend upon this.)

        Thanks,
        Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to