Actually, the standard does have a relevant "SHOULD".
RFC 3261, section 14.2:
A UAS providing an offer in a 2xx (because the INVITE did not contain
an offer) SHOULD construct the offer as if the UAS were making a
brand new call, subject to the constraints of sending an offer that
updates an existing session, as described in [13] in the case of SDP.
I suspect that people who argue for returning the current
media types/codecs are really covering for implementation
limitations. But I could be wrong. It's not a "MUST".
In regard to the "semantic meaning" question, 3PCC flows
are the typical usage, but the UAS can't *know* the semantic
meaning. All it knows is it got a re-INVITE w/o SDP.
-troy
"Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]> said:
Hi,
This has been discussed a number of times.
The problem is that the standard doesn't describe any specific behaviour. For
3PCC cases all the supported media types/codecs are supposed to be returned,
but some people have also described use-cases where the current media
types/codecs are to be returned.
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Diego B
Sent: 15. syyskuuta 2005 10:28
To: David Stuart
Cc: sip-implementators columbia CS
Subject: Re: [Sip-implementors] re-INVITE with no SDP
Hi;
You can check RFC 3725 for 3PCC usage of re-INVITE with no SDP.
In some 3PCC scenarios, when Media has to be switched between legs,
re-INVITE with no SDP is used to start the media switching process.
The expected response is a response with SDP listing all the suported
media types/codecs to be presented to the other leg, and start a re
negotiation of media.
Regards
Diego B
David Stuart wrote:
Hi Everyone,
Is there any particular semantic meaning to a re-INVITE
with no SDP?
How should a request like this be responded to?
David
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
