[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] sdp in re-invite rfc 3261 14.1. Current suppor

From: Dave Harley
Subject: Re: [Linphone-developers] sdp in re-invite rfc 3261 14.1. Current support/intentions?
Date: Fri, 17 Jul 2009 16:38:25 +0100

Hi Simon,

I managed to get a test preformed using the latest version of Linphone for windows (3.1.2).
Hopefully this is up to date enough.

1st test.
1) Linphone calls an analogue extension which is connected to a Mitel PABX.
2) Call is established.
3) Analogue extension tries to go on hold.
4) Analogue extension tries to retrieve call from hold.
5) Call is terminated ( actually not sure which end hangs up but its not important).

2nd test is the exact same with the exception that the call is made from a xlite client.

Attached are wireshark pcap traces of the sip transfer for each test and the debug trace produced by the Linphone client.

In the Linphone test the interesting bit is that Linphone issue's a 603 decline to the bodyless (re-)invite which is received after the dialog has been established.
In the 2nd test the xlite response to the same packet  is 200 Ok with an SDP body attached, which is acked with an SDP body ( including the hold indication) by the Mitel.  

The other interesting thing is that the Linphone test shows no indication of a off hold event, which makes sense cause it never went on hold in the first place I guess.
The xlite does see the off hold (re-)invite.  However in this case the invite does have a body.  Screwy pabx! 

>From my reading of 3216 sec 14.1 I would think that xlite is more compliant, but I suppose I would say that. Certainly from an interop point of view it would be nice if Linphone handled the interaction similarly. 
I'm sure like all RFC's its open to interpretation and the xlite/Mitel interpretation might not match your own views. 

I'd be grateful if you could let me know your analysis.  If there is any further testing I can do let me know and I'll do by best.

Best regards,

The results are as follows: 

On Thu, 2009-07-16 at 17:25 +0200, Simon Morlat wrote:
Hi Dave,

Receiving of INVITEs and reINVITEs without SDP is implemented and it should 
work. I think it has been implemented shortly after the email you refer.
Try lastest release (3.1.2). This feature is not tested very often, just tell 
me if you find a bug.


Le jeudi 16 juillet 2009 16:17:32, Dave Harley a écrit :
> Hi All,
> There was a query about 2 years ago regarding receiving invites and
> re-invites with no sdp offer when interoping with a mitel.  It
> referenced 14.1 and 13.2.1 of RFC 3261.
> I'm running an old release of linphone which was happily doing its job
> up to now.  However recently it appears that I need to support the above
> against both a Mitel and an Aastra A5000 iPBX.
> At the time Simon pointed out he had no immediate intention of
> implementing this (from the original thread:
> ).
> Just wondering has this situation changed?  Is there any support in the
> top of the tree for this aspect of the RFC?
> I would test this myself before asking but getting access to the
> environment where it exhibits is... problematic.
> BTW I originally thought this was an osip issue and posted there. I was
> wrong and was, very helpfully, pointed in the right direction. So
> apologies if this mail seems familiar to any list members.
> Best regards,
> Dave

Dave Harley.Senior Systems Engineer

Email: address@hidden   Web:
Tel:     +353 21 4941607                        Fax:  +353 21 4800848

Integrated Point-Of-Care Entertainment & Information System

Unit 6 (Nualight Building), Cork Technology Park, Model Farm Road, Cork, Ireland

Dublin office : Digital Depot,Thomas Street, Dublin 8, Ireland

This email may contain information which is confidential and/or privileged. 
The information is intended solely for the use of the individual or entity named above.
If you are not the intended recipient, be aware that any disclosure, copying, distribution
or use of the contents is prohibited. If you have received this electronic transmission
in error, please notify the sender by telephone or return email and delete the material
from your computer.

Attachment: traces.tar.gz
Description: application/compressed-tar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]