[Linphone-users]uncommon sip-signalling

[stefanfritzsche]

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!