Hi All,
Thanks for the tips... it is as I feared; no common agreement. These
kinds of troubles are exactly what is hampering SIP inter-op.
I agree that NORMALLY all the supported medias should be returned;
however in our case the remote side is clearly not expecting this
(unfortunately).
Thanks for the help,
Dave
Christer Holmberg (JO/LMF) wrote:
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
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
