[Sip-implementors] 3PCC re-connecting scenario
pkyzivat at cisco.com
Wed Sep 7 22:55:57 EDT 2005
I think the issues you are raising are issues of (in)compatibility
- 2327 may say that m-lines are required, but newer versions
(draft-ietf-mmusic-sdpnew-*) make them optional.
- 3264 says that an sdp body with no m-lines is an offer or answer even
if it has no m-lines, but 2543 decided if an offer was present by the
presence of an m-line.
The cases that are treated differently are unusual cases, but are
potentially problems for those that want to use them. I think there is
no perfect solution, except that 2543 implementations will hopefully
soon only be memories.
Amarendra Kumar wrote:
> 1. re-INVITE with no media should not cause an offer to be sent. As this
> state will be offer received, you can't not make an offer when you received
> an offer itself. Most of the endpoint consider re-INVITE with no-media
> as equivalent to the re-INVITE without offer, Thus they end up in sending
> an offer, which is not correct behaviour. According RFC 3264 if Offer
> zero "m" lines then answer to that MUST contain zero "m" lines.
> Support for RFC 3725 needs to given to the endpoints,
> otherwise there may be serious interoperability issue between endpoints
> and all 3pcc controller.
> But the issue over here is that as per the RFC2327 (section 6.SDPSpecification)
> there m-lines are mandatory parameter in the SDP body. Thus if an end point
> received INVITE with-out media(zero m-lines), it will reject the request
> 406 Not Acceptable.
> Same senario with the RFC 3264 and 3725 will work with-out any problem.
> is a significant gap between 3264 and 2327. I didn't find any documentation
> for it.
> This gap may cause interoperability issue between endpoints and all
> This is creating confusion which one to follow. This is an issue which needs
> to be taken care.
> On 9/1/05, Tina K <kramarv at gmail.com> wrote:
>>we are developing the application for re-connecting parties taken from 2
>>different calls. Initially I was thinking about inviting first party with
>>no_media SDP, 200-ACK, then re-INVITE B-party with no media, obtain offer,
>>re-INVITE A with SDPb. Then A answer with SDP a' which will be sent to B
>><----------INVITE (SDP no_media)
>>----------------->INVITE (no SDP)
>><---------------INVITE (SDP b)
>>-------------->200 (SDP a)
>>-------------------------> ACK (SDP a)
>>1. re-INVITE with no_media causes offer in real life (despite RFC 3725). I
>>suppose some Media Gateways will send BYE upon reception ACK without an
>>2 . ACK (SDP a) - the call may end up by generation a BYE by B-party.
>>Let' say I send first INVITE with idisabled media (a=sendonly or inactive)
>>get 200 with SDPa and send ACK. However, the second problem seems to me
>>Any ideas how to avoid ACK with SDP?
>>Sip-implementors mailing list
>>Sip-implementors at cs.columbia.edu
More information about the Sip-implementors