[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-users]uncommon sip-signalling
From: |
Aymeric Moizard |
Subject: |
Re: [Linphone-users]uncommon sip-signalling |
Date: |
Tue, 8 Jul 2003 11:40:58 +0200 (CEST) |
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
>