Re: [Linphone-users]uncommon sip-signalling

[Aymeric Moizard]

Linphone will be ported to eXosip soon which will add support for on/hold
off/hold. (the body in the ACK might be still unsupported for some time!)

It will also add support for REFER, SUBSCRIBE, NOTIFY and MESSAGE
methods.

Aymeric

On Tue, 8 Jul 2003, address@hidden wrote:

> Hello,
>
> First of All:
> Thanks for writing linphone.
>
> I have a question about some special kinds
> of SIP-signalling, and whether linphone
> supports it.
>
> The normal way of initiating a session
> processes as following:
>
> ---------- Invite (with SDP) ---------->
> <-------------- Trying -----------------
> <-------------- Ringing ----------------
> <--------- 200 OK (with SDP) -----------
> ----------------- ACK ----------------->
>
>
> Ok, that works fine with linphone and
> partysip.
> (except of that anoying latency caused by
> my old-school-soundcard's dsp-blocksize
> set to 8192)
>
> But there are other options of SIP-Signalling
> mentioned in the RFCs.
> For instance an ACK to 200 OK may contain an
> application/sdp message body. This is permitted
> if the initial INVITE did not contain an sdp
> message body:
>
> --------- Invite (without SDP) -------->
> <-------------- Trying -----------------
> <-------------- Ringing ----------------
> <--------- 200 OK (with SDP) -----------
> ------------ ACK (with SDP) ----------->
>
> I tried this a couple of times, but
> linphone always crashed.
> So, is this generally supported by
> linphone?
>
>
> Another way is, to put the callee "onhold"
> by using an SDP-body without media-lines
> and the connection address set to "0.0.0.0".
>
> --- Invite (SDP without media-lines) -->
> <-------------- Trying -----------------
> <-------------- Ringing ----------------
> <--------- 200 OK (with SDP) -----------
> ------ ACK (SDP with media-lines) ----->
>
> The advantage of both techniques would be,
> that a proxy in the signalling-path can
> make the decision which codec to use.
>
> So again: does linphone support this signalling?
>
>
> Thanks in Advance
> Stefan Fritzsche
>
>
> PS: Some RFC-references, where this signalling
> is mentioned:
>
> RFC 2543: page 29, chapter 4.2.2 ACK:
>
> .. The ACK request MAY contain a message body with the final session
>    description to be used by the callee. If the ACK message body is
>    empty, the callee uses the session description in the INVITE request.
>
> RFC 2543: page 139, chapter B.4:
>
>    In some cases, a caller may not know the set of media formats which
>    it can support at the time it would like to issue an invitation. This
>    is the case when the caller is actually a gateway to another protocol
>    which performs media format negotiation after call setup. When this
>    occurs, a caller MAY issue an INVITE with a session description that
>    contains no media lines. The callee SHOULD interpret this to mean
>    that the caller wishes to participate in a multimedia session
>    described by the session description, but that the media streams are
>    not yet known. The callee SHOULD return a session description
>    indicating the streams and media formats it is willing to support,
>    however. The caller MAY update the session description either in the
>    ACK request or in a re-INVITE at a later time, once the streams are
>    known.
>
> RFC 3261: page 80, chapter 13.2.1:
>
>  o If the initial offer is in the first reliable non-failure
>    message from the UAS back to UAC, the answer MUST be in the
>    acknowledgement for that message (in this specification, ACK
>    for a 2xx response).
>
>
> --
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
>
> Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
>
>
>
> _______________________________________________
> Linphone-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/linphone-users
>